Static Routes: Right Tool, Common Trap

A new elementary campus. One fiber link back to the district. A handful of subnets behind it. There is no case for OSPF here — there is a case for six well-chosen static routes, a summary, and a document that says why each one exists.

Static routing is not the beginner option. It is the correct option for small, stable topologies, and it is a trap in large or changing ones. Knowing which you have is the whole skill.

The mechanics

A static route says: to reach this prefix, send to that next hop.

ip route 10.50.0.0 255.255.0.0 10.0.0.9

In UniFi: Settings → Routing → Static Routes → Create New. Destination network, distance, and either a next-hop address or an interface. The next-hop form is the one you want on Ethernet.

The distinction matters. Specifying only an interface tells the router "anything in this prefix is directly attached to that port," so it ARPs for every destination address individually. On a point-to- point link with two addresses that is harmless. On a shared segment it produces an ARP entry per remote host and a table full of confusion. Use a next hop, and let the recursion do its job.

Floating statics: failover without a protocol

Two routes to the same prefix, different distances:

The router installs only the better one. If the fiber route's next hop becomes unreachable, the route is withdrawn and the backup takes over. That is real failover, and it costs one extra line.

What it does not do is fail back gracefully, converge quickly, or tell you it happened. Static failover is detection by next-hop reachability, nothing more. If the fiber is up but the far side is broken, both routes are "valid" and traffic still goes into the hole.

Summarize or drown

A new campus with ten VLANs needs either ten routes on the district core or one summary.

10.50.0.0/16  -> new campus

Everything at that site lives inside the /16, so one route covers all of it, and the campus router carries the ten specifics internally. Now adding a VLAN at the new site requires zero changes at the district core — which is the entire point of a summary.

The rule: summarize at the edge, be specific at the core only when you must. A summary that accidentally covers an unassigned range is how you black-hole future subnets; pick the block, document it, and never allocate outside it.

Worked example: the new campus

Existing district: 10.0.0.0/8, subdivided by site (10.10.x primary, 10.40.x high school, 10.30.x middle school). The new elementary gets 10.50.0.0/16.

On the district core:

On the new campus router:

Note the symmetry. The district core needs one summary toward the campus; the campus needs a default and the district block back. Two lines each, and the whole site is routed.

When static routing stops being right

• More than a handful of paths. Every site needs a route to every other site. Five sites is 20 routes; ten sites is 90. At that point a typo is a certainty.
• Multiple uplinks with real failover. Static tracking can watch a next hop, not a path.
• Frequent changes. Every new subnet means touching every router.
• Mixed vendors. Syntax differs, and the person on call at 02:00 will not remember three dialects.

The honest threshold: if you can draw the whole topology on one page and every route fits on one screen, static is fine. If you cannot, the protocol is cheaper than the outage.

What breaks in production

• Next hop on the wrong side. A route pointing at an address that is not in a connected subnet never installs. Some platforms log nothing.
• Missing return route. The new campus can reach the district; the district has no route back. Pings work one way, TCP never completes.
• Asymmetric paths with NAT. Traffic leaves through the fiber and returns through the VPN, and the firewall has no state for the return. Looks like random drops.
• Summary covering a live subnet elsewhere. 10.48.0.0/14 looks tidy until it swallows a subnet that belongs to another site.
• Routes that outlive the design. Someone decommissions a link; the route stays; the next person spends an afternoon on it.

Checklist

1. Every static route uses a next hop, not just an interface.
2. Each site has exactly one summary pointing at it, and nothing else allocates inside that block.
3. Backup routes use a clearly different distance, and someone has tested the failover.
4. Return routes exist in both directions, and you have proven it with a sourced ping.
5. The route table is in the documentation, with a comment per line explaining why it exists.

Next

The mechanics are simple; the planning is not. Continue with Designing a Second Campus, where the subnet plan, the link, and the summary are decided before anyone configures a router.