If we're going to be diagnosing network problems, then we need to start with
the debug command.
The debug command is part of our privileged exec level, meaning we don't have
to go into
global configuration, but we do have to make sure that we have enabled and
entered the
enable secret in order to put in these debug commands.
The format is going to simply be the word debug, and then we are going to
clarify or
specify the feature that we want to debug, and then we typically have some WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
specify the feature that we want to debug, and then we typically have some
other options
afterward.
And then importantly, I need to be able to turn off my debug.
And so even though we can use a no debug command, it's also pretty common
simply to
say on debug.
So if I say on debug, and then I specify the debug I want to disable, or I can
say all
to get rid of all of my debug, and that's actually pretty helpful when we are
running
a bunch of debug all at once, we just want to disable everything. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
a bunch of debug all at once, we just want to disable everything.
Now if I want to see the debug messages happening, debug messages are
automatically pushed out
to the console.
However, I might need to make sure that they're going to get pushed out to my
terminal, if
I'm logged in via telnet and SSH.
Well I should say or SSH and hopefully ideally SSH in our secure networks.
So I am SSH into a device and I run a debug message, I'm getting nothing back. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So I am SSH into a device and I run a debug message, I'm getting nothing back.
Well I might need to enable terminal monitor.
So simply saying terminal monitor will enable me to get those messages.
Now I might also have to check the logging level, because depending on what
that set to,
I might not be outputting debug messages to the terminal.
And technically I could change it so it's not outputting to the console either
if I'm
not seeing it there.
So we'll be talking about logging levels and enabling those coming up later on WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we'll be talking about logging levels and enabling those coming up later on
in the skill.
But for now just keep in mind that we do need to be able to see those debug, it
's sort of
the easy button if we're logged in via console because all of those debug are
output by default.
But if I am remote connected in via telnet or SSH, then I'm going to have to
enable it
with terminal monitor and possibly adjust the logging level.
And by the way, if I want to turn off the debug messages, then the no for this
command,
terminal monitor actually goes right here.
So it'd be terminal no monitor, not no terminal monitor, just sort of a little WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So it'd be terminal no monitor, not no terminal monitor, just sort of a little
nuance there.
So what are some important debug that we should know?
Well there are hundreds if not thousands of debug and it's all going to depend
on the
thing we're trying to debug.
And so rather than try to memorize all of the different debug is going to be
important
that we can go out to the documentation and say, hey, I want to debug the
events that
are happening with a particular protocol like maybe EIGRP or OSPF or spanning
tree. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
tree.
And so there are a few useful ones we could list out here.
But again, it's going to be about going out to Cisco documentation and really
trying to
figure out which debug is going to be the one that would help me to understand
what's
going on.
So for example, we might want to run a debug command for spanning tree.
And I can always just say debug type this in debug spanning tree and then
question mark
and see what options are available.
And for example, we might lock into debug spanning tree events. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And for example, we might lock into debug spanning tree events.
And this is a great option for seeing all of the different timers and the VPDUs
are
getting sent out.
There is a different separate BPDU debug that we could use.
And so there's a lot of different ways that we could use the debug not only to
troubleshoot
what's happening, but also keep in mind, it's a great tool for learning.
This is one of the ways that I learned spanning tree a long time ago is I
enabled a bunch
of debug and I also had a stopwatch available and I was timing events to make
sure I understood
exactly when things would happen. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
exactly when things would happen.
But these debug outputs are a great tool for learning exactly how particular
technologies
work.
We can also see that when we think about our layer three side, if I do a debug
IP question
mark, I'm going to see a lot of different protocol show up in here.
For example, debug IP, EIGRP.
We also have BGP in here and OSPF.
And there's all kinds of different events tied to these individual protocols.
But again, running IP, EIGRP and then a question mark will tell me different WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But again, running IP, EIGRP and then a question mark will tell me different
types of debug
that might be useful.
And then this is a big one as well.
And this one is rather infamous debug IP packet.
So debug IP packet is going to show me every single IP packet that crosses the
layer three
device.
This command is really useful in lab environments, especially because I can see
whether packets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
whether packets
are being routed by a particular way or if they're getting dropped.
And so it's great to see these packets and help me figure out, hey, is my
routing environment
set up correctly?
Are the packets actually arriving and getting sent out the interface that I
think they should
be getting sent out?
And so this is a very powerful command.
However, there are a couple of things to be aware of.
And to understand that, we need to take a look and see how this relates to the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
And to understand that, we need to take a look and see how this relates to the
CPU utilization
on our devices.
We have to be really careful about running debug on the console, especially.
And the reason for that is because on our Cisco platforms, output to the
console is considered
to be a very high priority event.
And the reason for that is because Cisco recognizes that in a network emergency
type of situation,
I need to be able to connect to the console and see what's happening.
Jansus are the networks already impaired in some of these situations. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
Jansus are the networks already impaired in some of these situations.
And so we're going to risk dropping packets and not processing packets because
the CPU
is so busy outputting to the console.
And so that's a very important aspect of console connectivity and running the
bugs out
to the console.
But this becomes even more important when we think about commands such as debug
IP packet
in production, because when we look at this and we're talking about thousands
of packets WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
of packets
per second and possibly even more than that, well, this all of a sudden is
going to result
in our CPU being burned on outputting to the console.
So we might want to consider a different logging method, either going to
terminal or possibly
just a syslog server.
But the other option that we can use for this debug and potentially others is
using access
control lists for the sake of deploying limits.
So at this point, what we could do is deploy an ACL that targets a specific WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So at this point, what we could do is deploy an ACL that targets a specific
source IP address
or possibly a destination IP address and then map it to the debug command.
So for example, now I can say debug IP packet.
And then I can specify the access control list after it.
And now it's not outputting all of the packets that cross the layer three
device, but rather
looking for very specific packets and then reporting that back to me.
So we do have that option with especially debug IP packet, but there are other WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
So we do have that option with especially debug IP packet, but there are other
debug
commands that maybe just give me too much information.
And at that point, I can look to apply an access control list to not only
reduce CPU
load, but also to make it easier on me to parse through the information.
[BLANK_AUDIO]