為什麼Traceroute時沒有發生packet lost但是總會出現 * 呢?

說實話，關於這個問題我自己也常常覺得很納悶，剛好最近PacketLife.net(我真的愈來愈喜歡這個網站了，只要上過我課程的學生應該不陌生，給各位同學的cheatsheet都是從PacketLife上抓下來的)把這個issue提出來並且作了一份packet analyze報告，請參考!

Traceroute timeouts

Posted by stretch in Networking on Monday, 29 Dec 2008 at 2:26 a.m. GMT

If you spend a lot of time performing traceroutes to Cisco routers you've probably noticed that they usually end like this:

R1# traceroute 10.0.34.4
Type escape sequence to abort.
Tracing the route to 10.0.34.4   
1 10.0.12.2 16 msec 8 msec 12 msec  
2 10.0.23.3 16 msec 16 msec 16 msec  
3 10.0.34.4 16 msec *  20 msec

Notice that the second reply from the last hop has timed out. This is easily repeated with subsequent traceroutes, and it is always the second attempt which times out. Strange, eh?

The reason for this is IOS' default ICMP rate limiting. Back in May I wrote an article explaining the common "U.U.U" response that results from pinging an unreachable destination, and the same logic is at work here. Inspecting the default ICMP rate limits reveals that ICMP unreachable messages are only sent every 500ms:

R4# show ip icmp rate-limit
                          DF bit unreachables   All other nreachables
Interval (millisecond)     500                   500

Interface                  # DF bit unreachables     # All other unreachables
---------                  ---------------------     ------------------------
FastEthernet0/1            0                         3     

Greatest number of unreachables on FastEthernet0/1

This rate limiting configuration effectively ignores every other traceroute packet (see the timeline illustration in the previous article). Makes sense, but why do all the requests to routers prior to the last hop receive replies without this problem?

Those replies are of a different ICMP type, namely the "TTL exceeded" type. Remember that traceroute works by sequentially incrementing the TTL of UDP (or ICMP on Windows) packets destined for a host and recording the replies received from intermediate routers. All hops except the last one will (or should) return a "TTL exceeded in transit" message, whereas the last hop should return a "destination unreachable/port unreachable" message indicating that it cannot handle the received traffic (UDP traceroute packets are typically addressed to a pseudorandom high port on which the end host is not likely to be listening).

The packet capture attached at the end of this article includes the traffic from the traceroute demonstrated above.

Interestingly, we can remove the ICMP rate limit with no ip icmp rate-limit:

R4(config)# no ip icmp rate-limit unreachable
R4(config)# ^Z
R4# show ip icmp rate-limit

Now our traceroute from R1 completes fully:

R1# traceroute 10.0.34.4
Type escape sequence to abort.
Tracing the route to 10.0.34.4
1 10.0.12.2 32 msec 12 msec 20 msec
2 10.0.23.3 60 msec 56 msec 24 msec
3 10.0.34.4 32 msec 44 msec 36 msec

However, removing the ICMP rate-limit may open an avenue for denial of service attacks on your routers, so in practice you probably want to leave it applied.

File Attachments

• traceroute.cap (1.4 KB)