In the configuration below, ICMP is blocked at MIN’s FastEthernet0/0 interface; afterwards a traceroute is performed (see traceroute #9). Traceroute #9 stops at MIN and MIN reports back a destination net (network) unreachable message due to the ACL applied. The traceroute never completes as the probes (ICMP echo requests) are all blocked as they ingress MIN on Fa0/0 (see diagram below). This is an example of an explicit notification; the router is explicitly informing the host that the destination is unreachable and if we took a packet capture it would also tell us that its administratively blocked. Some routers/firewalls (e.g., Juniper) have the option to discard packets silently; in cases like that we would just see all asterisks after hop 2 in traceroute #9.
Traceroute #9
Traceroute #10 and #11 are examples of where traceroute can be misleading. They show asterisks in the middle of the traceroute which would lead someone to believe there’s an issue. However as shown this is just because certain ICMP messages are blocked, connectivity isn’t an issue as shown with the pings #2 and #3.
In Traceroute #10 we see timeouts for hop 3 but the traceroute continues on afterwards. The configuration below shows that ICMP is being blocked at DVR as traffic enters from MIN; this is also shown in the diagram below. Further investigation shows that these timeouts on hop 3 aren’t an issue as they don’t affect connectivity between the hosts as shown in ping #2. Ping #2 is successful because the pings (ICMP echo requests/replies) only traverse the top and bottom paths and never traverse the MIN > DVR link where ICMP is blocked. In this example, it appears there is packet loss between hops 2 (SEA) and 4(OMH) due to the three asterisks in hop 3, but clearly this is not the case as it’s just a matter of ICMP being blocked and no other traffic being blocked.
Ping #2
C:\>ping 10.10.10.6
Pinging 10.10.10.6 with 32 bytes of data:
Reply from 10.10.10.6: bytes=32 time=6ms TTL=124
Reply from 10.10.10.6: bytes=32 time=4ms TTL=124
Reply from 10.10.10.6: bytes=32 time=4ms TTL=124
Reply from 10.10.10.6: bytes=32 time=4ms TTL=124
Ping statistics for 10.10.10.6:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 6ms, Average = 4ms
The red X below shows where ICMP is being blocked. There is only one packet being blocked, that’s the TTL exceeded message generated by MIN and sent out the MIN > DVR link. The rest of the packets are forwarded; this is why hop 3 from Traceroute #10 shows all asterisks; the ICMP TTL message generated by MIN is dropped by the ACL at DVR and therefore never arrives back at the 10.10.10.2 host.
Traceroute #10
In Traceroute #11 we see a response for the first probe/hop and the destination or the 5th hop. In the middle there are no responses for hops 2, 3 and 4. We may think this is a problem as we should be seeing responses for every hop. Further investigation shows that pings are successful to the destination and the traceroute does complete to its destination. The configuration below shows why the traceroute displays the way it does. On SVL an ACL was configured to deny any ICMP time-exceeded messages (TTL exceeded), this ACL was then applied to traffic ingressing SVL from SEA and PHX. The net result is that the first hop remains unaffected because it doesn’t traverse the SVL > PHX or SVL > SEA links, the next three hops time out because the ACL is blocking the time-exceeded messages. The last probe does get a response from the destination though; the reason for this is when the 5th probe reaches the intended destination it responds with an ICMP echo reply; since the echo replies aren’t blocked this is why the last hop shows up in the traceroute. It’s also the reason why the ping #3 is successful as they use ICMP echo requests and ICMP echo replies, neither of which is blocked.
Ping #3
C:\>ping 10.10.10.6
Pinging 10.10.10.6 with 32 bytes of data:
Reply from 10.10.10.6: bytes=32 time=4ms TTL=124
Reply from 10.10.10.6: bytes=32 time=4ms TTL=124
Reply from 10.10.10.6: bytes=32 time=4ms TTL=124
Reply from 10.10.10.6: bytes=32 time=4ms TTL=124
Ping statistics for 10.10.10.6:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 4ms, Average = 4ms
Traceroute #11
Traceroute #12 is an example of where traceroute is useful, it identified that the MIN router was missing a route for the destination which would prevent connectivity as shown in ping #4. In Traceroute #12 MIN (192.168.1.22) reports a destination host unreachable and the traceroute never reaches its destination of 10.10.10.6. Ping #4 also confirms 192.168.1.22 shows destination host unreachable. Look back at Traceroute #9 as that traceroute also showed a destination unreachable message. There is a slight difference though; Traceroute #9 shows destination net unreachable while Traceroute #12 shows destination host unreachable. To see why MIN is reporting the unreachable message we will look at the routing table at MIN.
IANA lists the different types of ICMP unreachable messages
Ping #4
C:\>ping 10.10.10.6
Pinging 10.10.10.6 with 32 bytes of data:
Reply from 192.168.1.22: Destination host unreachable.
Reply from 192.168.1.22: Destination host unreachable.
Reply from 192.168.1.22: Destination host unreachable.
Reply from 192.168.1.22: Destination host unreachable.
Ping statistics for 10.10.10.6:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 4ms, Maximum = 6ms, Average = 4ms
Traceroute #12
