Refer to the exhibit. After implementing the configuration, 172.20.20.2 stops replying to ICMP echos, but the default route fails to be removed. What is the reason for this behavior?

Question

Exhibits

Options

• AThe source-interface is configured incorrectly.
• BThe destination must be 172.30.30.2 for icmp-echo
• CThe default route is missing the track feature
• DThe threshold value is wrong.

• A
  4% (1)
• B
  4% (1)
• C
  81% (21)
• D
  12% (3)

Explanation

IP SLA & Object Tracking Explanation

Option C is correct because even though the IP SLA probe is correctly detecting that 172.20.20.2 is unreachable, the static default route lacks a track statement linking it to the IP SLA object - meaning the router has no mechanism to automatically remove the route when the tracked object goes down. Without ip route 0.0.0.0 0.0.0.0 [next-hop] track [object-number], the route remains in the routing table regardless of the IP SLA results.

• Option A is wrong because the source-interface is a valid optional parameter and, even if misconfigured, would more likely affect the probe itself rather than causing a selective failure where tracking works but route removal doesn't.
• Option B is wrong because the icmp-echo destination should point to the monitored host (172.20.20.2), not another address; the probe is already successfully detecting the failure, so the destination is fine.
• Option D is wrong because threshold values relate to response time performance, not reachability - the probe is functioning correctly since it detects the host going down.

Memory Tip: Think of IP SLA and Object Tracking as a two-link chain - IP SLA detects the problem, but the track keyword on the static route is what acts on it. If the chain is broken, nothing changes in the routing table!

No community discussion yet for this question.