WEBVTT 00:00:00.000 --> 00:00:12.520 This discussion on Debugs, Conditional Debugs, Ping and Trace are purely exam related. We 00:00:12.520 --> 00:00:23.120 are just going to stick to that level of detail. Debugs are what? They are a type of syslog 00:00:23.120 --> 00:00:30.360 message. That's what they are. They are a type of syslog message that is going to show us real 00:00:30.360 --> 00:00:39.280 time changes as they occur on our device. Compare that to show commands. Show commands are a 00:00:39.280 --> 00:00:47.080 snapshot in time, meaning that when you type in show, for example, run, you're seeing a snapshot 00:00:47.200 --> 00:00:53.040 of the running config at that moment in time. Any changes that are made, you're not updated 00:00:53.040 --> 00:00:57.520 about those changes unless you type in show run again and you look for any changes that had 00:00:57.520 --> 00:01:04.120 occurred. It would be the same thing with show VLAN brief. You look at show VLAN brief. You 00:01:04.120 --> 00:01:09.400 see that snapshot of what's there. If somebody adds a bunch of VLANs and you don't know that, 00:01:09.440 --> 00:01:18.280 you're not going to know about those VLANs being added. Why? Because you need to type in show VLAN 00:01:18.280 --> 00:01:26.560 brief again. Debugs allow you to keep track of those changes that happen in real time. By default, 00:01:26.560 --> 00:01:33.480 they're sent to the console port, the monitor port, so your VTY lines in addition to your RAM. 00:01:33.480 --> 00:01:39.080 In regards to the monitor port, just remember from our syslog discussion that if you are 00:01:39.080 --> 00:01:46.160 telnetted into a device or SSHed into a device, then you also need to type in the terminal monitor 00:01:46.160 --> 00:01:52.400 command if you want to see those debug messages, those syslog messages. The problem with debugs, 00:01:52.400 --> 00:01:57.360 though, is they're very, very resource intensive. Although it's nice to get details in real time, 00:01:57.360 --> 00:02:05.680 it's very resource intensive for our devices to work with those debugs. Here's an example of 00:02:05.680 --> 00:02:10.720 something like show IP route. A show IP route gives me a snapshot of the routing table at 00:02:10.720 --> 00:02:14.440 that moment in time. If all of a sudden my dynamic routing protocol made some changes, 00:02:14.440 --> 00:02:20.680 I would not know that unless I typed in show IP route again. Something like debug IP routing would 00:02:20.680 --> 00:02:24.880 actually show me the adds, the deletes, and the changes in the routing table in real time. In 00:02:24.880 --> 00:02:29.560 this particular case, I've turned on debug IP routing, and we can see that EIGRP has made some 00:02:29.560 --> 00:02:36.840 changes to our routing table. By typing in show IP route, you can see those static changes. The 00:02:36.840 --> 00:02:41.920 thing about show commands is that it's static in nature, whereas debugs are real-time, dynamic, 00:02:41.920 --> 00:02:44.840 it happens, boom, the message appears on the screen, letting you know that something has 00:02:44.840 --> 00:02:49.520 changed, something has occurred. Remember that debugs invoke process switching. If you remember, 00:02:49.520 --> 00:02:54.320 process switching involves the CPU. Since the CPU is involved, it will definitely slow down 00:02:54.480 --> 00:03:00.760 our device's performance when it's all said and done. If I'm debugging packets, that means those 00:03:00.760 --> 00:03:08.680 packets are going to be slowed down as the debugging is occurring. It's something that 00:03:08.680 --> 00:03:14.800 you need to take into consideration before you use any type of debugs because turning on too 00:03:14.800 --> 00:03:21.240 many at the same time could impact the performance of your device. If you accidentally leave debugs 00:03:21.280 --> 00:03:26.120 enabled, it definitely could impact the performance of your device over time. It's 00:03:26.120 --> 00:03:32.440 important that you always use debugs for a very specific purpose at a very specific point in time, 00:03:32.440 --> 00:03:36.960 and you know the ramifications ahead of time of using that debug. Then as soon as you're done 00:03:36.960 --> 00:03:43.160 getting the information you need, you shut it off with the undebug all command in privilege 00:03:43.640 --> 00:03:52.800 exact mode. If you're in any other mode, just type in do undebug all, but there's a short form 00:03:52.800 --> 00:03:58.000 for that. You can type in you all or do you all wherever you are, and that will do the exact same 00:03:58.000 --> 00:04:06.800 thing. Cisco even warns you in a lot of their documentations that debugs are dangerous. Use 00:04:06.800 --> 00:04:15.680 them with caution. Now, conditional debugs is really why we were having this discussion. It 00:04:15.680 --> 00:04:22.000 provides debug filtering to limit the output that is generated. Now, you might be saying, 00:04:22.000 --> 00:04:25.960 oh, you mean like that discriminator we talked about in our syslog discussion? No, 00:04:25.960 --> 00:04:30.480 that's not what I'm talking about. This is something completely different. Now, 00:04:30.680 --> 00:04:39.120 could we use a discriminator with our debugs? Absolutely, yes, and I gave you an example of 00:04:39.120 --> 00:04:46.080 that in our syslog discussion, but now I want to talk about a different type of filtering option 00:04:46.080 --> 00:04:54.200 we have called strictly conditional debugs. So, by typing in debug condition question mark in 00:04:54.200 --> 00:04:58.080 privilege exact mode, notice that privilege exact mode, not global configuration mode, 00:04:58.600 --> 00:05:04.400 you can see the different conditions that are supported on your particular device. 00:05:04.400 --> 00:05:19.280 So, for example, let's do R1 today. On R1, let's type in debug IP. No, let's do debug 00:05:19.280 --> 00:05:27.480 condition first. Debug condition. So, these are the different conditions that we have the 00:05:27.520 --> 00:05:33.080 opportunity on this device to implement, which as you can see, this device had a whole lot more. 00:05:33.080 --> 00:05:40.200 But some of the ones here we might want to debug based on just a specific interface or just a 00:05:40.200 --> 00:05:48.120 specific IP address or just a specific MAC address or maybe just a specific VLAN or VRF. So, for 00:05:48.120 --> 00:05:57.160 example, when I type in debug IP packet, then I am going to get a lot of debugging information 00:05:57.320 --> 00:06:09.960 showing up on R1. Logging console 7, right? So, you see all these debug messages. Now, 00:06:09.960 --> 00:06:16.160 when you look at this information, we could filter this with our debug condition command. 00:06:16.160 --> 00:06:21.240 So, let me try and shut all this off right now. So, that way there we can type in our command 00:06:21.360 --> 00:06:29.400 without being bombarded with those messages. Let's type in debug condition and our condition 00:06:29.400 --> 00:06:35.680 we're going to specify is, let's say, interface. Let's go with just gigabit Ethernet 0 slash 0 00:06:35.680 --> 00:06:46.280 slash 0 as an example. Now, if we type in debug IP packet before I hit enter, realize we were 00:06:46.280 --> 00:06:54.280 getting debugs on 0 slash 1 and 0 slash 0, 0 slash 1 and 0 slash 0. But now watch what happens 00:06:54.280 --> 00:07:02.240 when I type in debug IP packet. Because I have a condition set, it's only going to debug on that 00:07:02.240 --> 00:07:09.800 condition. It's not going to debug on anything else. And so, if we remove that condition, 00:07:09.800 --> 00:07:15.240 then it's going to go back to being normal, which is all interfaces in this case. Whereas, 00:07:15.240 --> 00:07:22.080 in this case, my condition was only gig 0 0. So, let's try the IP address option instead. So, 00:07:22.080 --> 00:07:32.800 let's do a you all here. And let's type in no debug condition. And it was number one. So, 00:07:32.800 --> 00:07:39.880 let's remove that condition. Yes. All right. And now let's type in something like debug condition 00:07:39.880 --> 00:07:50.720 IP. And let's do 224.0.0.5. So, what is that IP address? That is OSPF. So, let's just type in 00:07:50.720 --> 00:07:57.520 debug IP packet now. And let's see if it does what I expect it to do. So, and now it's only 00:07:57.520 --> 00:08:05.640 going to show me debugs that have the IP address 224.0.0.5 in them. So, that's all conditional 00:08:05.640 --> 00:08:12.600 debugging is, folks. Conditional debugging is giving you the opportunity to set essentially a 00:08:12.600 --> 00:08:20.560 filter for all debugs that happen. So, it doesn't matter whether it's debug IP packet or any other 00:08:20.560 --> 00:08:30.640 type of debug. When that condition is set, it applies to any debug that you launch. So, be 00:08:30.640 --> 00:08:36.640 mindful that if you launch a debug and you forgot that a condition was still enabled, 00:08:36.640 --> 00:08:44.560 then you might not get the debug output you were expecting. So, for example, if you did debug – let's 00:08:44.560 --> 00:08:49.680 say you're running EIGRP and OSPF on your device, but you had a condition that debug 224.0.0.5 only, 00:08:49.680 --> 00:08:55.720 and you type in debug IP EIGRP packet or anything like that, well, you're not going to get any 00:08:55.720 --> 00:09:01.280 messages because EIGRP doesn't use 224.0.0.5. So, that might be one of the reasons why all of a 00:09:01.280 --> 00:09:06.560 sudden you're not getting your debug output. You have a debug condition that has been set. So, 00:09:06.560 --> 00:09:10.680 here's an example of – like we did debug IP packet, and then we set up our condition, 00:09:10.680 --> 00:09:14.200 and our condition was for that particular interface, and then only that particular 00:09:14.280 --> 00:09:34.160 interface is showing up now. Okay? Now, ping. The tool that we can use to what? Test IP connectivity 00:09:34.200 --> 00:09:44.000 between two devices. That's what it's used for in a general sense, but what else do we have the 00:09:44.000 --> 00:09:49.160 ability to test as well? Well, we have with ping the ability to set a lot of different options 00:09:49.160 --> 00:09:57.760 with an extended ping, and that gives us the ability to test different aspects of our network 00:09:57.760 --> 00:10:03.120 along a particular path as an example. So, let's just go out to our device right now. We'll hit 00:10:03.120 --> 00:10:11.880 up DSW1. For example, if I type in ping 8.8.8.8, everything about this ping now is using just 00:10:11.880 --> 00:10:19.160 straight-up default ping values. So, it's using a very small packet size. It's using a timeout of 00:10:19.160 --> 00:10:26.000 two seconds, but we have the ability with ping to manipulate a lot of those values. For example, 00:10:26.000 --> 00:10:34.280 I could say ping size 1500 if I wanted to, and if I say ping size 1500, you'll see it still worked. 00:10:34.280 --> 00:10:40.920 What did 1500 mean? 1500 bytes. If I type in ping size 1501, right, that still worked in this 00:10:40.920 --> 00:10:46.840 particular case. Still worked in this particular case. Still worked in. Why is it working? Can 00:10:46.840 --> 00:10:52.800 anybody tell me why it is working? Well, think about it. What is our maximum transmission unit? 00:10:52.800 --> 00:10:59.840 What is our maximum transmission? It's only 1500, right? That's it. So, why in the world would a packet of 00:10:59.840 --> 00:11:06.720 1501, 1502, 1503 successfully be transmitted through the network? That's right, because 00:11:06.720 --> 00:11:11.040 fragmentation is occurring. That's right. Fragmentation is occurring. So, watch this. 00:11:11.040 --> 00:11:16.800 If I say size 1500, but I say do not fragment. Do not fragment. Watch. That breaks down, 00:11:16.800 --> 00:11:23.920 because now I'm saying I do not want fragmentation to occur. So, now 1503 is too big, because the 00:11:23.920 --> 00:11:31.280 MTU of my interfaces are 1500. So, if you go back to 1501, you'll see it doesn't work. Why? Because 00:11:31.280 --> 00:11:38.520 we got a fragment, because we're bigger than 1500. Maximum packet size. The MTU of any packet that 00:11:38.520 --> 00:11:44.760 can go into an Ethernet frame is what? 1500. Remember that. So, we'll back up here. 1500. 00:11:45.240 --> 00:11:50.280 You'll see now it works. But let's go over to somebody like R2 right now. We go over to R2. 00:11:50.840 --> 00:12:01.720 Let's go to interface FastEthernet 0 size 0 size 0. Configure terminal interface FastEthernet 00:12:01.720 --> 00:12:10.440 0 size 0 size 0. And I type in IP MTU 1476. All right. So, now if we go back to DSW1, 00:12:10.440 --> 00:12:14.200 as we're going to the Internet here, you'll see that doesn't work anymore. 00:12:14.760 --> 00:12:20.520 And the M means what? The M means could not fragment. See that? Could not fragment. 00:12:21.480 --> 00:12:28.200 Could not fragment. All right. Who could not fragment? Some device along the path. 00:12:28.760 --> 00:12:32.520 Now, you may be saying, whoa, whoa, whoa. How come we didn't get that message before, Raymond? 00:12:34.120 --> 00:12:41.320 Because it was this device that was not able to fragment it. Because this device is interfaces, 00:12:41.320 --> 00:12:45.640 DSW1, as it was trying to send it out the interface, it can't. So, it just is telling 00:12:45.640 --> 00:12:50.200 me can't ping, can't ping, can't ping, can't ping, can't do it. Right? Whereas down here now, 00:12:50.840 --> 00:12:54.760 it's actually able to get it all the way to somebody that somebody happens to be R2 in 00:12:54.760 --> 00:13:01.160 this particular case. And in the end, right, tells me cannot fragment, cannot fragment, 00:13:01.720 --> 00:13:09.720 cannot fragment. So, we know somewhere along the path, there is an MTU that is lower than 1500. 00:13:09.720 --> 00:13:20.760 So, we could spend the time to try to figure that out by going 1499, 1498, 1497, right? But 00:13:22.200 --> 00:13:26.200 there's a better way to do that. And that is just by doing an extended ping, for example. So, 00:13:26.200 --> 00:13:30.840 if I ping using IP, what's the target IP address? Just do 88888 again. 00:13:31.720 --> 00:13:39.720 Repeat count. I'll just do it once. And what is my size of my actual datagram? So, we said 1500. 00:13:39.720 --> 00:13:42.440 That's not going to matter because I'm going to do a sweep of ranges here momentarily. So, 00:13:42.440 --> 00:13:46.280 that 1500 is not going to matter. Timeout in seconds, we'll do two, the default. 00:13:47.080 --> 00:13:53.880 Do I want extended commands? Yes. Source address or interface? Okay, doesn't matter in this case. 00:13:55.160 --> 00:13:59.800 Service type, leave it at the default of zero. So, I don't want to care about quality of service 00:14:00.760 --> 00:14:06.520 values in this one. Set do not fragment bit. Yes, set the do not fragment bit. 00:14:07.960 --> 00:14:12.280 Validate data reply, no. Don't worry about the data pattern. Don't worry about this. 00:14:13.000 --> 00:14:20.680 Sweep ranges, yes. Let's sweep from 1400 to 1500. That's what I want to do. Oops, 00:14:20.680 --> 00:14:26.280 minimum size, 1400. Maximum size, 1500. We know 1500 doesn't work. 00:14:27.160 --> 00:14:32.760 Sweep interval, okay. We'll do one at a time. And there you go. So, now you can see where it stopped. 00:14:34.920 --> 00:14:40.760 Where the very first M is, that tells us the size because this first one would have been 1400, 00:14:41.640 --> 00:14:48.200 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. 00:14:48.200 --> 00:14:53.720 Right? So, you can count all of those. Absolutely, you can count all of those until you get all the 00:14:54.600 --> 00:15:00.040 way around to the M and you would figure it out. Or you could look at this. There was a 76% rate, 00:15:00.040 --> 00:15:13.560 so 77 of 101. 77 of 101. Why? Because we sent 1400, right? So, 1400 was our first one 00:15:14.120 --> 00:15:24.760 that we actually sent. So, in the end, right, we can conclude that it's this number 00:15:25.560 --> 00:15:33.400 minus one. This number minus one. So, it'd be 1476 would be the number because we got to count 00:15:33.400 --> 00:15:40.040 zero, right? So, zero is one of those. So, 1476 counting zero along the path. 00:15:40.120 --> 00:15:46.120 So, now, I know the minimum and 1476. So, now, we can do our test again this way. 00:15:48.920 --> 00:15:53.880 And we could type in, for example, 1477, right? Doesn't work. 00:15:57.000 --> 00:16:04.600 But you type in 1476. Oh, it works, right? So, you can figure out the MTU along the path 00:16:04.680 --> 00:16:11.640 along the path by doing something like this. So, an extended ping with the do not fragment bit set. 00:16:13.880 --> 00:16:18.600 The packet is too large for an interface. The MTU packet gets dropped. 00:16:21.160 --> 00:16:28.600 And what is the result? M. So, if you ever see M, M, M, M, it means that the packet could not 00:16:28.600 --> 00:16:35.320 be fragmented. And the MTU is lower than the size of the packet along that path somewhere. 00:16:36.040 --> 00:16:39.960 So, exclamation mark means everything's okay. Period indicates the network server 00:16:39.960 --> 00:16:42.680 timed out while waiting for a reply. So, ping didn't work. 00:16:48.760 --> 00:16:56.600 Packet life exceeded. Could not fragment. Source quench. All right. So, the most important ones 00:16:56.600 --> 00:17:04.360 there. Period, exclamation mark, M. Those are the ones I would worry about for the certification exam. 00:17:14.600 --> 00:17:19.480 Traceroute. What does traceroute give us the ability to do? It gives us the ability to trace 00:17:19.480 --> 00:17:24.040 the path that a particular packet takes through the network to get to a particular destination. 00:17:24.040 --> 00:17:29.000 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 00:17:29.000 --> 00:17:39.640 through 10, 40, 23.5, through 203.0, 113, 89 in order to get there. So, when we see our probes 00:17:39.640 --> 00:17:45.320 here, you'll see that we had one that was zero milliseconds, eight milliseconds, eight milliseconds, 00:17:45.320 --> 00:17:51.240 zero milliseconds, star. Okay, what does a millisecond mean, and what does star mean? 00:17:51.960 --> 00:17:56.440 So, millisecond means for each node, the round trip time in milliseconds with a specified number 00:17:56.440 --> 00:18:00.360 of the probe. So, that means it was a successful probe and we were able to calculate the time. 00:18:00.360 --> 00:18:03.640 If you see a star, it just simply means the probe timed out. It means we sent the probe, 00:18:03.640 --> 00:18:09.400 but it never came back to us in the specified amount of time. So, it may have come back like 00:18:09.400 --> 00:18:15.000 a microsecond later or a millisecond later or a second later, but it's too late at that point 00:18:15.000 --> 00:18:20.920 in time. So, the star doesn't necessarily mean it failed. The star simply means we didn't get 00:18:20.920 --> 00:18:27.720 the response in the default allotted time that we wait for the response. That's all that means. 00:18:29.400 --> 00:18:35.160 A, if you get an A, it means that there's an access control list in the way blocking 00:18:35.160 --> 00:18:41.000 us from being able to use that. So, traceroute on our Cisco devices, I can't remember 00:18:41.640 --> 00:18:58.440 the top of my head if it's using ICMP or UDP. Let's try this just quickly. IP access list 00:18:59.240 --> 00:19:14.200 extended. We'll call it traceroute. Okay. Now, we're going to deny ICMP. Let's do any, any. 00:19:14.200 --> 00:19:24.440 That would also block our pings as well, but that's okay for right now. And then, 00:19:28.440 --> 00:19:36.440 permit IP any, any. Just doing a demo on the fly. May or may not work. 00:19:38.760 --> 00:19:50.600 Interface gigabit ethernet 0 slash 1 IP access hyphen group traceroute 00:19:50.760 --> 00:20:01.000 inbound. Let's do the same thing for 00 inbound. All right. Let's give this a try. 00:20:01.000 --> 00:20:03.240 This is trying to do something off the top of my head. Let's see if it works. 00:20:06.600 --> 00:20:13.080 It might be because it's using UDP. So, let's try this PC here for a second. 00:20:14.840 --> 00:20:17.560 So, we go to this PC. Let's try a traceroute. Trace 00:20:21.080 --> 00:20:24.760 Oops. Wrong button. Trace. 00:20:39.000 --> 00:20:43.000 So, in this case, we're getting a destination network unreachable. So, 00:20:43.000 --> 00:20:49.320 based on the access control list on our PC, we're getting a result on a PC of a destination network 00:20:49.320 --> 00:20:55.320 unreachable because the ACL is blocking us. But it's not blocking. If you're wondering why it's 00:20:55.320 --> 00:21:03.080 not blocking my router's trace, it's because the Cisco router is using UDP for ICMP and not 00:21:06.600 --> 00:21:07.320 traceroute. 00:21:07.320 --> 00:21:20.520 Sorry. I said that incorrectly. Cisco – the PC is using ICMP for traceroute, 00:21:20.520 --> 00:21:22.840 whereas Cisco is using UDP for traceroute. 00:21:37.320 --> 00:21:45.320 All right. So, deny UDP traceroute. 00:22:07.320 --> 00:22:20.360 So, I'm just going to – I got to remind myself I have to look it up to see what exactly it is. 00:22:20.360 --> 00:22:23.160 But what I'm going to do is I'm just going to modify our ACL here for a second. 00:22:23.720 --> 00:22:26.360 I'm going to deny all UDP traffic. I'm going to do that. 00:22:28.920 --> 00:22:32.840 And that will just allow us to do this example here so you can see the A's on the router. 00:22:33.720 --> 00:22:43.560 So, IP access group. So, let's say deny – I need a sequence number here. So, we're going to do 5 00:22:44.200 --> 00:22:49.880 deny UDP any any. So, obviously, it's not advisable in the real world because it's – I mean, 00:22:49.880 --> 00:22:54.040 you're just blocking all UDP traffic. But I'm just doing this to try to get – show you that A 00:22:54.040 --> 00:23:01.720 so you know what it means. So, do show access-list. So, UDP any any. So, that should block. 00:23:03.720 --> 00:23:08.920 There you go. There's the A. Yay. All right. So, traceroute – Cisco traceroute uses UDP. 00:23:08.920 --> 00:23:12.440 So, that's an example. Exclamation mark A, exclamation mark A, exclamation mark A. 00:23:13.240 --> 00:23:17.560 All right. That is telling you that we got administratively prohibited. So, 00:23:17.560 --> 00:23:23.640 it should actually be exclamation mark A on our Cisco devices and not just A. Oops. It's back up 00:23:23.640 --> 00:23:29.640 there. So, think about it for a second. If I spent all that time, folks, trying to show you that, 00:23:29.640 --> 00:23:34.760 there's a reason why I did that, right? So, I showed you that. I showed you that. I showed you 00:23:34.760 --> 00:23:43.160 that. Why? I don't know. Maybe. Maybe you're going to need that. So, the other options here, 00:23:44.200 --> 00:23:49.960 not really something that I'm worried about you knowing, but definitely those three, I think you 00:23:49.960 --> 00:23:54.360 got yourself covered for traceroute for your Encore preparation. So, just keep that in mind 00:23:54.360 --> 00:23:58.040 as you're reviewing. So, things I showed you in ping, keep them in mind. Things I showed you in 00:23:58.040 --> 00:24:03.560 traceroute, keep in mind. Your conditional B bugs, keep that in mind as well when you review 00:24:03.560 --> 00:24:05.000 for your certification exam.