Now that we've discussed the different ICMP unreachables involved,
let's test it out.
Let's kick off a traceroute from the Globomantics client to the
Wired Brain Coffee server and see what happens.
Almost all operating systems will clearly print the traceroute results
in some kind of tabular fashion for easy readability.
In Cisco IOS, each row represents a different time‑to‑live value,
effectively showing each hop in the network on its own row.
The columns represent individual probes that are sent.
This particular operating system sends three probes per hop,
as indicated by the three time measurements displayed.
The IP address displayed towards the beginning of the row shows
the source IP address of the ICMP unreachable message received. On
the first row, the IP address is 10.1.4.1, which is R1's LAN
interface towards the client.
Remember that we were using traceroute with a target of
10.2.5.5, so any IP address in the path that is not 10.2.5.5 is
an intermediate hop and should therefore have returned an ICMP
TTL exceeded unreachable message.
The second row is similar to the first showing three unreachables
received with their corresponding transit times.
The IP address shown here is 10.1.2.2, which is R2's WAN interface
towards R1. We are slowly inching our way to the remote server hop
by hop. The third row is the end of the traceroute since the IP
address displayed is 10.2.5.5.
We can reasonably assume that the message generated by the remote server was
an ICMP port unreachable. TTL did not expire, but the bogus destination port
of 334 something was not open on the target.
The server then notifies the sender that you tried to send traffic to me
on this port, but it's closed, so I can't process it.
Let's explore what happens when an operator traceroutes to a
non‑existent destination, such as 10.2.5.6.
The first few hops continue to function normally as
intermediate routers are revealed.
Both R1 and R2 receive packets from the client, which expire
due to TTL counting down to 0 and thus send their TTL
exceeded messages back to the client.
On the third iteration, the client sends out probes with TTL equal to 3,
but receives no reply, as indicated by the asterisk. R2 cannot find a
client with an IP address of 10.2.5.6 on its server LAN segment, so it
does not send anything back to the client.
The probes simply time out.
This will continue until the operating system reaches its
TTL limit, which I've set to 5 here just to speed things
up. To reinforce learning,
I'll enable ICMP debugging and kick off another successful traceroute.
Because the probes are UDP, we won't see them being sent with this
specific debug message, but that's not a big deal.
What we do see is the nine unreachable messages coming back.
First, there are three TTL exceeded messages from R1, indicating
that the packet's TTL expired in transit.
Next, there are another three TTL exceeded messages from
R2, the second hop, as expected. Last,
there are three port unreachable messages from the remote server indicating
that it is not listening on the bogus UDP probe port. While seeing debugs
on the router shell is useful, it would be even better to see what other
goodies exist inside these packets. I'll show you in the next clip where we will explore these details further.