Refer to the exhibit. The administrator noticed that the connection was flapping between the two ISPs instead of switching to ISP2 when the ISP1 failed. Which action resolves the issue?
Refer to the exhibit. The administrator noticed that the connection was flapping between the two ISPs instead of switching to ISP2 when the ISP1 failed. Which action resolves the issue?
The issue is that when ISP1 fails, the IP SLA continues to respond via ISP2, causing the connection to flap between the two ISPs. This is because the IP SLA is not tied to a specific source interface. By including a valid source-interface keyword in the icmp-echo statement, the IP SLA will only monitor the connectivity through ISP1. This ensures that if ISP1 fails, the IP SLA will stop responding and will not switch back to ISP2 until ISP1 is actually back online. This resolves the flapping issue.
If you ISP 1 fails the IP SLA will start pinging out via ISP 2. They the IP SLA will start responding again and put the static router back in for ISP 1. This will continue until ISP is back online. IP SLA 1 icmp-echo 8.8.8.8 source-interface g1/0
For more control over that, IP SLA may fall back to ISP2 in case source address can reach 8.8.8.8 by another than ISP1. You'll need to control that by adding: ip route 8.8.8.8 255.255.255.255 g1/0 ip route 8.8.8.8 255.255.255.255 Null0 2
Good point. https://community.cisco.com/t5/routing/ip-sla-tracking-a-far-ip/td-p/1971337
Note this is a bad idea with a common DNS like google. Ideally you ping some WAN specific interface that is only reachable from ISP1 exclusively, it prevents the complexity.
yes, option A. look this: https://www.lead2pass.com/downloadable/download/sample/sample_id/7350/