Static routing to same destination IP does not failover

[rakuten02]

The network topology is Router A - Router B - Router C.

Router A has 2 static routes to Router C.

ip route 209.112.64.5 255.255.255.255 116.55.177.57
ip route 209.112.64.5 255.255.255.255 113.165.26.155
interface 0/0 configured with 116.55.177.58. (connected to Router B)
interface 0/1 configured with 113.165.26.154. (connected to Router B)

Router B config:
interface 0/0 configured with 116.55.177.57 (connected to Router A)
interface 0/1 configured with 113.165.26.155 (connected to Router A)
interface 0/2 configured with 209.112.64.4 (connected to Router C)
ip route 203.126.64.0 255.255.255.0 209.112.64.5

Router C config:
interface 0/2 configured with 209.112.64.5 (connected to Router B)
ip route 0.0.0.0 0.0.0.0 209.112.64.4

Am I right to say that the above config means that the static route to 209.112.64.5 is load balanced and with failover?

However, once I shutdown either interface 0/0 or 0/1 in Router B, the ping from Router A to Router C will fail.

Router A does not auto failover to the next possible static route, using the other interface. Why is this so?

Thanks!

[rakuten02]

Oddly, after doing a manual traceroute to 209.112.64.5 from Router A, ping to 209.112.64.5 is able to work again.

Somehow the failover takes awhile or the manual traceroute triggers the 2nd static route to take effect.

[Georg Pauwen]

Hello,

what if you manually clear the arp and routing tables after shutting down the interface?

(clear ip arp/clear ip route)

[JimWicks]

While it's true that you will have two equal-cost routes on router-A across to your 209.112.64.5 address on router-C it is not correct to say that your ping-packets will be load-balanced.   For a given source/destination pair of addresses router-a will always chose the same egress interface even when there is ECMP route. Likewise router-B in the opposite direction (it may not be the same physical interface used in each direction as each device may have a different hash so router-A could choose interface 0/0 to send the packet and router-B could return it via 0/1).

For your ping failures, I would guess it depends what the source address is that you are pinging from on router-A and the corresponding physical interface you shut down.   If your ping source-address is 0/0 and that is also the one that you shut-down then you are going to see failures as that address is no longer available.

As a sanity-check, try configuring a loopback address on router-A to use that as the source of your pings which is independent of the interfaces you are shutting down. Then add static-routes on router-B towards that /32 loopback via the two next-hops of router-A.  Repeat the ping-test using the new loopback as source

ping 209.112.64.5 source <loopback-ip-address>

and see if it then fails over as you expect.

[Richard Burts]

We do not know how router A and router B are connected and that could possibly have an impact on failover. If an interface on B is shut down then A might or might not be impacted by this. For the static route to be withdrawn A must see its interface line protocol change state to down. Does this happen? Perhaps a better test might be to unplug an interface on A?

[rakuten02]

Thanks for the explanation all!

I did a ping 203.126.64.5 from router A, which by default seems to always use 116.97.180.58 (int fa0/0) as source IP.

Once I bring down interface 0/0 in router B or router A, ping 203.126.64.5 fails from router A.
If I do a ping 203.126.64.5 source 113.165.26.154 from router A, the ping will work.

I am expecting router A to be able to automatically switch to fa0/1 route when the route using fa0/0 is down. But this is not the case.

Result of show ip route of Router A after fa0/0 is shutdown in router A/B:
116.0.0.0/24 is subnetted, 1 subnets
C    116.97.180.0 is directly connected, FastEthernet0/0
203.126.64.0/32 is subnetted, 1 subnets
S    203.126.64.5 [1/0] via 116.97.180.57
                  [1/0] via 113.165.26.155
113.0.0.0/24 is subnetted, 1 subnets
C 113.165.26.0 is directly connected, FastEthernet0/1

[JimWicks]

As Richard mentioned above, the static route will only be withdrawn if the next-hop interface goes down after you initiate the shutdown action and in the scenario you show the Fa0/0 is still up (you see the "Connected" in the route table) and therefore you device still had the static-route via that interface in the routing table.

For this scenario, detecting the next-hop availability for your static route using IPSLA-probes is probably the way to go if you can't force the interface state to down.

[rakuten02]

thanks for clarifying! I'll take a look at IP SLA.

Status connectivity of an interface seem to work in strange ways, perhaps I do not get understand it fully.

I would think that the interface of router A would be up/down if the interface of router B is administratively shutdown. It is due to Ethernet keepalives that still work, hence the interface is still up/up?

[Richard Burts · Accepted solution]

You are on the right track. Especially with Ethernet it is possible for the peer device to be down but for the local Ethernet interface to still be in the"protocol up" state. And that does allow the static route to remain in the routing table even though the next hop is not reachable (and this basically creates a black hole where the device forwards traffic out the interface and the data just disappears since it can not get to the next hop). When using static routes and you want failover you do need to use something like IP SLA to be able to withdraw the failed route. Note that one of the benefits of a dynamic routing protocol is that it will detect a peer who is not responding and will make changes in the routing table to adjust to the failure.

[Richard Burts]

I am glad that our explanations have been helpful. Thank you for marking this question as solved. This will help other participants in the community to identify discussions which have helpful information. This community is an excellent place to ask questions and to learn about networking. I hope to see you continue to be active in the community.