首先：traceroute是如何工作的？
Traceroute transmits packets with small TTL (Time To Live) values. The TTL is an IP header field that is used to prevent packets from running into endless loops. When a router that handles the packet subtracts one from the packet's TTL. The packet expires and it's discarded when the TTL reaches zero.
Traceroute sends ICMP Time Exceeded messages, (RFC 792 ), back to the sender when this occurs. By using small TTL values, the packets will quickly expire, so traceroute causes all routers along a packet's path to generate the ICMP messages that identify the router.
For example, TTL = 1 should produce the message from the first router, TTL = 2 generates a message from the second router in the path , and so on...
問題和解決辦法
If you’re using a *nix or BSD-based operating system and trying to use traceroute at home behind a NAT router , you probably have problems with intermediate routers timing out, i.e.:
3 * * * 4 * * * 5 * * * 6 * * *
Furthermore, you may have also noticed that Windows’ tracert program doesn’t have this problem. The Unix traceroute program uses a bunch of UDP packets on a bunch of client ports to do its magic ,
whereastracert uses ICMP packets, which I guess would have to be port forwarded on your router normally . Regardless, the solution is to use:
traceroute -I targethost.com
This forces traceroute to use ICMP packets the way the Windows program does. Amazing! I’m sure there’s a downside to this approach, but so far it works like a charm.
traceroute 有
使用兩種：使用ICMP的和使用UDP的。
Microsoft使用ICMP，所以win95上發出的traceRT應使用的是ICMP，但我沒有用 sniffer查過；其它包括unix和cisco router都使用UDP.
ICMP traceroute :
===========
使用ICMP Echo Request ， Echo Reply and TTL-expired .
源發出 ICMP
Equest，第一個request的TTL爲1，第二個request的TTL爲2，以後依此遞增直至第30個；中間的router送回ICMP TTL-expired ( ICMP type 11)通知source，（packet同時因TTL超時而被drop)，由此source知曉一路上經過的每一個router；最後的 destination送回ICMP Echo
Reply 。
所以中間任何一個router上如果封了ICMP Echo Request ， traceroute就不能工作 ；如果封了type 11 (TTL-expired)， 中間的router全看不到 ，但能看到packet 到達了最後的destination；如果封了ICMP
Echo Reply，中間的全能看到，最後的destination看不到 。
UDP traceroute:
==========
使用ICMP TTL-expired (type 11)， ICMP port unreachable (type 3， code 3)， UDP
port >32768 .
source發出UDP packet， source port使用隨機的任何大於32768的高段port， destination port從33434開始每送個probe依此遞增，直至33434+29，（cisco router上使用extended-traceroute命令可以修改這個起始的33434 port #），
同時TTL從1開始依此遞增，直至1+29=30（最多送30個probe)。中間的router送回 ICMP TTL-expired，使得source得知了中間的每一個router，最後的destination送回TTL-expired 和ICMP port unreachable （因爲任何主機上都沒有應用使用UDP port# >32768這樣的高段port )。
所以中間某處封掉UDP port>32768回導致traceroute不工作 ；封掉TTL超時會使source看不到中間的router（有的router根本不支持回送TTL超時）；封掉type3 code3可能看不到destination .
另外需要知道的是，由於回送TTL-expired的信息需要CPU生成一個packet，必須打斷 CPU，爲保證其它工作的正常進行，cisco router每隔一秒才處理traceroute ，所以在source 上你可能看到中間一路 * * *，但卻看得到最後的destination. 這時你應知道這是中間的router CPU太忙或者中間路由器不回送TTL-expired包的原因 ，不必大驚小怪的。:-)
下面是我自己的問題終於得到了解答：
在虛擬機的red hat上使用nat方式上網：
到百度2跳就到了。
然而使用windows公網來：
要9跳才完成。。。
分析如下：
windows中的tracert和linux中的traceroute -I，都是使用icmp協議，但是linux是在虛擬機的nat路由器後面，個人估計在收到linux上的ip包時候，nat路由器在替換ip頭的時候沒有考慮tracert這個功能，直接換了，然後直接傳遞到目的地址，目的地址有一個icmp echo Reply.從而我2跳就到了。。。
如果在linux上使用traceroute，默認使用udp協議，除了第一跳，剩下的都是* * *。八成是因爲虛擬機nat 路由器，默認丟棄port>32767的包。 所以一切都解釋了。圓滿了