Selected Answer: BC Correct: B - Both static routes need a separate Track object and IP SLA probe. C - Each SLA probe has to come from a different ISP, so a different IP address. Wrong: A - A separate Track object by itself won't help; we also need a separate IP SLA probe. D - This is redundant; the router already knows which interface to use for both next hops (based on ARP and MAC address table). E - This is just messy and not required; we only need to set a different source for each probe (answer C).

Selected Answer: BC I would choose B and C. Setting the static route to 8.8.8.8 for both ISP doesn't make sense. It would make sense if there were only one static route for that.

Link: https://community.cisco.com/t5/routing/ip-sla-tracking-a-far-ip/td-p/1971337

D & E are right

Selected Answer: BC Im going for B and C, because option E isn't needed, with the default route u already have communication with google DNS, so you only need to separate the tracks between static routes and WAN's

It is not clearly explained what they want to configure with "E". It could still be a valid option with the right configuration. Based on this: https://community.cisco.com/t5/routing/ip-sla-tracking-a-far-ip/td-p/1971337 The first two static routes are there to make sure that the tested IP address inside the ISP1 is truly reached only via link to ISP1, and if that link is down, then the pings are going to be thrown away (this is to prevent pinging 8.8.8.8 via ISP2 thanks to the default route). ip route 8.8.8.8 255.255.255.255 Ethernet0/0 10.0.0.1 ip route 8.8.8.8 255.255.255.255 Null0 2 ip sla 1 icmp-echo 8.8.8.8 source-interface Ethernet0/0 threshold 800 timeout 1000 frequency 30 ip sla schedule 1 start-time now life forever track 1 rtr 1 reachability ip route 0.0.0.0 0.0.0.0 10.0.0.1 track 1 ip route 0.0.0.0 0.0.0.0 20.0.0.1 2

That way, a static route to 8.8.8.8/32 should be set only through the primary ISP, not for both ISPs. That makes "E" incorrect.

Question: "icmp-echo 8.8.8.8 source-interface Ethernet0/0" Would the device in this case only use the source IP of the interface, or only allow packets going outbound (so if a route is missing, the packets will not even be sent outbound). Anyway, in my opinion there is a difference between a route, a source interface and the actual route used for the test icmp packet. Anyway, i guess i need to lab this one to really understand how the source-interface part behaves.

Selected Answer: BC A -> No, use separate probes and track objects for each static route B -> Correct C -> Correct, if we configured the probe as: icmp-echo 8.8.8.8 source-ip <RoutersWANaddress> D -> No, including the egress interface is redundant E -> No, there is nothing wrong with the current static routes besides the attached track objects

Selected Answer: BC Maybe someone gets confused about this because they are looking at the community post. But there is a reason they use the /32 route: "The first two static routes are there to make sure that the tested IP address inside the ISP1 is truly reached only via link to ISP1, and if that link is down, then the pings are going to be thrown away (this is to prevent pinging 8.8.8.8 via ISP2 thanks to the default route)." The main point is that they want only ISP1 to reach 8.8.8.8, so if that specific route is not reachable they will fall back to the second default route, but they will not be able to contact 8.8.8.8 because there is a null0 route, since that is intentional

BUT in our scenario here we are just saying that the track is not working. For this to work we just create two IP SLA objects, and two different track, each object is going to use the ISP1 and ISP2 interface. If from that interface the 8.8.8.8 is not reachable then the track will go down. There is no need to use a static /32 route, cause we already reach 8.8.8.8 via the default route.

Selected Answer: BC in the real world, you track the preferred route and make the secondary route a floating static so it gets added to the RIB when the tracked route fails. I guess the exception is if you're using ecmp on the wan links in which case I hope you don't have any inbound traffic needs cause you shouldn't be managing that with static routes.