Debug output

- [Narrator] Debug commands are a very helpful and powerful way that we can troubleshoot within iOS. They provide real time information, about what's taking place on the device. But the caveat is , you have to be really careful with how these are used. They can generate lots and lots of information, and in many cases, if you use them incorrectly, if you use the wrong command, you can take down a device unintentionally, by completely overwhelming the CPU on the device and causing it to crash. So the general rule of thumb, when using debug, is that you want to be as specific as possible, in order to avoid this type of issue. So let's take a look at some debug output messages, and see how we can interpret these. Here you can see OU topology, we have an EIGRP area, and a couple of OSPF areas. We're going to take a look at how we can use debugging, to troubleshoot an adjacency issue, with our OSPF area in this example, and that's a common way we might use this. Some of the adjacency issues we might face, could include, misconfigured interfaces, incorrect network masks, and MTU size issues. Here we're already connected into router three. So let's say show IP OSPF neighbor, and you'll see that we have two neighbors listed, router four, at four.four.four. and router two at two .two .two.two. Router two looks okay, we have a full adjacency. However router four, it's telling us that the adjacency is down. it's in the downstate. So that's certainly not good. Let's use a debug command, and see if we can find out more information about that. So let's say debug IP OSPF adjacency, and we're going to get a lot of information coming in, that we can use. So we have some information coming in, I'm going to say no debug all, to turn off all of our debugging. So you can see that we have some debug messages populated here and if we look at these messages, of course we have a timestamp. So again, want to make sure that your time and date is set correctly, but really clearly it's spelled out for us. Neighbor four.four.four.four, has a smaller interface MTU. So we really quickly found out exactly what the issue was going on. So if we take this output, take this information and we go over to router four on this particular interface, let's set the MTU to 1500. So we'll just use the command MTU 1500 under the correct interface, so that we don't have a mismatch any longer. That's a very common reason why we would see this particular problem where the router is down. We might have an MTU mismatch. And very quickly without having to do a lot of work, debugging has told us that that is exactly what the issue is. So we've corrected our MTU size, I'll just do a quick shut, and no shut. And now we can see, from router four, already that our interface is coming up, and it's trying to resume the adjacency with router three. Let's jump back over to router three. And we'll again say show, IP OSPF neighbor. So still in the downstate, give it a little time we can actually see it's trying to work on that. And there we just got our message that, it went from loading to full. So our adjacency should be back up now, run that command once more. And we do have a full adjacency now, with router four. So really quickly, the debugging commands allowed us to find out what the issue was. So that's one example, of what we can see with that. Let's look at the output of debug IP OSPF hello. So if we run that command, we'll let it run for just a second, so that we do get some messages, and then we'll say no debug all so that we don't continue to get those messages. So by default, OSPF hello messages are sent out to the multicast group, 224.0.0.5 That's what we see here, And those are sent out every 10 seconds. So this is telling us that our gig zero/two interface, sent a hello message to this multicast group. And we also received, a hello message , from router four, on the same interface. So this again is great information to have. If we had a hello timer mismatch on our network, debugging would have clearly indicated that in our output. So in fact let's go back, to router four, under the same interface. Let's say IP OSPF hello hyphen interval. And we'll set that to 15, instead of the default value. We'll give that just a little bit of time, And if we go back to our three , let's again say debug IP OSPF hello. We'll let some information populate there. And we'll again say no debug all. We're told specifically that we have a mismatched hello parameter, from the router to interface. So that's very helpful to us. Now we know exactly how to correct that issue, without a lot of effort in troubleshooting. If we go back to, router four and we change that interval back to 10, back to the default value, that's going to correct everything. We'll go ahead and say, debug IP OSPF hello, and take a look at those messages one more time. And again we see our neighborship come back. It's gone from loading to full. So everything is back to normal. We see that adjacency as a neighborship now. So you can see debug messages are super powerful troubleshooting tools. And once again I'll point out the importance of proper date and time here. As is important with every type of log message. If we say debug IP, and we take a look at contextual help, you can see there are many many options for debugging on this router. Again, use caution when you're debugging, especially in an enterprise environment. We've looked at a couple of examples here by debugging with OSPF, but debugging has a vast amount of options. And it's really really helpful if you want to pinpoint problems within your network. So that's a look at creating and interpreting a debug command output.