WEBVTT 1 00:00.000 --> 00:05.160 Well, Traceroute is a mission critical tool. We're going to use this a lot in 2 00:05.160 --> 00:06.320 our troubleshooting, 3 00:06.320 --> 00:10.200 and a lot of us, when we're at this point in our career, studying for this exam 4 00:10.200 --> 00:12.960 , have probably already used Traceroute quite a few times. 5 00:12.960 --> 00:17.070 But let's make sure we understand exactly how it works, and for that matter, 6 00:17.070 --> 00:20.320 the different options that we have available to us when we're using it at the 7 00:20.320 --> 00:20.800 CLI. 8 00:20.800 --> 00:25.050 We can usually make our Traceroute a little bit more efficient if we use a 9 00:25.050 --> 00:26.400 certain set of options. 10 00:26.400 --> 00:30.950 So, first of all, how exactly it works? Well, the goal here is to track out the WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 10 00:26.400 --> 00:30.950 So, first of all, how exactly it works? Well, the goal here is to track out the 11 00:30.950 --> 00:34.600 different hops in the network that our packets take. 12 00:34.600 --> 00:39.170 And so we might look at this and say, "Well, I don't know if it takes Path A up 13 00:39.170 --> 00:41.200 here on top or Path B down here. 14 00:41.200 --> 00:45.970 I'm over here with my device, and I'm trying to get over here to this 15 00:45.970 --> 00:47.200 destination." 16 00:47.200 --> 00:52.780 So, I can use a Traceroute, and the Traceroute is going to go hop by hop and 17 00:52.780 --> 00:58.340 have each hop report back that it is indeed the one that is processing the ICMP 18 00:58.340 --> 01:00.200 packet that I'm sending. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 18 00:58.340 --> 01:00.200 packet that I'm sending. 19 01:00.200 --> 01:04.840 Now, the way we do this, the way we get these intermediary devices to report 20 01:04.840 --> 01:09.400 back is by setting the time to live in our ICMP message. 21 01:09.400 --> 01:15.430 So, I set a time to live of one, and what we get is we get a TTL expiration 22 01:15.430 --> 01:20.390 notice, meaning that the device in question, let's say this device here, my 23 01:20.390 --> 01:24.400 first hop, is going to receive my ICMP message and say, 24 01:24.400 --> 01:28.770 "Hey, the TTL, I'm decrementing it. It's zero. It's expired. I'm going to go 25 01:28.770 --> 01:34.400 ahead and alert you with an ICMP message back saying that the TTL has expired." WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 25 01:28.770 --> 01:34.400 ahead and alert you with an ICMP message back saying that the TTL has expired." 26 01:34.400 --> 01:39.400 Well, as part of the Traceroute process, my CPU, or my PC, or whatever I'm on, 27 01:39.400 --> 01:43.740 is processing that and keeping track of that and reporting back when those 28 01:43.740 --> 01:45.400 responses are received. 29 01:45.400 --> 01:50.930 And so, we set a TTL equal to one, then we set a TTL equal to two, and this is 30 01:50.930 --> 01:54.750 where we find out whether we took Path A or Path B, because if it got routed 31 01:54.750 --> 01:59.670 this way, then this top router is going to respond back, otherwise the bottom 32 01:59.670 --> 02:00.400 one will. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 32 01:59.670 --> 02:00.400 one will. 33 02:00.400 --> 02:05.090 Either way, we get that expiration notice. And so, I can start to see the 34 02:05.090 --> 02:10.340 different hops as this message progresses through, and as I importantly 35 02:10.340 --> 02:15.620 increment my time to live until I either reach the destination, or I reach a 36 02:15.620 --> 02:20.400 maximum hop count as configured according to the Traceroute tool. 37 02:20.400 --> 02:24.770 One other nice thing about the Traceroute is it does two things for us. First 38 02:24.770 --> 02:29.690 of all, it does show us the response time. We're keeping track of how long it 39 02:29.690 --> 02:33.400 took to get a response out of these different hops. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 39 02:29.690 --> 02:33.400 took to get a response out of these different hops. 40 02:33.400 --> 02:38.390 So, I can see that maybe this took 30 milliseconds or 110 milliseconds, 41 02:38.390 --> 02:40.400 something along those lines. 42 02:40.400 --> 02:46.420 Furthermore, it'll actually attempt to do a reverse DNS lookup, meaning I'm 43 02:46.420 --> 02:51.400 taking an IP address, and I'm converting it over to the actual DNS. 44 02:51.400 --> 02:56.850 So, maybe I get something that indicates to me that this is some kind of 45 02:56.850 --> 03:01.750 service provider one router, and maybe it's according to their domain or what WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 45 02:56.850 --> 03:01.750 service provider one router, and maybe it's according to their domain or what 46 03:01.750 --> 03:02.400 have you. 47 03:02.400 --> 03:06.580 So, it's possible that I can figure out, based on the reverse DNS lookup, 48 03:06.580 --> 03:10.990 whether this device that's responding to me belongs to one service provider or 49 03:10.990 --> 03:13.400 maybe a different service provider. 50 03:13.400 --> 03:18.460 But keep in mind, and the more we use Traceroute, the more familiar with this, 51 03:18.460 --> 03:20.400 this can take a lot of time. 52 03:20.400 --> 03:24.700 It can actually delay our Traceroute to the point that it takes a very long 53 03:24.700 --> 03:28.890 time to get responses back when really what we're interested in is just 54 03:28.890 --> 03:31.400 figuring out the path that is taken. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 54 03:28.890 --> 03:31.400 figuring out the path that is taken. 55 03:31.400 --> 03:35.150 And so, sometimes that's to our advantage that is doing reverse DNS, and 56 03:35.150 --> 03:36.400 sometimes it's not. 57 03:36.400 --> 03:42.150 Furthermore, it's going to do multiple probes per TTL. So, by default, with 58 03:42.150 --> 03:46.400 Cisco, we're going to do three probes at TTL of one. 59 03:46.400 --> 03:49.840 So, we're going to do one, two, three, and get three responses back all from 60 03:49.840 --> 03:53.670 the same device, keep in mind, unless something really weird is happening with 61 03:53.670 --> 03:56.470 the routing, and that could be the case if we're getting load balanced or 62 03:56.470 --> 03:57.400 something like that. 63 03:57.400 --> 04:01.920 But usually, it's going to come back from the same device, and so we do three WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 63 03:57.400 --> 04:01.920 But usually, it's going to come back from the same device, and so we do three 64 04:01.920 --> 04:03.400 probes at TTL of one. 65 04:03.400 --> 04:07.570 Well, then we're going to do three probes at TTL of two, so we get three 66 04:07.570 --> 04:09.400 responses back each time. 67 04:09.400 --> 04:14.660 So, all of these, well, at least the probes, the reverse DNS, the TTL, we have 68 04:14.660 --> 04:19.920 control over those settings when we're performing a Traceroute from the Cisco 69 04:19.920 --> 04:20.400 CLI. 70 04:20.400 --> 04:25.470 So, when we look at our different options that we can use when we're using Tr 71 04:25.470 --> 04:29.400 aceroute, it starts with probe. 72 04:29.400 --> 04:34.400 So, I can set the probe count on a per-hot basis, and this defaults to three. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 72 04:29.400 --> 04:34.400 So, I can set the probe count on a per-hot basis, and this defaults to three. 73 04:34.400 --> 04:38.480 So, if I were to set this, let's say two, one, or two, well, now I don't have 74 04:38.480 --> 04:42.400 as many probes and I don't have to wait as long at each hop. 75 04:42.400 --> 04:46.240 The downside is if that packet was eaten by the network, then I'm not going to 76 04:46.240 --> 04:50.760 get a response at all, but especially in a lot of enterprise networks, we don't 77 04:50.760 --> 04:52.400 have to worry about as many dropped packets. 78 04:52.400 --> 04:56.980 This can be really useful for trying to reduce the time it takes to Traceroute 79 04:56.980 --> 04:58.400 through the network. 80 04:58.400 --> 05:03.300 So, I also have the ability to control the TTL, and not just the TTL from a max WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 80 04:58.400 --> 05:03.300 So, I also have the ability to control the TTL, and not just the TTL from a max 81 05:03.300 --> 05:06.400 perspective, which, by the way, defaults to 30. 82 05:06.400 --> 05:11.240 Yes, it'll try to go to 30 different hops, but I can also set a minimum, which 83 05:11.240 --> 05:12.400 defaults to one. 84 05:12.400 --> 05:17.980 Now, if I set a different maximum, then, yeah, it's nice if I'm not getting any 85 05:17.980 --> 05:21.780 responses back, I don't want to have to wait for 30 different hops to resolve 86 05:21.780 --> 05:22.400 to nothing. 87 05:22.400 --> 05:26.400 And so, we might want to reduce this to something more realistic, like 10. 88 05:26.400 --> 05:30.810 But also, if I don't really care about getting a response from my default WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 88 05:26.400 --> 05:30.810 But also, if I don't really care about getting a response from my default 89 05:30.810 --> 05:34.800 gateway, because I know my default gateway is there, I could increase the 90 05:34.800 --> 05:36.400 minimum to two or three. 91 05:36.400 --> 05:41.040 And just to say, hey, I'm going to start with a TTL of two, meaning I'm going 92 05:41.040 --> 05:44.400 to immediately identify that second hop device. 93 05:44.400 --> 05:48.650 That's a pretty nifty feature that is something that doesn't get used a whole 94 05:48.650 --> 05:52.400 lot, but can definitely be useful in the right circumstance. 95 05:52.400 --> 05:56.400 We also have this option called numeric. 96 05:56.400 --> 06:00.100 On its own, it doesn't really indicate what's happening, but if we think about WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 96 05:56.400 --> 06:00.100 On its own, it doesn't really indicate what's happening, but if we think about 97 06:00.100 --> 06:06.520 it, what it's trying to indicate is that we care about an IP address and not a 98 06:06.520 --> 06:09.400 DNS domain lookup. 99 06:09.400 --> 06:15.400 This skips this lookup here that we just talked about. 100 06:15.400 --> 06:20.190 It cancels the need to try to perform that reverse DNS lookup, and therefore, 101 06:20.190 --> 06:23.400 it was only going to respond with IP addresses. 102 06:23.400 --> 06:29.400 This drastically speeds up our trace routes. 103 06:29.400 --> 06:32.760 It has the equivalent of the dash D option before doing trace routes from WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 103 06:29.400 --> 06:32.760 It has the equivalent of the dash D option before doing trace routes from 104 06:32.760 --> 06:33.400 Windows. 105 06:33.400 --> 06:38.460 So it basically removes the domain lookup, speeds things up, only returns IP 106 06:38.460 --> 06:43.130 addresses, but in a lot of situations when we're on the network, that's 107 06:43.130 --> 06:45.400 primarily what we care about, especially in enterprise networks. 108 06:45.400 --> 06:49.470 We don't necessarily need the domain name of every switch in layer three device 109 06:49.470 --> 06:51.400 , assuming they even have them. 110 06:51.400 --> 06:55.400 So here's a few options, probe TTL and numeric. 111 06:55.400 --> 06:57.400 We actually have a few others that I want to address. 112 06:57.400 --> 07:04.400 First of all, the source, which allows me to specify a source IP address. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 112 06:57.400 --> 07:04.400 First of all, the source, which allows me to specify a source IP address. 113 07:04.400 --> 07:14.400 So this is always going to choose the nearest or closest to destination. 114 07:14.400 --> 07:19.850 So in our diagram up here, if I were to, well, we said that this was a PC, let 115 07:19.850 --> 07:22.400 's say that I'm on a router here. 116 07:22.400 --> 07:26.400 So now this is a Cisco router, we'll call it router one. 117 07:26.400 --> 07:28.400 And maybe there's a network behind it. 118 07:28.400 --> 07:32.160 So if I perform a trace route, in the same way that I perform, if I were to WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 118 07:28.400 --> 07:32.160 So if I perform a trace route, in the same way that I perform, if I were to 119 07:32.160 --> 07:37.410 perform a ping, it's going to look at the routing table, see this destination, 120 07:37.410 --> 07:42.460 it lives out this interface, and it's going to use that as the source IP 121 07:42.460 --> 07:43.400 address. 122 07:43.400 --> 07:46.400 Well, I can specify that I want to use a different source. 123 07:46.400 --> 07:50.050 Sometimes we call these extended pings or extended trace routes, because we're 124 07:50.050 --> 07:51.400 using extended options. 125 07:51.400 --> 07:56.040 So instead of specifying a source IP address or allowing the system to decide 126 07:56.040 --> 07:59.400 it, I could specify a source address back here. 127 07:59.400 --> 08:00.400 What does that do for me? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 127 07:59.400 --> 08:00.400 What does that do for me? 128 08:00.400 --> 08:06.400 Well, it tells me whether this next hop has a route back to that IP address. 129 08:06.400 --> 08:09.400 And for that matter, every other hop in the path. 130 08:09.400 --> 08:13.880 And so naturally, the upstream device will have a path back to the interface 131 08:13.880 --> 08:15.400 that it's connecting to. 132 08:15.400 --> 08:19.400 That's just the nature of layer three links. 133 08:19.400 --> 08:23.400 But does it have a path back to the route that's behind this router? 134 08:23.400 --> 08:27.400 And that will tell me a lot about whether the routing is working. 135 08:27.400 --> 08:31.400 So this is absolutely a great tool, not just from a trace route perspective, WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 135 08:27.400 --> 08:31.400 So this is absolutely a great tool, not just from a trace route perspective, 136 08:31.400 --> 08:36.390 but also from a ping perspective to make sure that different devices in the 137 08:36.390 --> 08:39.400 network path can get to specific routes. 138 08:39.400 --> 08:43.400 So from here, I have a couple of other options that are good to know. 139 08:43.400 --> 08:46.400 DSCP, which defaults to zero. 140 08:46.400 --> 08:48.400 And I wonky bracket here. 141 08:48.400 --> 08:53.810 But the DSCP value I could set if I want to test, maybe see if this packet is 142 08:53.810 --> 08:55.400 landing in the right queues. 143 08:55.400 --> 08:57.400 This is especially useful in pings. 144 08:57.400 --> 09:02.400 But since trace routes also use ICMP messages, it accomplishes the same thing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 144 08:57.400 --> 09:02.400 But since trace routes also use ICMP messages, it accomplishes the same thing. 145 09:02.400 --> 09:07.030 So I can make sure, for example, that if I've got something crazy where my DSCP 146 09:07.030 --> 09:12.270 -EFs are supposed to go this way, then I could confirm that they're going that 147 09:12.270 --> 09:15.400 way by specifying the DSCP value here. 148 09:15.400 --> 09:19.400 And then lastly, I also have a VRF option. 149 09:19.400 --> 09:23.400 So the VRF is going to assume the default VRF. 150 09:23.400 --> 09:29.400 And this can absolutely get us into trouble if we have multiple VRFs. 151 09:29.400 --> 09:33.590 And we think we're pinging or trace routing within one VRF and we really need WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 151 09:29.400 --> 09:33.590 And we think we're pinging or trace routing within one VRF and we really need 152 09:33.590 --> 09:35.400 to specify the correct VRF. 153 09:35.400 --> 09:41.420 So if we do have multiple VRFs, and for that matter, if we have management VRFs 154 09:41.420 --> 09:44.400 , which a lot of Cisco devices are starting to have management VRFs for out of 155 09:44.400 --> 09:44.400 band, 156 09:44.400 --> 09:49.020 management ports, it's one thing if I want to do a ping, I'm probably not trace 157 09:49.020 --> 09:50.400 routing from the management port too often. 158 09:50.400 --> 09:55.100 But if I do need to use the management interface, in that case, I would need to 159 09:55.100 --> 09:56.400 specify the VRF. 160 09:56.400 --> 10:01.520 So all of these options have the ability to be used simply with the trace route WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 160 09:56.400 --> 10:01.520 So all of these options have the ability to be used simply with the trace route 161 10:01.520 --> 10:02.400 command. 162 10:02.400 --> 10:04.400 I can type in trace route. 163 10:04.400 --> 10:09.400 And then, for example, I could specify probe one. 164 10:09.400 --> 10:15.400 But I can also, rather than doing that, I can just say enter here. 165 10:15.400 --> 10:21.900 So to do my enter command, and then rather than specifying an IP address, Cisco 166 10:21.900 --> 10:25.400 's CLI recognizes, "Hey, you just say enter on trace route." 167 10:25.400 --> 10:29.400 So now it's going to ask us, "Hey, how many probes do you want?" 168 10:29.400 --> 10:31.400 "Hey, what's the TTL that you want to use?" WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 168 10:29.400 --> 10:31.400 "Hey, what's the TTL that you want to use?" 169 10:31.400 --> 10:33.400 You know, and so on and so forth. 170 10:33.400 --> 10:37.520 And so that's the concept of the extended trace route, which we can use to our 171 10:37.520 --> 10:38.400 advantage. 172 10:38.400 --> 10:43.280 So if we want the speediest, fastest version of trace route, we'd probably want 173 10:43.280 --> 10:46.400 to perform a trace route with a, 174 10:46.400 --> 10:52.400 we'd specify maybe the IP address of 10.0.0.1 or whatever this is. 175 10:52.400 --> 10:59.400 And then I could say probe, probe one, and then specify numeric. 176 10:59.400 --> 11:04.030 That'll make it so that we only have a single probe at each hop, and that it's WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 176 10:59.400 --> 11:04.030 That'll make it so that we only have a single probe at each hop, and that it's 177 11:04.030 --> 11:07.400 numeric, and we can even manipulate the time to live if we so desire. 178 11:07.400 --> 11:09.400 Oh, and one last thing, by the way. 179 11:09.400 --> 11:13.400 We mentioned that we have a max TTL of 30. 180 11:13.400 --> 11:17.800 Well, if we do a trace route in the wrong direction, and we start getting these 181 11:17.800 --> 11:19.400 asterisks for all of our probes, 182 11:19.400 --> 11:22.400 asterisks, meaning I'm not getting a response. 183 11:22.400 --> 11:28.250 So my TTL of one here, got nothing, my TTL two, got nothing, and it's trying to 184 11:28.250 --> 11:29.400 do reverse DNS lookups, 185 11:29.400 --> 11:32.400 and it's just waiting for all these responses. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 185 11:29.400 --> 11:32.400 and it's just waiting for all these responses. 186 11:32.400 --> 11:34.400 This can take a long time to get to 30. 187 11:34.400 --> 11:40.400 Well, fortunately, Cisco does give us a break command in the CLI, and it is 188 11:40.400 --> 11:43.400 control shift six. 189 11:43.400 --> 11:49.400 Kind of an interesting combination of characters here, but if we enter that, 190 11:49.400 --> 11:51.400 then we can stop the probe. 191 11:51.400 --> 11:54.400 And by the way, that works well for pings as well. 192 11:54.400 --> 11:59.630 We can break out of that and hopefully not have to sit there for five or ten 193 11:59.630 --> 12:03.400 minutes while it actually tries to wrap up the trace route. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000 193 11:59.630 --> 12:03.400 minutes while it actually tries to wrap up the trace route. 194 12:03.400 --> 12:05.260 route that's clearly going nowhere.