Refer to the exhibit. What are two reasons for IP SLA tracking failure? (Choose two.)
Refer to the exhibit. What are two reasons for IP SLA tracking failure? (Choose two.)
The source-interface is configured incorrectly as it should be Fa1/0 based on the topology, making E a correct option. Additionally, the default route has the wrong next hop IP address. The configuration includes a default route pointing to 172.30.30.2 with lower administrative distance, which would take precedence and cause tracking to fail, confirming C as correct. Therefore, the accurate reasons for IP SLA tracking failure are E and C.
Another awful question. However, it's realistic. It's realistic because poor communications skills are so common in this field.
lmfao, true
I labbed this up in CML. Only E) is correct. No second matching answer yet. A. The threshold value is wrong. => Threshold is correct, I tested it + see my previous post below. (frequency seconds ) > (timeout milliseconds ) > (threshold milliseconds ) B. The destination must be 172.30.30.2 for icmp-echo. => "icmp-echo 172.20.20.2" is correct, no changes required. C. The default route has the wrong next hop IP address. => If you have a default route, and also the same default route with tracking, then you can delete the normal default route ("ip route 0.0.0.0 0.0.0.0 172.20.20.2"), and the other default route with tracking won't be affected ("ip route 0.0.0.0 0.0.0.0 172.20.20.2 track 10"). It remains in the configuration. So, the default route configuration looks good. D. A route back to the R1 LAN network is missing in R2 => It is not necessary to have reachibility from R2 to R1's LAN for IP SLA and tracking to work. IP SLA + track works fine without this, it won't cause a failure. E. The source-interface is configured incorrectly. => It is true. Based on the picture it should be "icmp-echo 172.20.20.2 source-interface fa1/0".
A, B and C are all wrong. Idk why you voted A as a correct answer, because setting a threshold of 500 ms is perfectly valid. You basically say 'if the ICMP-echo reply comes after 500 ms, then remove the route'. B and C are wrong because the default routes and ADs are configured correctly for what the track and SLA configs try to accomplish. D and E are technically correct, but they exclude each other: - If you use fa0/0 then the ISP probably needs a route to the internal network, making D correct. But if D is true then E is incorrect, because if the ISP has a route to the internally network, then it has reachability back to FA0/0 and the source-interface is not configured incorrectly anymore, making E wrong. - If E is correct, then the ISP no longer needs a route to the internal network making D Wrong.
Since its using Source-interface Fa0/0 we can assume the R2 will not have a route back to it, to solve the issue, adjust the source-interface to Fa1/0.
I'll say D and E A. The threshold value is wrong - Not wrong. Works on routers. B. The destination must be 172.30.30.2 for icmp-echo. - It could be either of the two ISP's C. The default route has the wrong next hop IP address. - The command "no ip route 0.0.0.0 0.0.0.0 172.20.20.2" will not remove "ip route 0.0.0.0 0.0.0.0 172.20.20.2 track 10" if it exists on the router. And if it does not exist, it will throw this error: "%No matching route to delete" D. A route back to the R1 LAN network is missing in R2. - R1 LAN is the source interface. Ideally, the IP SLA source-interface should be the interface facing the ISP (except in cases of BGP redistribution). E. The source-interface is configured incorrectly. - Now this means almost the same thing as option D, but since we've been asked to choose two options, we are forced to choose it too.
Threshold is OK. (frequency seconds ) > (timeout milliseconds ) > (threshold milliseconds ) (frequency 10 seconds = 10000ms ) > (timeout 5000ms ) > (threshold 500ms) https://notes.networklessons.com/ip-sla-parameters
Fa0/0 is probably hidden for R2, so also R2 won´t have routing to reach it.
It's CE, if you delete the default route to 172.20.20.2 obviously the tracking doesn't work, and the source interface is clearly wrong.
It is CE
D and E is correct
Guys it´s D and E Just check the SAME question here Question #253 <- Get the answer
Actually Q253 is different but you can gather some information from it. A. Threshold is OK since it was OK in Q253 so not one of the two answers B. Destination should not be 172.30.30.2 for icmp-echo so not one of the 2 answers C. Both default routes are OK (the No removes any previous untracked default route through 172.20.20.2 so not one of the two answers Clearly E is an answer, should not be using LAN IP as SLA source (this was a possible answer in Q253 but the SLA source interface there was Fa1/0 so wasn't the answer there) But if you are using LAN IP as SLA source, and R2 needs a route back to it and likely does not and D is the only answer we have left to correctly choose.
A and E D. I don't think so. The ISP is propably not interested in my LAN IP-Range, especially when it is private range. So with E (another source interface) it is not necessary to go for D.
A. Threshold seems legit B. Why would we be tracking secondary link with IP SLA C. Might be the issue My understanding is that ip route 0.0.0.0 0.0.0.0 172.20.20.2 track 10 will only get installed when track is up. Track will go up only 172.20.20.2 is reachable and i believe it is not since our default route is pointing to 172.30.30.2 (ad 5 - is installed since tracked default is unreachable) no ip route command will no remove static route with track statement D. No proof of that but real case scenarion E - We can source the echo from any interface I would go with C & D
D & E are the best options
I think the E is not correct because there is no problem with the Fa0/0 as the source interface as we want to check the ping from the LAN interface, so therefore ascertained that answers B and C are wrong the only left is A because we are using "Reachability" tracking so threshold value is not important and can be ignored https://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst9500/software/release/17-5/configuration_guide/ip/b_175_ip_9500_cg/configuring_enhanced___object_tracking.pdf page 3
Actually D and E are contradicting each other One of them should be present
A and E D. I don't think so. The ISP is propably not interested in my LAN IP-Range, especially when it is private range. So with E (another source interface) it is not necessary to go for D
Correction: LAB test threshold=500ms, SLA works normally. Answer: DE ok