This discussion on Debugs, Conditional Debugs, Ping and Trace are purely exam related. We
are just going to stick to that level of detail. Debugs are what? They are a type of syslog
message. That's what they are. They are a type of syslog message that is going to show us real
time changes as they occur on our device. Compare that to show commands. Show commands are a
snapshot in time, meaning that when you type in show, for example, run, you're seeing a snapshot
of the running config at that moment in time. Any changes that are made, you're not updated
about those changes unless you type in show run again and you look for any changes that had
occurred. It would be the same thing with show VLAN brief. You look at show VLAN brief. You
see that snapshot of what's there. If somebody adds a bunch of VLANs and you don't know that,
you're not going to know about those VLANs being added. Why? Because you need to type in show VLAN
brief again. Debugs allow you to keep track of those changes that happen in real time. By default,
they're sent to the console port, the monitor port, so your VTY lines in addition to your RAM.
In regards to the monitor port, just remember from our syslog discussion that if you are
telnetted into a device or SSHed into a device, then you also need to type in the terminal monitor
command if you want to see those debug messages, those syslog messages. The problem with debugs,
though, is they're very, very resource intensive. Although it's nice to get details in real time,
it's very resource intensive for our devices to work with those debugs. Here's an example of
something like show IP route. A show IP route gives me a snapshot of the routing table at
that moment in time. If all of a sudden my dynamic routing protocol made some changes,
I would not know that unless I typed in show IP route again. Something like debug IP routing would
actually show me the adds, the deletes, and the changes in the routing table in real time. In
this particular case, I've turned on debug IP routing, and we can see that EIGRP has made some
changes to our routing table. By typing in show IP route, you can see those static changes. The
thing about show commands is that it's static in nature, whereas debugs are real-time, dynamic,
it happens, boom, the message appears on the screen, letting you know that something has
changed, something has occurred. Remember that debugs invoke process switching. If you remember,
process switching involves the CPU. Since the CPU is involved, it will definitely slow down
our device's performance when it's all said and done. If I'm debugging packets, that means those
packets are going to be slowed down as the debugging is occurring. It's something that
you need to take into consideration before you use any type of debugs because turning on too
many at the same time could impact the performance of your device. If you accidentally leave debugs
enabled, it definitely could impact the performance of your device over time. It's
important that you always use debugs for a very specific purpose at a very specific point in time,
and you know the ramifications ahead of time of using that debug. Then as soon as you're done
getting the information you need, you shut it off with the undebug all command in privilege
exact mode. If you're in any other mode, just type in do undebug all, but there's a short form
for that. You can type in you all or do you all wherever you are, and that will do the exact same
thing. Cisco even warns you in a lot of their documentations that debugs are dangerous. Use
them with caution. Now, conditional debugs is really why we were having this discussion. It
provides debug filtering to limit the output that is generated. Now, you might be saying,
oh, you mean like that discriminator we talked about in our syslog discussion? No,
that's not what I'm talking about. This is something completely different. Now,
could we use a discriminator with our debugs? Absolutely, yes, and I gave you an example of
that in our syslog discussion, but now I want to talk about a different type of filtering option
we have called strictly conditional debugs. So, by typing in debug condition question mark in
privilege exact mode, notice that privilege exact mode, not global configuration mode,
you can see the different conditions that are supported on your particular device.
So, for example, let's do R1 today. On R1, let's type in debug IP. No, let's do debug
condition first. Debug condition. So, these are the different conditions that we have the
opportunity on this device to implement, which as you can see, this device had a whole lot more.
But some of the ones here we might want to debug based on just a specific interface or just a
specific IP address or just a specific MAC address or maybe just a specific VLAN or VRF. So, for
example, when I type in debug IP packet, then I am going to get a lot of debugging information
showing up on R1. Logging console 7, right? So, you see all these debug messages. Now,
when you look at this information, we could filter this with our debug condition command.
So, let me try and shut all this off right now. So, that way there we can type in our command
without being bombarded with those messages. Let's type in debug condition and our condition
we're going to specify is, let's say, interface. Let's go with just gigabit Ethernet 0 slash 0
slash 0 as an example. Now, if we type in debug IP packet before I hit enter, realize we were
getting debugs on 0 slash 1 and 0 slash 0, 0 slash 1 and 0 slash 0. But now watch what happens
when I type in debug IP packet. Because I have a condition set, it's only going to debug on that
condition. It's not going to debug on anything else. And so, if we remove that condition,
then it's going to go back to being normal, which is all interfaces in this case. Whereas,
in this case, my condition was only gig 0 0. So, let's try the IP address option instead. So,
let's do a you all here. And let's type in no debug condition. And it was number one. So,
let's remove that condition. Yes. All right. And now let's type in something like debug condition
IP. And let's do 224.0.0.5. So, what is that IP address? That is OSPF. So, let's just type in
debug IP packet now. And let's see if it does what I expect it to do. So, and now it's only
going to show me debugs that have the IP address 224.0.0.5 in them. So, that's all conditional
debugging is, folks. Conditional debugging is giving you the opportunity to set essentially a
filter for all debugs that happen. So, it doesn't matter whether it's debug IP packet or any other
type of debug. When that condition is set, it applies to any debug that you launch. So, be
mindful that if you launch a debug and you forgot that a condition was still enabled,
then you might not get the debug output you were expecting. So, for example, if you did debug – let's
say you're running EIGRP and OSPF on your device, but you had a condition that debug 224.0.0.5 only,
and you type in debug IP EIGRP packet or anything like that, well, you're not going to get any
messages because EIGRP doesn't use 224.0.0.5. So, that might be one of the reasons why all of a
sudden you're not getting your debug output. You have a debug condition that has been set. So,
here's an example of – like we did debug IP packet, and then we set up our condition,
and our condition was for that particular interface, and then only that particular
interface is showing up now. Okay? Now, ping. The tool that we can use to what? Test IP connectivity
between two devices. That's what it's used for in a general sense, but what else do we have the
ability to test as well? Well, we have with ping the ability to set a lot of different options
with an extended ping, and that gives us the ability to test different aspects of our network
along a particular path as an example. So, let's just go out to our device right now. We'll hit
up DSW1. For example, if I type in ping 8.8.8.8, everything about this ping now is using just
straight-up default ping values. So, it's using a very small packet size. It's using a timeout of
two seconds, but we have the ability with ping to manipulate a lot of those values. For example,
I could say ping size 1500 if I wanted to, and if I say ping size 1500, you'll see it still worked.
What did 1500 mean? 1500 bytes. If I type in ping size 1501, right, that still worked in this
particular case. Still worked in this particular case. Still worked in. Why is it working? Can
anybody tell me why it is working? Well, think about it. What is our maximum transmission unit?
What is our maximum transmission? It's only 1500, right? That's it. So, why in the world would a packet of
1501, 1502, 1503 successfully be transmitted through the network? That's right, because
fragmentation is occurring. That's right. Fragmentation is occurring. So, watch this.
If I say size 1500, but I say do not fragment. Do not fragment. Watch. That breaks down,
because now I'm saying I do not want fragmentation to occur. So, now 1503 is too big, because the
MTU of my interfaces are 1500. So, if you go back to 1501, you'll see it doesn't work. Why? Because
we got a fragment, because we're bigger than 1500. Maximum packet size. The MTU of any packet that
can go into an Ethernet frame is what? 1500. Remember that. So, we'll back up here. 1500.
You'll see now it works. But let's go over to somebody like R2 right now. We go over to R2.
Let's go to interface FastEthernet 0 size 0 size 0. Configure terminal interface FastEthernet
0 size 0 size 0. And I type in IP MTU 1476. All right. So, now if we go back to DSW1,
as we're going to the Internet here, you'll see that doesn't work anymore.
And the M means what? The M means could not fragment. See that? Could not fragment.
Could not fragment. All right. Who could not fragment? Some device along the path.
Now, you may be saying, whoa, whoa, whoa. How come we didn't get that message before, Raymond?
Because it was this device that was not able to fragment it. Because this device is interfaces,
DSW1, as it was trying to send it out the interface, it can't. So, it just is telling
me can't ping, can't ping, can't ping, can't ping, can't do it. Right? Whereas down here now,
it's actually able to get it all the way to somebody that somebody happens to be R2 in
this particular case. And in the end, right, tells me cannot fragment, cannot fragment,
cannot fragment. So, we know somewhere along the path, there is an MTU that is lower than 1500.
So, we could spend the time to try to figure that out by going 1499, 1498, 1497, right? But
there's a better way to do that. And that is just by doing an extended ping, for example. So,
if I ping using IP, what's the target IP address? Just do 88888 again.
Repeat count. I'll just do it once. And what is my size of my actual datagram? So, we said 1500.
That's not going to matter because I'm going to do a sweep of ranges here momentarily. So,
that 1500 is not going to matter. Timeout in seconds, we'll do two, the default.
Do I want extended commands? Yes. Source address or interface? Okay, doesn't matter in this case.
Service type, leave it at the default of zero. So, I don't want to care about quality of service
values in this one. Set do not fragment bit. Yes, set the do not fragment bit.
Validate data reply, no. Don't worry about the data pattern. Don't worry about this.
Sweep ranges, yes. Let's sweep from 1400 to 1500. That's what I want to do. Oops,
minimum size, 1400. Maximum size, 1500. We know 1500 doesn't work.
Sweep interval, okay. We'll do one at a time. And there you go. So, now you can see where it stopped.
Where the very first M is, that tells us the size because this first one would have been 1400,
1401, two, three, four, five, six, seven, eight, nine, da-da-da-da-da-da-da-da-da-da-da-da-da-da-da-da-da.
Right? So, you can count all of those. Absolutely, you can count all of those until you get all the
way around to the M and you would figure it out. Or you could look at this. There was a 76% rate,
so 77 of 101. 77 of 101. Why? Because we sent 1400, right? So, 1400 was our first one
that we actually sent. So, in the end, right, we can conclude that it's this number
minus one. This number minus one. So, it'd be 1476 would be the number because we got to count
zero, right? So, zero is one of those. So, 1476 counting zero along the path.
So, now, I know the minimum and 1476. So, now, we can do our test again this way.
And we could type in, for example, 1477, right? Doesn't work.
But you type in 1476. Oh, it works, right? So, you can figure out the MTU along the path
along the path by doing something like this. So, an extended ping with the do not fragment bit set.
The packet is too large for an interface. The MTU packet gets dropped.
And what is the result? M. So, if you ever see M, M, M, M, it means that the packet could not
be fragmented. And the MTU is lower than the size of the packet along that path somewhere.
So, exclamation mark means everything's okay. Period indicates the network server
timed out while waiting for a reply. So, ping didn't work.
Packet life exceeded. Could not fragment. Source quench. All right. So, the most important ones
there. Period, exclamation mark, M. Those are the ones I would worry about for the certification exam.
Traceroute. What does traceroute give us the ability to do? It gives us the ability to trace
the path that a particular packet takes through the network to get to a particular destination.
So, if we type in traceroute and we do 8.8.8.8, we'll see the path that we're taking. We're going
through 10, 40, 23.5, through 203.0, 113, 89 in order to get there. So, when we see our probes
here, you'll see that we had one that was zero milliseconds, eight milliseconds, eight milliseconds,
zero milliseconds, star. Okay, what does a millisecond mean, and what does star mean?
So, millisecond means for each node, the round trip time in milliseconds with a specified number
of the probe. So, that means it was a successful probe and we were able to calculate the time.
If you see a star, it just simply means the probe timed out. It means we sent the probe,
but it never came back to us in the specified amount of time. So, it may have come back like
a microsecond later or a millisecond later or a second later, but it's too late at that point
in time. So, the star doesn't necessarily mean it failed. The star simply means we didn't get
the response in the default allotted time that we wait for the response. That's all that means.
A, if you get an A, it means that there's an access control list in the way blocking
us from being able to use that. So, traceroute on our Cisco devices, I can't remember
the top of my head if it's using ICMP or UDP. Let's try this just quickly. IP access list
extended. We'll call it traceroute. Okay. Now, we're going to deny ICMP. Let's do any, any.
That would also block our pings as well, but that's okay for right now. And then,
permit IP any, any. Just doing a demo on the fly. May or may not work.
Interface gigabit ethernet 0 slash 1 IP access hyphen group traceroute
inbound. Let's do the same thing for 00 inbound. All right. Let's give this a try.
This is trying to do something off the top of my head. Let's see if it works.
It might be because it's using UDP. So, let's try this PC here for a second.
So, we go to this PC. Let's try a traceroute. Trace
Oops. Wrong button. Trace.
So, in this case, we're getting a destination network unreachable. So,
based on the access control list on our PC, we're getting a result on a PC of a destination network
unreachable because the ACL is blocking us. But it's not blocking. If you're wondering why it's
not blocking my router's trace, it's because the Cisco router is using UDP for ICMP and not
traceroute.
Sorry. I said that incorrectly. Cisco – the PC is using ICMP for traceroute,
whereas Cisco is using UDP for traceroute.
All right. So, deny UDP traceroute.
So, I'm just going to – I got to remind myself I have to look it up to see what exactly it is.
But what I'm going to do is I'm just going to modify our ACL here for a second.
I'm going to deny all UDP traffic. I'm going to do that.
And that will just allow us to do this example here so you can see the A's on the router.
So, IP access group. So, let's say deny – I need a sequence number here. So, we're going to do 5
deny UDP any any. So, obviously, it's not advisable in the real world because it's – I mean,
you're just blocking all UDP traffic. But I'm just doing this to try to get – show you that A
so you know what it means. So, do show access-list. So, UDP any any. So, that should block.
There you go. There's the A. Yay. All right. So, traceroute – Cisco traceroute uses UDP.
So, that's an example. Exclamation mark A, exclamation mark A, exclamation mark A.
All right. That is telling you that we got administratively prohibited. So,
it should actually be exclamation mark A on our Cisco devices and not just A. Oops. It's back up
there. So, think about it for a second. If I spent all that time, folks, trying to show you that,
there's a reason why I did that, right? So, I showed you that. I showed you that. I showed you
that. Why? I don't know. Maybe. Maybe you're going to need that. So, the other options here,
not really something that I'm worried about you knowing, but definitely those three, I think you
got yourself covered for traceroute for your Encore preparation. So, just keep that in mind
as you're reviewing. So, things I showed you in ping, keep them in mind. Things I showed you in
traceroute, keep in mind. Your conditional B bugs, keep that in mind as well when you review
for your certification exam.