A few days ago I’ve received a cryptic e-mail with exactly this content: “I am having a issue "static routes not flushed when next hop is unreachable" please advice.” I suspected that the sender actually wanted to ask me what to do if a static route pointing to an IP next-hop does not disappear when the next hop becomes unreachable and told him to adjust the ip route static adjust-time parameter while monitoring the CPU usage.
The reason for this suggestion is simple: while various events (including changes in interface state and tracked objects) cause immediate change in the state of the static routes, the changes to next-hop reachability are not evaluated immediately; the next-hop check is done periodically and the default interval is 60 seconds.
A very low value of the scanning interval increases CPU utilization on a device with many static routes.
To illustrate this behavior, I’ve configured a simple static route using a loopback IP address of a remote OSPF router as its next hop:
S1#show ip route 10.7.8.0 Routing entry for 10.7.8.0/24 Known via "static", distance 1, metric 0 Routing Descriptor Blocks: * 10.0.0.22 Route metric is 0, traffic share count is 1 S1#show ip route 10.0.0.22 Routing entry for 10.0.0.22/32 Known via "ospf 1", distance 110, metric 65, type intra area Last update from 10.0.0.11 on Serial1/0.100, 00:00:26 ago Routing Descriptor Blocks: * 10.0.0.11, from 10.0.0.11, 00:00:26 ago, via Serial1/0.100 Route metric is 65, traffic share count is 1
When the remote loopback interface was shut down, the OSPF route disappeared within a few seconds (as dictated by the SPF delay timer), but it took almost a minute for the static route to be removed from the IP routing table (the printout was generated by the debug ip routing command).
00:04:23.953: RT: del 10.0.0.22/32 via 10.0.0.11, ospf metric [110/65] 00:04:23.953: RT: delete subnet route to 10.0.0.22/32 00:05:10.766: RT: del 10.7.8.0/24 via 10.0.0.22, static metric [1/0] 00:05:10.766: RT: delete subnet route to 10.7.8.0/24
After changing the scanning interval to one second, the static route disappeared almost immediately after the OSPF route:
S1(config)#ip route static adjust-time 1 S1(config)# 00:07:08.994: RT: del 10.0.0.22/32 via 10.0.0.11, ospf metric [110/65] 00:07:08.994: RT: delete subnet route to 10.0.0.22/32 00:07:09.882: RT: del 10.7.8.0/24 via 10.0.0.22, static metric [1/0] 00:07:09.886: RT: delete subnet route to 10.7.8.0/24