- [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.