Traceroute transmits packets with small TTL (time to Live) values. The TTL is an IP header field , which is used to prevent packets from running into endless loops. When a router this 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), when the sender is this occurs. By using small TTL values, the packets would quickly expire, so traceroute causes all routers along a packet's path to Gene Rate 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 Rou ter in the path, and so on ...
Problems and Solutions
If you ' re using a *nix or bsd-based operating system and trying to use on traceroute
home behind a NAT router, you probably hav e problems with intermediate routers timing out, i.e.:
3 * * * * * * * * * * * * * * * * *6 * * *
Furthermore, also noticed that Windows ' program tracert
doesn ' t has this problem. The Unix program traceroute
uses a bunch of UDP packets in a bunch of client ports to does its magic, whereas tracert uses ICMP p Ackets, which I guess would has to being port forwarded on your router normally. Regardless, the solution is-use:
Traceroute-i targethost.com
This forces traceroute
-to-use ICMP packets the the-the-the-Windows program does. amazing! I ' m sure there ' s a downside to this approach, but so far it works like a charm.
Traceroute has
Two types are used: ICMP and UDP.
Microsoft uses ICMP, so tracert on Win95 should use ICMP, but I didn't check with sniffer, and other Unix-and Cisco router use UDP.
ICMP traceroute:
===========
Use the ICMP echo Request, echo Reply and ttl-expired.
SOURCE Emits ICMP
Equest, the TTL for the first request is 1, the second request has a TTL of 2, then increments up to 30th, and the middle router sends back the ICMP ttl-expired (ICMP type 11) to notify the source, (Packet is also drop for TTL timeout), so source knows every router that passes along the way, and the final destination sends back the ICMP Echo Reply.
So if the ICMP Echo Request is blocked on any of the router, traceroute will not work, and if the type one (ttl-expired) is blocked, the router in the middle cannot be seen, but you can see packet The final destination is reached, and if the ICMP Echo Reply is sealed, the middle Almighty sees that the last destination cannot be seen.
UDP traceroute:
==========
Using ICMP ttl-expired (Type one), ICMP Port unreachable (Type 3, code 3), UDP
Port >32768.
Source emits a UDP packet, the source port uses any random high segment port greater than 32768, destination port increments from 33434 for each probe, up to 33434+29, (Cisco Use the Extended-traceroute command on router to modify this starting 33434 Port #),
At the same time, the TTL increments from 1 until 1+29=30 (up to 30 probe). The middle of the router sent back to the ICMP ttl-expired, so that source learned the middle of each router, the final destination sent back to ttl-expired and ICMP Port unreachable (Because a high segment port using UDP port# >32768 is not applied on any host).
So somewhere in the middle of blocking UDP port>32768 back causes traceroute not to work; blocking the TTL timeout causes the source to see no intermediate router (some router do not support the echo TTL timeout at all); seal off Type3 Code3 may not see the destination.
It is also important to know that because the loopback ttl-expired information requires the CPU to generate a packet, must interrupt the CPU, in order to ensure the normal operation of other work, the Cisco router processing traceroute every second, so in the source You may see the Middle way * *, but you can see the final destination. At this point you should know that this is the middle of the router CPU is too busy or the intermediate router does not echo the ttl-expired package, do not fuss. :-)
Here are my own questions that have finally been answered:
Use NAT on the virtual machine's Red hat to surf the Internet:
To Baidu 2 jump on the.
However, using Windows public network to:
9 Jump to complete ...
The analysis is as follows:
Tracert in Windows and Traceroute-i in Linux are all using the ICMP protocol, but Linux is behind the NAT router of the virtual machine, and the individual is estimated to receive the IP packets on the Linux NAT router in the replacement IP header does not consider tracert this function, directly changed, and then passed directly to the destination address, the destination address has an ICMP echo Reply. So I'm 2.
If you use Traceroute on Linux, the UDP protocol is used by default, except for the first hop, the rest is * * *. Probably is due to the virtual machine NAT router, which discards the port>32767 package by default. So it's all explained. A complete.
From: http://blog.csdn.net/lhq9220/article/details/6436984
Linux environment, Traceroute returns a series of * cause analysis