The solution follows below, in white-on-white text. Highlight below if you've read the last post and want to see the answer.
I included lots of distracting configuration elements that have nothing to do with the problem:
- Multiple OSPF areas
- Different OSPF area types
- ABR disagreements about stubiness
- 'subnets' keyword on redistribution
- Mismatched wildcard bits in OSPF network statements
- OSPF process IDs
- HSRP preemption stuff
- Passive OSPF interfaces
When the Ethernet interface on either of these routers fails, then the static route to the server segment behind the firewall will be withdrawn, and the OSPF redistribution will go with it. R3 and R4 will immediately converge on the remaining path to the server segment.
Shortly after, the static route will re-appear on the router with the failed interface, but now it will have recursed through R3 or R4. Because the static route has re-appeared, the redistribution will re-appear as well.
R3 and R4 will use the path via the failed router without knowing that the path loops right back to them.
The fix here is to configure the static routes like this:
ip route 172.16.0.0 255.255.0.0 Ethernet 0/0 10.0.0.20
Using the interface keyword here locks the route to the Eth0/0 interface, preventing recursion.
The IOS documentation says this:
Specifying the next hop without specifying an interface when configuring a static route can
cause traffic to pass through an unintended interface if the default interface goes down.
In fact, while the static route as I originally presented it might seem like the "normal" way to do things, the IOS documentation explicitly refers to this sort of configuration as a "recursive static route":
In a recursive static route, only the next hop is specified. The output interface is derived from the next hop.
Hi,
ReplyDeleteInteresting post!
But isn't the static route to add
ip route 172.16.0.0 255.255.0.0 Ethernet 0/0 10.0.0.20 ?
In your post, it's
ip route 172.16.0.0 255.255.0.0 Ethernet 0/0 10.0.0.17
Fixed! Thanks, Sebastien.
ReplyDelete