Static routes: when they are the right answer

There is a reflex among engineers that dynamic routing is sophisticated and static routing is primitive. That is not a useful way to choose. Each has a domain where it is correct.

Where static routing is right

A stub site with one uplink. There is one way out. A routing protocol will discover that one way out, consume memory and CPU, generate hellos, and arrive at the answer you could have typed. A default route is not a compromise here; it is the correct design.

A boundary you do not control. Pointing at a provider’s handoff. You do not want to run a protocol with a network you do not administer unless there is a reason.

Anything where predictability matters more than adaptability. A static route does exactly one thing forever. During an incident, that is a virtue.

Where it is wrong

Any topology with multiple paths that must fail over, anything that changes often, and anything large enough that the static configuration becomes its own maintenance problem. A dozen static routes is fine. Two hundred is a liability, because nobody will remove them when the reason disappears.

The failure mode to understand

A static route pointing at a next-hop address stays in the table while the interface is up, regardless of whether the next hop is alive. If the far router fails but the link stays up — common with a switch in between — traffic is forwarded into a black hole.

The answer is to verify reachability and withdraw the route when it fails:

ip sla 1
 icmp-echo 192.0.2.1 source-interface Gi0/1
 frequency 5
ip sla schedule 1 life forever start-time now
track 1 ip sla 1 reachability
ip route 0.0.0.0 0.0.0.0 192.0.2.1 track 1

The discipline

Comment every static route with why it exists. An unexplained static route is one nobody will dare remove, and it will outlive its purpose by years.