Static Routing Review Checklist

Run this quarterly, and additionally after any change that adds or removes a static route, after a provider renumbers a handoff, and after any incident where traffic left by a path the design did not choose.

It overlaps the route-policy and route-leak reviews deliberately but asks a narrower question. Those ask what this router tells other routers. This one asks what it forwards on when nothing is talking to it at all: the routes a person typed, which stay exactly as typed until another person changes them.

What a static route does not have

No failure detection, no convergence, no withdrawal. A protocol route disappears when whatever advertised it stops; a static route does not. When its next-hop stops answering, the kernel goes on ARPing for an address that is not there, the traffic is dropped silently, and both show configuration and show ip route go on showing exactly what the operator wrote. Nothing in that picture looks wrong, which is why nothing logs it.

That produces two defects which need different evidence, and the list keeps them apart:

• The route is not installed. The next-hop does not resolve, disable is still set, or the commit never reached FRR. show ip route static and ip route get answer this.
• The route is installed and wins when it should not. Administrative distance decides selection, and distance is a statement about trust, not about reachability. A route can be perfectly healthy and still be the wrong one. Only show ip route <prefix>, which prints every candidate with the distance that beat the others, answers this.

Access this needs

Everything is read-only but one item: compare saved exists only in configuration mode, so enter configure, read it, and exit without committing. The FRR views are available as VyOS operational commands or through vtysh -c; the kernel views run at the same prompt.

Three items cannot be closed from this router. The return path needs a traceroute from the far end. The discard and martian items need the address plan open beside the output — the command lists what is being dropped, and only the plan says whether that was the intention.

Where the evidence goes

Attach the output, not only the conclusion. “Static routes reviewed, no findings” is worth nothing in six months; the show ip route 0.0.0.0/0 from the day is worth a great deal, because the next reviewer can diff against it. Findings here are rarely urgent and often expensive — a route nobody can explain is a route nobody dares remove — so each needs an owner and a date rather than a resolution before the review closes.

Sign-off

• Reviewer: ________________ Date: ___________
• Network owner: ___________ Date: ___________