Well, Traceroute is a mission critical tool. We're going to use this a lot in
our troubleshooting,
and a lot of us, when we're at this point in our career, studying for this exam
, have probably already used Traceroute quite a few times.
But let's make sure we understand exactly how it works, and for that matter,
the different options that we have available to us when we're using it at the
CLI.
We can usually make our Traceroute a little bit more efficient if we use a
certain set of options.
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
So, first of all, how exactly it works? Well, the goal here is to track out the
different hops in the network that our packets take.
And so we might look at this and say, "Well, I don't know if it takes Path A up
here on top or Path B down here.
I'm over here with my device, and I'm trying to get over here to this
destination."
So, I can use a Traceroute, and the Traceroute is going to go hop by hop and
have each hop report back that it is indeed the one that is processing the ICMP
packet that I'm sending. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
packet that I'm sending.
Now, the way we do this, the way we get these intermediary devices to report
back is by setting the time to live in our ICMP message.
So, I set a time to live of one, and what we get is we get a TTL expiration
notice, meaning that the device in question, let's say this device here, my
first hop, is going to receive my ICMP message and say,
"Hey, the TTL, I'm decrementing it. It's zero. It's expired. I'm going to go
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
ahead and alert you with an ICMP message back saying that the TTL has expired."
Well, as part of the Traceroute process, my CPU, or my PC, or whatever I'm on,
is processing that and keeping track of that and reporting back when those
responses are received.
And so, we set a TTL equal to one, then we set a TTL equal to two, and this is
where we find out whether we took Path A or Path B, because if it got routed
this way, then this top router is going to respond back, otherwise the bottom
one will. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
one will.
Either way, we get that expiration notice. And so, I can start to see the
different hops as this message progresses through, and as I importantly
increment my time to live until I either reach the destination, or I reach a
maximum hop count as configured according to the Traceroute tool.
One other nice thing about the Traceroute is it does two things for us. First
of all, it does show us the response time. We're keeping track of how long it
took to get a response out of these different hops. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
took to get a response out of these different hops.
So, I can see that maybe this took 30 milliseconds or 110 milliseconds,
something along those lines.
Furthermore, it'll actually attempt to do a reverse DNS lookup, meaning I'm
taking an IP address, and I'm converting it over to the actual DNS.
So, maybe I get something that indicates to me that this is some kind of
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
service provider one router, and maybe it's according to their domain or what
have you.
So, it's possible that I can figure out, based on the reverse DNS lookup,
whether this device that's responding to me belongs to one service provider or
maybe a different service provider.
But keep in mind, and the more we use Traceroute, the more familiar with this,
this can take a lot of time.
It can actually delay our Traceroute to the point that it takes a very long
time to get responses back when really what we're interested in is just
figuring out the path that is taken. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
figuring out the path that is taken.
And so, sometimes that's to our advantage that is doing reverse DNS, and
sometimes it's not.
Furthermore, it's going to do multiple probes per TTL. So, by default, with
Cisco, we're going to do three probes at TTL of one.
So, we're going to do one, two, three, and get three responses back all from
the same device, keep in mind, unless something really weird is happening with
the routing, and that could be the case if we're getting load balanced or
something like that.
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
But usually, it's going to come back from the same device, and so we do three
probes at TTL of one.
Well, then we're going to do three probes at TTL of two, so we get three
responses back each time.
So, all of these, well, at least the probes, the reverse DNS, the TTL, we have
control over those settings when we're performing a Traceroute from the Cisco
CLI.
So, when we look at our different options that we can use when we're using Tr
aceroute, it starts with probe.
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
So, I can set the probe count on a per-hot basis, and this defaults to three.
So, if I were to set this, let's say two, one, or two, well, now I don't have
as many probes and I don't have to wait as long at each hop.
The downside is if that packet was eaten by the network, then I'm not going to
get a response at all, but especially in a lot of enterprise networks, we don't
have to worry about as many dropped packets.
This can be really useful for trying to reduce the time it takes to Traceroute
through the network.
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
So, I also have the ability to control the TTL, and not just the TTL from a max
perspective, which, by the way, defaults to 30.
Yes, it'll try to go to 30 different hops, but I can also set a minimum, which
defaults to one.
Now, if I set a different maximum, then, yeah, it's nice if I'm not getting any
responses back, I don't want to have to wait for 30 different hops to resolve
to nothing.
And so, we might want to reduce this to something more realistic, like 10.
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
But also, if I don't really care about getting a response from my default
gateway, because I know my default gateway is there, I could increase the
minimum to two or three.
And just to say, hey, I'm going to start with a TTL of two, meaning I'm going
to immediately identify that second hop device.
That's a pretty nifty feature that is something that doesn't get used a whole
lot, but can definitely be useful in the right circumstance.
We also have this option called numeric.
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
On its own, it doesn't really indicate what's happening, but if we think about
it, what it's trying to indicate is that we care about an IP address and not a
DNS domain lookup.
This skips this lookup here that we just talked about.
It cancels the need to try to perform that reverse DNS lookup, and therefore,
it was only going to respond with IP addresses.
This drastically speeds up our trace routes.
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
It has the equivalent of the dash D option before doing trace routes from
Windows.
So it basically removes the domain lookup, speeds things up, only returns IP
addresses, but in a lot of situations when we're on the network, that's
primarily what we care about, especially in enterprise networks.
We don't necessarily need the domain name of every switch in layer three device
, assuming they even have them.
So here's a few options, probe TTL and numeric.
We actually have a few others that I want to address.
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
First of all, the source, which allows me to specify a source IP address.
So this is always going to choose the nearest or closest to destination.
So in our diagram up here, if I were to, well, we said that this was a PC, let
's say that I'm on a router here.
So now this is a Cisco router, we'll call it router one.
And maybe there's a network behind it.
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
So if I perform a trace route, in the same way that I perform, if I were to
perform a ping, it's going to look at the routing table, see this destination,
it lives out this interface, and it's going to use that as the source IP
address.
Well, I can specify that I want to use a different source.
Sometimes we call these extended pings or extended trace routes, because we're
using extended options.
So instead of specifying a source IP address or allowing the system to decide
it, I could specify a source address back here.
What does that do for me? WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
What does that do for me?
Well, it tells me whether this next hop has a route back to that IP address.
And for that matter, every other hop in the path.
And so naturally, the upstream device will have a path back to the interface
that it's connecting to.
That's just the nature of layer three links.
But does it have a path back to the route that's behind this router?
And that will tell me a lot about whether the routing is working.
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
So this is absolutely a great tool, not just from a trace route perspective,
but also from a ping perspective to make sure that different devices in the
network path can get to specific routes.
So from here, I have a couple of other options that are good to know.
DSCP, which defaults to zero.
And I wonky bracket here.
But the DSCP value I could set if I want to test, maybe see if this packet is
landing in the right queues.
This is especially useful in pings.
But since trace routes also use ICMP messages, it accomplishes the same thing. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
But since trace routes also use ICMP messages, it accomplishes the same thing.
So I can make sure, for example, that if I've got something crazy where my DSCP
-EFs are supposed to go this way, then I could confirm that they're going that
way by specifying the DSCP value here.
And then lastly, I also have a VRF option.
So the VRF is going to assume the default VRF.
And this can absolutely get us into trouble if we have multiple VRFs.
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
And we think we're pinging or trace routing within one VRF and we really need
to specify the correct VRF.
So if we do have multiple VRFs, and for that matter, if we have management VRFs
, which a lot of Cisco devices are starting to have management VRFs for out of
band,
management ports, it's one thing if I want to do a ping, I'm probably not trace
routing from the management port too often.
But if I do need to use the management interface, in that case, I would need to
specify the VRF.
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
So all of these options have the ability to be used simply with the trace route
command.
I can type in trace route.
And then, for example, I could specify probe one.
But I can also, rather than doing that, I can just say enter here.
So to do my enter command, and then rather than specifying an IP address, Cisco
's CLI recognizes, "Hey, you just say enter on trace route."
So now it's going to ask us, "Hey, how many probes do you want?"
"Hey, what's the TTL that you want to use?" WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
"Hey, what's the TTL that you want to use?"
You know, and so on and so forth.
And so that's the concept of the extended trace route, which we can use to our
advantage.
So if we want the speediest, fastest version of trace route, we'd probably want
to perform a trace route with a,
we'd specify maybe the IP address of 10.0.0.1 or whatever this is.
And then I could say probe, probe one, and then specify numeric.
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
That'll make it so that we only have a single probe at each hop, and that it's
numeric, and we can even manipulate the time to live if we so desire.
Oh, and one last thing, by the way.
We mentioned that we have a max TTL of 30.
Well, if we do a trace route in the wrong direction, and we start getting these
asterisks for all of our probes,
asterisks, meaning I'm not getting a response.
So my TTL of one here, got nothing, my TTL two, got nothing, and it's trying to
do reverse DNS lookups,
and it's just waiting for all these responses. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
and it's just waiting for all these responses.
This can take a long time to get to 30.
Well, fortunately, Cisco does give us a break command in the CLI, and it is
control shift six.
Kind of an interesting combination of characters here, but if we enter that,
then we can stop the probe.
And by the way, that works well for pings as well.
We can break out of that and hopefully not have to sit there for five or ten
minutes while it actually tries to wrap up the trace route. WEBVTT X-TIMESTAMP-MAP=LOCAL:00:00:00.000,MPEGTS:900000
minutes while it actually tries to wrap up the trace route.
route that's clearly going nowhere.