Refer to Exhibit. Which two reasons for IP SLA tracking failure are likely true? (Choose Two)
A. The source-interface is configured incorrectly.
B. The destination must be 172.30.30.2 for icmp-echo.
C. A route back to the R1 LAN network is missing in R2
D. The default route has wrong next hop IP address.
E. The threshold value is wrong.
Hey, Someguy,
I agree with A & C but for different reasons than you pointed out.
Notice that the source interface Fa0/0 is a customer facing interface on a local LAN. You wouldn’t IP-SLA on the connected interface toward the destination because it would always pass.
If R1’s local Lan is not reachable by R2, IP-SLA will fail. (C)
Perhaps Fa0/0 is not included in the routing protocol? We dont know. That information is not shown in the question.
For the same reason, if the source interface has any misconfiguration which causes routing to fail SLA will fail (A).
For this reason, I would select A & C as the reasons for SLA tracking failure.
A & C
“B” is incorrect. The IP SLA is used to determine if R1’s default gateway (172.20.20.2) becomes unavailable. Therefore, the icmp-echo command must be used against 172.20.20.2.
“D” is incorrect. Both default routes listed in the configuration are accurate (172.20.20.2 is the Primary and 172.30.30.2 is the Secondary that R1 needs to switch to if the Primary becomes unavailable). When the tracking detects that rechability is down, the configuration causes the default route to 172.20.20.2 to be removed (“no ip route 0.0.0.0 0.0.0.0 172.20.20.2”) and a new default route added (“ip route 0.0.0.0 0.0.0.0 172.30.30.2).
“E” is incorrect. The threshold value is within the valid range (Range is 0 to 60000) and is less than the Timeout (which is also correct).
“A” is correct. While the answer may appear to be worded poorly, it is not. It specifically states that the “source-interface” is misconfigured. What this means is that, In the configuration above, the line reading “icmp-echo 172.20.20.2 source-interface FastEthernet0/0” should read “icmp-echo 172.20.20.2 source-interface FastEthernet1/0” as that is the R1 interface that leads directly to R2 and the 172.20.20.2 address.
“C” is correct. Why might the tracking fail altogether? If R2 does not have a route back to R1, then the icmp-echo will fail. (This shouldn’t happen, as R2 should realize that this is a directly connected subnet, but…).
For C, this means that the tracking switches the default route to the Secondary and the Primary is never used. This is the “failure” referred to.
There is no problem with the Fa0/0 as the source interface as we want to check the ping from the LAN interface -> A is not correct.
Answer B is not correct as we must track the destination of the primary link, not backup link.
In this question, R1 pings R2 via its LAN Fa0/0 interface so maybe R1 (which is an ISP) will not know how to reply back as an ISP usually does not configure a route to a customer’s LAN -> C is correct.
There is no problem with the default route -> D is not correct.
The source interface should be reffer to the exhibit Fa 1/0.
so A is a good answer.
We see that the subnet is 172.20.20.0/30, we dont need to a default route because the network is connected with cost 0.
Default route is used for last ressort. So we dont need to response D
I think that in router R2, there is shorter prefix like 172.20.20.2/32 and if it is the case, I think that it should have a route to the 172.20.20.0/30.