Static versus dynamic routing — when the operator manages routes and when the routers do

A firewall’s routing table is the source of every forwarding decision. How that table is built determines how the firewall reacts to a link failure, a new prefix, or a path that becomes more expensive than it was a minute ago. Static routing puts the operator in charge of every entry; dynamic routing puts the routers in charge, with the operator defining the rules under which they cooperate. Each model is correct for some deployments and wrong for others, and choosing the wrong one is one of the most expensive misconfigurations in a production network.

This lesson covers what static and dynamic routing each do, the failure modes of static-only routing at production scale, the convergence property that dynamic protocols provide, and the deployment shapes where one or the other is the right answer.

What static routing does

In a static-routing deployment, the operator writes each routing entry. Connected routes are added by the kernel when an interface comes up; default routes are added by the operator or by DHCP on the WAN; everything else is a manually-configured static route. The routing table does not change unless the operator changes it.

The discipline of static routing is the discipline of writing every entry the network will ever need, on every device that needs it, and updating every entry when the network changes. For a single-firewall, single-upstream deployment, that is trivial: one default route. For a multi-WAN firewall, it is a small handful of routes. For a network with five remote sites and three uplinks, it is dozens of routes that must be kept consistent across every device.

What dynamic routing does

In a dynamic-routing deployment, the operator configures a routing protocol (OSPF, BGP, or another) and the routers exchange reachability information among themselves. The routing table becomes a function of what the protocol has learned. When a link fails, the protocol detects the failure (via the absence of hello packets, a timeout, or a withdrawn route announcement) and converges on a new topology.

+--------+        +--------+        +--------+
|   A    |--------|   B    |--------|   C    |
|  OSPF  |        |  OSPF  |        |  OSPF  |
+--------+        +--------+        +--------+
     |                |                |
     +----- shared LAN segment ---------+

In the diagram, the three routers run OSPF. Each one advertises its connected networks to the others. Each one builds a topology database from the others’ advertisements. Each one runs the SPF (Shortest Path First) algorithm against that database. When the link between A and C fails, A and C notice (no hellos from the other side), withdraw the route, recompute SPF, and converge within seconds. No operator action is required.

The cost is complexity. A routing protocol is a long-running daemon that consumes CPU and memory, that has its own failure modes, that has its own security model, and that the operator must understand well enough to debug when it misbehaves. The operator who deploys a dynamic protocol without understanding it has added a moving part to the network that they cannot reason about.

The convergence property

Dynamic protocols provide one property that static routing cannot: convergence — the property that after a topology change, every router in the network eventually agrees on the same topology. Convergence time is the metric. OSPF converges in seconds; BGP can take minutes; static routing does not converge at all — the operator is the convergence mechanism.

The property matters at production scale because the operator is not fast enough to update every static route in real time. A network with three uplinks and five sites has fifteen “primary” static routes and ten or more backup routes. When a link fails, the operator must log in to every device that has a route through that link and update every entry. At three in the morning. The dynamic protocol does this in seconds; the operator does it in minutes, if the operator notices at all.

The failure mode of static routing at scale is therefore the failure mode of the operator. The operator sleeps; the operator makes typos; the operator forgets a device. The dynamic protocol does not sleep, does not make typos, and runs on every device. The trade-off is correctness and effort: dynamic routing is correct automatically, but the effort is in understanding and operating the protocol.

When static is right, when dynamic is right

The decision tree:

The line moves with the number of routers and the rate of topology change. A network with two routers and a stable topology can run static routes; a network with five routers and frequent changes cannot.

Reading the routing table to see which model is in use

A quick check tells the operator whether the routing table was built from static entries or from a dynamic protocol.

$ netstat -rn | head -20; echo '---'; ps -ax | grep -E 'zebra|ospfd|bgpd|frr' | grep -v grep

Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            198.51.100.1       UGS       igb0
10.0.0.0/24        link#1             U         igb1
10.1.0.0/24        link#2             U         igb2
198.51.100.0/24    link#3             U         igb0
127.0.0.1          link#4             UH        lo0

---
1237 con- S    0:00.21 /usr/local/sbin/zebra -f /usr/local/etc/frr/zebra.conf
1241 con- S    0:00.18 /usr/local/sbin/ospfd -f /usr/local/etc/frr/ospfd.conf

Summary

• Static routing: the operator writes every entry. Correct for small, stable networks. Failure mode at scale is the operator.
• Dynamic routing: the routers exchange reachability. Correct for networks with two or more routers that need to converge. Failure mode is the protocol and the daemon.
• Convergence is the property that dynamic protocols provide; static routing does not converge — the operator is the convergence mechanism.
• The trap of dynamic on a static network: engineering theatre. The trap of static on a dynamic network: operational infeasibility.
• A routing daemon running with no configuration is half a deployment; finish it or remove it.