The mechanics of traceroute are interesting, but using it to
solve network problems is truly useful.
Let's explore that next.
Traceroute is an excellent diagnostic tool for finding faults in the
network. Even in steady state networks in which no outages currently exist,
traceroute can live up to its self‑evident name.
It traces the route from source to destination.
But what happens when you have a variety of paths between two nodes?
Suppose we've just received a call from the finance department that
their accounting services hosted on the remote Wired Brain Coffee
server are performing slower than usual.
Let's see what a basic ICMP ping tells us.
We will ping from our Globomantics client to the remote
server using IP address 10.2.5.5.
Well, not surprisingly, the ping succeeds.
Is it possible that our network is preferring to take the backup path
through R3 rather than the direct link between R1 and R2? A basic
ping cannot answer this question for us,
but traceroute likely can.
Let's try that.
We need to target 10.2.5.5 again and let traceroute work its magic.
Okay, time to examine the output.
The first row reveals R1's LAN interface towards the client, which is
expected. Since R1 is not the final destination, it generates a TTL
exceeded ICMP message and sends it back to the client.
The next hop is unexpected,
revealing 10.1.3.3, which is R3. I haven't talked about this
additional router much so far because I purposefully wanted
this clip to be surprising.
R3 is another Globomantics router that ties into Wired Brain Coffee Company's
R2 router, but exists along a backup path in the network.
Why do you think R3 would be showing up in the traceroute? Pause the
video if you need some time to think about it.
The reason R3 shows up in the traceroute from the client is because R1 is
preferring to use R3 to reach the remote server rather than R2 from a
routing perspective. Because this is not a course on Cisco IOS or IP
routing, I won't go into detail on that,
but we could form a hypothesis based on this observation.
I'll hypothesize that the link between R1 and R2 is currently
down again, perhaps due to a fiber cut between Globomantics
and Wired Brain Coffee Company.
What tool can we use to test if the link between R1 and R2 is
up? That's right, our trusty ICMP ping.
There's no rule stating that we cannot mix and match our troubleshooting
tools. Let's quickly ping 10.1.2.1 to see if we get a reply.
All right,
this doesn't look good. At this point, I would log in to R2 and dig deeper
into the cause for this interface being unresponsive.
The main point is that we use traceroute and ICMP ping in a
two‑punch combination to resolve this very common business scenario
regarding poor performance across a network.
We saw in a previous demonstration that traceroute could also report a timeout
condition marked by asterisks, and oftentimes where these asterisks start
appearing is the part of the network in which to focus.
I hope you found this demonstration useful and applicable to your daily work.
I can't tell you how many times I followed this basic
process to track down network issues in my years of
networking. Brilliance in the basics is key.
Stay tuned for more tools and techniques for using ICMP to optimize networking performance.