Refer to the exhibit. After recovering from a power failure, Ethernet0/1 stayed down while Ethernet0/0 returned to the up/up state. The default route through ISP1 was not reinstated in the routing table until Ethernet0/1 also came up.
Which action resolves the issue?
To resolve the issue, a static route to the 8.8.8.8/32 destination through the next hop 203.0.113.1 should be added. This is because the IP SLA operation relies on reaching 8.8.8.8 to verify connectivity through ISP1. When Ethernet0/1 is down, the IP SLA probe to 8.8.8.8 can still succeed via ISP2, which prevents the default route through ISP1 from being reinstated. Adding the static route ensures that the IP SLA probe is specifically routed through ISP1, allowing proper tracking and the correct default route reinstatement.
IP SLA operation to check ISP-1 should not rely on ISP-2 interface/connection--reach 8.8.8.8 via ISP-2 in this case. in this case either; - the address for icmp-echo should be changed to 203.0.113.1 OR - Add static route 8.8.8.8/32 -->203.0.113.1
I initially did not understand this scenario, and I had to create a lab to see the behavior. Here is what is happening. Router reboots, and link E0/1 remains down. While the router reboots, it is attempting to rebuild the RIB, but because there is a track object monitoring the 0/0 via E0/0 to 203.0.113.1, that route is never installed into the RIB due to the SLA failing probes to 8.8.8.8/32. By adding a separate static route to 8.8.8.8 via E0/0, the SLA successfully probes 8.8.8.8 and the default route is installed into the RIB.
Really good one, this feels like a chicken & egg problem. The installation depends on the same route used to validate the ISP. It seems best practice to ideally use a WAN IP in the IP sla configuration that is reachable via directly connected. This way you do not need to think about separate routes. On the other side, if you actually want to validate "true" internet access, using an echo on some WAN IP seems also a bad idea as the ISP can have issues preventing you from reaching the internet. Anyway, really good content, Thanks!
Confirmed "A" in lab. Of course, with the original configuration in the output, the track object (+sla) did not go down at all, when lost connectivity to 203.0.113.1, because the target of the sla (8.8.8.8) was still available through 198.51.100.1. Solution "A" is definitely needed for the whole thing to work. It would be best to add this line, too. ip route 8.8.8.8 255.255.255.255 Null0 2 https://community.cisco.com/t5/routing/ip-sla-tracking-a-far-ip/td-p/1971337
A is correct
option A correct