ROUTING

OSPF, Static Routing and Gateway Failover Playbook

When static routes are enough, when dynamic routing helps, how adjacency fails, and how to test route failover instead of assuming it.

Static routes are not inferior

For a small network with one clear path, static routing can be easier to understand and safer to operate. Dynamic routing becomes valuable when there are multiple routers, redundant paths or frequent topology changes.

OSPF in practical terms

OSPF routers form neighbour relationships, exchange link-state information and calculate routes from that topology. The important installer checks are interface addressing, area membership, neighbour state, route installation and return path.

Useful Cisco-style checks

show ip ospf neighbor
show ip ospf interface brief
show ip route ospf
show ip route <destination>

Adjacency troubleshooting

  1. Confirm both interfaces are up/up.
  2. Confirm IP addresses and masks place the link in the same subnet.
  3. Confirm both ends participate in the intended OSPF area.
  4. Check authentication if configured.
  5. Check MTU mismatch if neighbours stop before full state.
  6. Check network type and timers if platform settings differ.

Default route injection

A default route is often distributed from an Internet edge into the internal routing domain. Do not advertise a default merely because the router itself has one. The design should decide whether loss of upstream Internet should withdraw that default.

Gateway redundancy

First-hop redundancy protocols and tracked static routes can provide gateway failover. The real requirement is not "two routers". It is that clients keep a usable gateway path when a router, link or upstream service fails.

Failure test

  1. Record the normal route and next hop.
  2. Start continuous traffic to a relevant remote destination.
  3. Fail one approved path.
  4. Measure convergence and service impact.
  5. Confirm the failed route is removed or deprioritised.
  6. Restore and confirm stable return to the intended state.

Common trap

A router can fail over outbound traffic while return traffic still follows the dead path. Always test both directions and stateful firewall/NAT behaviour when dual WAN or dual routers are involved.

Longest-prefix match

Routers prefer the most specific matching route. A /24 route is more specific than a default route, so an unexpected specific route can divert traffic even when the default gateway looks correct. Use the exact destination in a route lookup rather than reading only the default route.

Administrative distance and competing routes

Platforms can learn the same prefix from connected, static and dynamic sources. The routing table chooses according to route preference and metric rules. When failover behaves unexpectedly, inspect which route source actually won and why.

OSPF network design

Keep area design simple unless scale requires complexity. Passive interfaces can advertise connected networks without attempting neighbour formation on user-facing LANs. Authentication, where used, must match on both ends.

Dual WAN reality

Two ISP links do not automatically provide reliable failover. Decide how reachability is tracked, how NAT changes when the exit link changes, and whether inbound services have a surviving path. Test DNS and applications after failover, not only ICMP.

Route troubleshooting from the destination backwards

Pick the failing destination and check the exact route on each Layer 3 hop. Do not assume that because one router has the correct path, the return side does too. A useful workflow is client gateway, distribution/core, firewall/edge, remote gateway, then the reverse direction.

Black-hole routes and summaries

Summary routes can simplify routing tables but can also attract traffic for a subnet that does not actually exist behind the summary. If a summary is used, understand where more-specific routes should appear and what happens if one disappears.

Tracking static routes

Some platforms can tie a static route to object tracking or reachability tests. This can withdraw a route when the next-hop path is unusable even if the local Ethernet interface remains physically up. The tracking target should represent the service path you actually care about, not merely the directly connected modem.

Failover and stateful services

When Internet exit changes, NAT and firewall state can be lost. Existing sessions may need to reconnect even if routing converges correctly. Set expectations accordingly and test new sessions after failover as well as ongoing traffic.

Technical references

Use the current project specification and the exact product documentation for the installed equipment. These references support the technical principles used in this guide.