|
Knowledge
Base
- HOME:
Connection
-
-
- 4. How traceroutes work
How traceroutes work
- A traceroute packet starts from the machine that requested the traceroute. This packet is created with a TTL, (Time To Live), bit of 1.
- When the first gateway/router receives the packet it decrements the packet by 1, (As every packet on the network decrements to prevent bouncing packets throughout the internet), and if the TTL = 0, which it would, the router returns an error indicating that the "TTL was exceeded".
- Information about the returned packet would include the gateway/router's ip, which is displayed on the command line.
- The "Round Trip Packet", (from the time it left the host to the time it returned from the gateway/router), time is calculated and displayed as well. This is the time from which it left to the time it returned.
- If that was not the destination host, traceroute initiates another packet but increments the TTL to 2.
- The first gateway/router decrements the TTL and if it is not 0, it sends it to the next gateway/router, which in turn decrements the TTL and which should equal 0 at this point. This, again, would be a "TTL was exceeded" error and the receiving gateway/router would return it to the sender.
- Traceroute would again calculate the "Round Trip Packet" time and display that and the ip (or name) of the gateway/router that the packet erred out on.
This can go on and on until it finds the remote host it was looking for. At this point the UDP packet that was sent, was delivered to a port that does not accept the UDP packet and returns an error of "Port not allowed", I think, which traceroute now knows it found the host it was tracing to.
There are no packets being sent back with times in them to be viewed. If this was the case, one router having a mis-configured clock, would show unbelievable time losses or negative values. Which in turn may cause packets to start bouncing all over the place.
Example:
RT is round trip time and is the total time as error messages dont have time stamps between gateways/routers.
./traceroute yahoo.com
Increment TTL to 1
ttl=1 --------->Router 1 (ttl - 1 = 0)
RT <---------- Router 1 (error on ttl)
Increment TTL (previous + 1)
ttl=2 ----------->Router 1 (ttl - 1 = 1)
Router 1 ------------> Router 2 (ttl - 1 = 0)
RT <-------------------------------Router 2 (error on ttl)
Increment TTL (previous + 1)
ttl=3 ------------>Router 1 (ttl - 1 = 2)
Router 1 ------------> Router 2 (ttl - 1 = 1) (Yahoo.com)
Router 2 ---------->RemoteHost
RT <------------------------------------------------- RemoteHost
(Port not allowed error)
I hope this explains what traceroute is doing and how times CAN accumulate.
Packets may get to a route and return quickly, then the next time through the route, (could be the other side of the router), they appear to be slower. Packets may never be consistent as you may hit congestion one time, or you may be going through a router that responded poorly on the first packet but is able to send the packet to the next router quickly, or whatever. There could be many causes for latency in packets.
Saying that it may be the receive side or the transmit side is not relevant if one direction is good and the other is bad. Because, they both are using the same transmitting and receiving paths. It is just my transmit is your receive. Now, if a router is bogged down, it would also show slowness when getting through it. But if I send a traceroute out with excellent times making the first couple of hops and traceroutes coming in are displaying poor times, it would mean that there is latency somewhere in the poor traceroutes path.
I noticed a few of the customers traceroutes that had displayed 1200, or so, ms at our router. But if you looked closely, as Tom indicated, there was a 1200 ms loss earlier in the path. Remember, the packets following that first lengthy response will be using that exact same path and may display further losses down the route.
Traceroutes sent to a router should not be expected to respond to the "destination unreachable" probe. This error is an error that the destination host that is requested is supposed to respond with. This is when traceroute, or any other form of traceroute, terminates. All other routers and such in between the originating and destination hosts, just move the packet along after stripping of a TTL bit, or error'ng out at the next hop when the TTL has been reached.
Most all routers do not consider the destination unreachable message a priority to respond to. Which makes sense if you don't want your router to be bombarded with bogus ports to take the router down. i.e. a Denial of Service (DoS) attack. Here are some example of tracerouting through a router then to a router.
Through multiple routers:
traceroute to yahoo.com (204.71.200.245), 30 hops max, 40 byte packets
1 209.239.32.1 (209.239.32.1) 1.508 ms 1.233 ms 3.596 ms
2 209.201.44.9 (209.201.44.9) 1.400 ms 1.546 ms 0.978 ms
3 Serial4-1-0.core2.dca1.IConNet.NET (204.245.69.194) 2.591 ms 2.451ms 2.567 ms
4 POS6-0-0.peer1.dca1.IConNet.NET (204.245.71.10) 3.186 ms 2.528 ms3.473 ms
5 fddi3-0.cr1.dca.globalcenter.net (192.41.177.113) 8.625 ms 7.854ms 7.292 ms
6 fe2-0-0.br1.DCA.globalcenter.net (204.152.166.13) 4.435 ms 4.077 ms 10.195 ms
To router 204.245.71.10:
traceroute to 204.245.71.10 (204.245.71.10), 30 hops max, 40 byte
packets
1 209.239.32.1 (209.239.32.1) 1.391 ms 1.409 ms 1.473 ms
2 209.201.44.9 (209.201.44.9) 2.258 ms 0.741 ms 3.064 ms
3 Serial4-1-0.core2.dca1.IConNet.NET (204.245.69.194) 3.321 ms 4.426ms 3.132 ms
4 POS6-0-0.peer1.dca1.IConNet.NET (204.245.71.10) 5.052 ms * 2.714ms
To router 192.41.177.118:
traceroute to 204.152.166.13 (204.152.166.13), 30 hops max, 40 byte
packets
1 209.239.32.1 (209.239.32.1) 16.559 ms 1.286 ms 0.932 ms
2 209.201.44.9 (209.201.44.9) 1.646 ms 3.230 ms 2.976 ms
3 Hssi12-0-0.core1.dca1.IConNet.NET (204.245.69.50) 2.678 ms 2.879ms 3.101 ms
4 POS0-0-0.peer1.dca1.IConNet.NET (204.245.71.6) 3.332 ms 5.094 ms2.615 ms
5 fddi2-1-0.br1.dca.globalcenter.net (192.41.177.118) 21.116 ms * *
Bottom line is if a customer is using our router as an example, we can only consider the ms it took not the timeouts. So this does not make for a good traceroute to troubleshoot with. We must traceroute through the routers to find connections that are slow or that are broken.
Updated: January 4, 2001
-
-
|
|
|
|
