Tuesday, March 20, 2012

Reasons for Abnormal Traceroute Results

Results due to ICMP Filters

When performing a ICMP based traceroute, there are a few reasons for not receiving a reply. Packet loss on congested networks can explain away singular dropped replies. If all three probes for one or more links go missing, it's likely that a firewall is blocking ICMP or the routers are configured to not return an ICMP error. If however the traceroute ends with a successful reply after reporting multiple failed probes, then this is the result of a firewall configured to pass ping requests, and not traceroute.



To understand what is going on here, it’s important to keep in mind that the Microsoft traceroute works by sending out ICMP echo requests (ICMP 8) with ever increasing TTL’s (Time-To-Live). The TTL’s of these requests are decremented by each router as it forwards the packet. If the TTL is 0 after a router decrements it, the router will not forward the packet. Instead is returns to the sender an error message in the form of a ICMP time exceeded (ICMP 11) packet. However, if the target host receives the ICMP echo request, it responds with an ICMP echo reply (ICMP 0).


In this conceptual traffic, we see at (A) the client sending out a ICMP 8 probe with the TTL of 1. Which the router receives, decrements the TTL, then realizing the TTL is 0, sends back an ICMP 11 to the client. In probes (B) and (C) the client sending the same probe with larger TTL’s, and we can follow along as the TTL’s are decremented at each hop until it reaches 0. At probe (D) we see a different reaction, as the probe just barely reaches the host with TTL of 1, in fact all traceroutes can be identified at the host as their TTL will always be 1.

Now, if a firework gets inserted into this network, and is configured to allow ping, then our traffic changes to the following picture.


Since ping only requires ICMP echo requests (ICMP 8), and ICMP echo replies (ICMP 0), the firewall will allow our traceroute probes to proceed into the network, but will not allow the ICMP time exceeded (ICMP 11) packets to return to the client. Thus, while the router on probe (C) receives our probe, decrements and responds with an error, the firewall prevents this response from reaching the client. We can easily confirm this by pinging the destination before running traceroute. On a side note, it's unlikely a Unix traceroute would see a response from the host, as it relies on ICMP unreachable (ICMP 3) for it's probes reaching a closed UDP port, and the firewall will likely block that as well.

While this helps us locate a firewall, remember that various venders, like Cisco, allow their devices to bet set to not decrement the TTL and thus give away their position. However, we will still be able to narrow down the firewall’s location to either the first link that doesn’t respond, or in between that link and the last reporting link.

If you want to Cisco device to allow traceroutes, then you’ll want to enable ICMP time exceeded and ICMP unreachable (for Unix traceroute).
See this Cisco Tech Note: http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a0080094e8a.shtml

Results due to Packet Loss

While dealing with a host that had major packet-loss issues, I fired off the following traceroute probe.


Since there was some packet-loss issues, I wasn't sure wither there were additional hops between 10.0.100.18 and 10.0.32.46. To confirm the results I fired off another query


"Insanity is doing the same thing over and over again but expecting different results."
- Not a student of Quantum Physics or Electrical Engineering

So this was great, trying to answer one question presented me with a new one. Why didn't tracert stop the first three times it successfully reached the host? I notice that this query didn't receive a successful reply to the third probe until the last attempt. Looking at the previous probe, I notice similar behavior. So I fired another probe to confirm my observations.

Sure enough, it seems that the Microsoft Tracert only checks the last probe when it determines if it should end or not. Interesting to keep in mind. I'll test various other traceroutes and update this is they show similar behavior.

No comments:

Post a Comment