Refer to the exhibit. An IP SLA was configured on router R1 that allows the default route to be modified in the event that Fa0/0 loses reachability with the router R3
Fa0/0 interface. The route has changed to flow through router R2.
Which debug command is used to troubleshoot this issue?
To troubleshoot why the route has changed, the most relevant command would be 'debug ip sla error'. This command displays debug messages when an IP SLA run-time error occurs, which can help identify why the IP SLA is failing and causing the default route to be redirected to R2. By looking at the IP SLA errors, we can diagnose why R1 is not maintaining the connection with R3 through Fa0/0, leading to the route change.
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.
B rather, not C -- whatever 'debug IP sla error' is the answer.
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.
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
If C was correct, would only make sense if the route was not already changed. "debug ip routing" only provides info, when a route is changing, and clearly the route has already be changed. Keep it at a bad question, all are wrong in a way. I personally stick with "debug ip sla error" as a correct answer, it creates shitty output, but that is better than nothing.
The correct answer is: C
C looks to be the correct answer
Sorry, Change this to B 'debug ip sla error'
The given answer is correct. After testing GNS3: The only result that make since is "debug ip routing"
How does it make sense if you're doing it AFTER the route has already been changed? Using debug ip sla error to verify the ip sla config has failed and then using debug ip sla trace afterwards are much better troubleshooting options...
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'.
debug ip sla error is the correct answer because debug ip routing is for troubleshooting routing protocols.
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.
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.
Answer B
C is correct
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.
B should be the correct answer
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
The given answer is correct