- [Instructor] One very powerful tool that we can use
for troubleshooting our networks is debugging.
I want to start this section
with a warning regarding debugging.
You want to be very careful when using debug commands.
The outputs created by debugging can be extremely verbose.
And they can completely overtake
the router prompt in your CLI.
So you want to use this with caution,
especially in production environments.
Debugging has the ability to process a ton of information,
and it can be disruptive to the operation of the router.
It can overload the CPU
and cause some major performance issues
or even network connectivity loss.
Having said that, when used with caution
and in the right circumstances,
this really is one of our most insightful things
that we can do when troubleshooting.
Here you can see our 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,
which is a common way that we would use that.
Some of the adjacency issues we might face
could include misconfigured interfaces,
incorrect network masks, and MTU size issues.
Let's connect into router three
and let's use the command show IP OSPF neighbor.
and here we can see that we have two routers as neighbors
we have routers two and routers four,
as our OSPF neighbors.
We can see their router IDs of 2.2.2.2 for router two,
and 4.4.4.4 for router four.
However, notice that router two is in the x start state.
That's certainly not good.
That state is where they're trying to begin communications
and develop a master slave relationship.
So there's obviously a problem with this adjacency.
So we can use a debug command
to see more information about that.
So let's say debug IP OSPF
and you want to say ADJ for adjacency here.
So we can hit Enter.
And almost immediately you see that
we start to receive information
about that OSPF adjacency.
Now, we can turn this off with the command, no debug all.
And that's going to disable all possible debugging.
So you see that, that has now been turned off.
You can see how quickly that CLI can fill up
with only debugging something very specific,
such as an OSPF adjacency.
So again, that kind of underscores
the warning of taking care when you're using debugging.
So if we look at this output,
we can see very clearly stated right here,
let me highlight that,
we can see very clearly stated our issue.
It says that the neighbor 2.2.2.2 which is,
remember that's router two has a smaller interface MTU.
So there's an MTU mismatch.
And that's a very common reason why we might see a problem
with an adjacency but debugging very quickly
and very easily told us what that issue is
without much work at all.
Let me jump over to router two now.
And from there, under global configuration mode,
we'll go under interface gig zero slash two.
That's the interface that is pointed towards router three,
where that MTU mismatch appears to be.
And we can say MTU 1500.
And if we jump back to router three now, after some time,
let me just clear off some room here.
And actually it came up really quickly there.
As I was trying to clear off the COI,
you can see we have that console message stating
that the adjacency is back,
we do have a full adjacency now with router two
is gone from loading to full
and that's what we would expect to see
if we did not have that MTU mismatch.
So very quickly, we were able to identify the problem
and to correct that.
So that's one example of what we can see
with the debugging commands.
Let's look at the output of debug IP OSPF hello.
We'll let that run for just a bit.
And then once we get a few messages coming into there,
we'll again disable that with the no debug all command
just so that it doesn't continue to fill up our CLI.
So by default, OSPF Hello messages are sent out
to the multicast group address
to 224.0.0.5 every 10 seconds.
And we can actually see that here we can see that
our interface our GIG zero slash one interface received
a Hello message from router two in area one
and it shows router two's egress interface IP address
192.0.2.1
We can also see where just under that,
we have sent a hello message out to the multicast group
224.0.0.5 and area one,
we sent that out to 198.51.100.1
So we can see all of those hello messages coming and going.
So that's great information to have.
If we had a hello timer mismatch on our network,
debugging would also have very clearly indicated that
in the output.
And in fact, let's go back to router two.
And from here,
we're already under interface gig zero slash two
where we corrected that MTU issue.
And let's say IP OSPF hello hyphen interval.
And instead of the default 10 seconds,
let's just set that to 15.
Then we'll jump back to router three.
And we'll make some space here and we'll again
run that same command debug IP OSPF hello.
We'll let that populate for just a bit.
And then once we do get some messages in there,
we'll turn off our debugging again
with that universal no debug all command,
it's going to turn off all possible debugging.
And right here we can see that we are told not only that
there are mismatched parameters,
but we're told exactly what that parameter is.
We're told in this output,
that our hello parameter is mismatched
from 192.0.2.1, which is again,
that's router two's interface.
So that's very helpful to us.
Now, we know exactly how to correct this issue.
Without a lot of effort in troubleshooting.
I'll go back to router two.
And I'll just change that back to the default of 10.
And we will see some messages in our console
going back to router three,
now we see a console message saying that
Gigabit Ethernet zero slash one
which is pointing towards router two at 2.2.2.2,
that's gone from loading to full.
So now, we see that the adjacency
has come back as a Full neighbor ship now.
If we on this router, say debug IP,
and we look at our contextual help,
you can see the many many options here for debugging.
Again, you want to use caution when you're debugging,
especially in an enterprise environments
you want to use care with that.
We've looked at a couple of examples here.
But debugging has a vast vast amount of options
to help you pinpoint problems within your network.
So that's a look at a couple of common ways
that we can use debugging for network management.