Exam 300-410 topic 1 question 21 discussion

The answer is 'debug ip sla error' (C) -- The route has already changed, so debug IP routing is useless. We need to find out why the IP sla is failing and thus redirecting the default route to R2, as such we need to look at the current IP sla error debugging.

C The debug ip sla error command displays debug messages when an IP SLA run-time error occurs. The debug ip sla error command can be used to troubleshoot problems that occur because of IP SLA misconfigurations or scheduler errors. Examples of problems that could cause IP SLA run-time errors include a disabled responder or a missing target.

B. debug ip sla error C. debug ip routing: This command is used to debug routing table changes. While it might show when the route changes, it will not provide details about the IP SLA test itself.

it is definitely C: R3#debug ip routing IP routing debugging is on R3# *Dec 13 05:02:27.747: %TRACKING-5-STATE: 1 ip sla 1 reachability Up->Down R3# *Dec 13 05:02:27.747: RT: del 0.0.0.0 via 10.1.0.1, static metric [1/0] *Dec 13 05:02:27.747: RT: delete network route to 0.0.0.0/0 *Dec 13 05:02:27.751: RT: default path has been cleared *Dec 13 05:02:27.751: RT: updating static 0.0.0.0/0 (0x0): via 10.2.0.1 1048578 *Dec 13 05:02:27.751: RT: add 0.0.0.0/0 via 10.2.0.1, static metric [10/0] *Dec 13 05:02:27.755: RT: default path is now 0.0.0.0 via 10.2.0.1 *Dec 13 05:02:27.775: RT: updating static 0.0.0.0/0 (0x0): via 10.2.0.1 1048578

A lot of folks are saying that since the route has already changed, what would be the point of running the 'debug ip routing' command. However, keep in mind that the question is focused on a route change, and it doesn't necessarily state that this isn't flapping. With the focus on a routing change, the 'debug ip routing' command would be most suitable, as the change in the routing table would be clearly seen if it happens again, or it's flapping. This gives you greater visibility to the route changes. On the other hand, if you focus on the 'debug ip sla error', all you get is what you already know, that the ip sla got triggered. You don't get no added value by running that command. Hence the best option would be 'debug ip routing'.

This question is incorrectly asked, otherwise it has no answer. Debug IP SLA ERROR is useless because the SLA does not have an error, it's working perfect by re-routing traffic to R2 (that is what it should be doing). Debug ip routing won't give any output if the change has already happened, so you cannot use it to troubleshoot the change that has already happened(it would have been useful if it was configured before the change). Debug ip packets gives no useful information and debug ip flow is just as usesless as well.

debug ip sla error is the correct answer because debug ip routing is for troubleshooting routing protocols.

These questions are often based on Cisco Press articles. If this is the relating article then answer "C" fits best. https://www.ciscopress.com/articles/article.asp?p=1613547&seqNum=3 Scenario: Tracking Reachability to Two ISPs Using "debug ip routing" for troubleshooting failed primary route. Output shows the route to be deleted, then missing.

Right answer C. It cannot be B. Look at the output: Router# debug ip sla error May 5 05:00:35.483: control message failure:1 May 5 05:01:35.003: control message failure:1 May 5 05:02:34.527: control message failure:1 May 5 05:03:34.039: control message failure:1 Source: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/debug/command/i1/db-i1-cr-book/db-i3.html

B should be the correct answer

The best answer is "debug ip sla error" first they are talking about an IP sla that modifies the default route if theres is a fail on SLA, then stablished that traffic started flowing to R2 due to this config. This mean that there were an error on ip sla, so is failing and and a static floating route is installed, so you the core issue to verify why sla is failing and triggering the change. Using of "Debug ip routing" will now give any output as the route has already change.

They talking about an issue, so assume that R1 doesn't loose reachability to R3, the route change so you have to find out why

If the route has changed to flow through router R2, then SLA is working. That's what it was supposed to do. So there is no SLA error. The error is whatever caused the unreachability that triggered the SLA to do its job.

The correct answer is: C

Answer B

C looks to be the correct answer

The given answer is correct. After testing GNS3: The only result that make since is "debug ip routing"