said by dbmaven:It's been posted in this forum, and various others on the site, that the fact that a traceroute or LQ test happens to show 'packet loss' at a particular hop is a
regular occurrence.
This is especially true of Level3. They have deliberately set their routers so that ICMP and even UDP traceroute packets are
low priority. In other words, when the router has higher priority traffic to deal with, ICMP/UDP will get dropped.
The
important metric for any traceroute is the latency time (how long the responding devices take to 'answer' the request) and
whether all or almost all of the packets get to the ultimate destination.To go cross-country from a west coast source to you in ~80-90 ms is about as good as you're going to get with just about any residential service. And from New Jersey to you in an avg. of 10ms is pretty incredible.
Whatever you think the problem is, the Level3 routers, at least in the most recent test you posted, are not it.
EXACTLY here is an article i wrote about Tracert. Maybe this should be a sticky:
Short and Simple Answer:
The user types the word traceroute followed by the destination (either a name or an IP address) and presses the enter or return key on the keyboard.
For example: c:\> traceroute oscar.aol.com
The computer running traceroute (we'll call that computer Binky ) creates 3 messages with a zero time to live addressed to the source address.
Binky sends the messages out onto the network, starts a timer, and waits for the messages to die.
The computer on which the messages die (not Binky) sends back 3 answers stating that the traceroute messages died.
Binky receives those messages, notes the time they arrived and shows the results of that round trip on the screen.
Binky repeats steps 1 through 4 until he reaches the destination he's tracing to.
The Long and Extended Answer:
When traceroute initializes it creates three UDP datagrams. Within each of the datagrams, traceroute sets the following values:.
Within the UDP Header
Destination port = 33434 (or some other value not likely to be used by the remote host) and the local UDP port to whatever value the local system specifies.
Time-To-Live (TTL) field = 1.
IP Header
Destination IP = IP address that is the target of the traceroute.
Source IP = Local Host IP
Traceroute transmits an Internet Protocol (IP) datagram via the interface used to reach the destination IP address.
The router at the next hop receives the UDP datagram and will take 1 of 3 actions.
The packet is not for this device
checks the TTL; if it is 1 or zero
it creates an ICMP Time-Exceeded message
Sets the source IP address in the IP header to it's own IP address
Sets the destination IP address field in the IP header to the traceroute originator's IP address.
Transmits the ICMP datagram out the interface listed as the route back to the traceroute originator's IP. Note that this route may be different than that used to receive the original traceroute packet.
If the TTL is not 1 or 0, the router decrements the TTL in the UDP header and transmits the packet out the interface used on that router to reach the destination IP address.
If the packet IS for this device, send back an ICMP Port Unreachable message.
If traceroute receives ICMP Time-Exceeded message (if not, skips to step V)
Traceroute records the results of the round trip time
Traceroute performs a reverse lookup of the IP address of the network device that sent the ICMP Time-Exceeded message.
Traceroute prints a line of output with a line number (hop number), round trip times, the host name and IP address of the router at that hop in the routing path.
Traceroute increments the TTL value to be used for the next three datagrams and repeats steps II - IV.
If traceroute receives a ICMP Port Unreachable message, it knows it has reached the destination prints the final results and exits.
Now we will look at some examples of how reading a Trace Route can be confusing:
1 1 ms 1 ms 1 ms 192.168.1.1
2 8 ms 7 ms 8 ms 10.49.0.1
3 7 ms 8 ms 6 ms pos0-0-nycmnyw-rtr1.nyc.rr.com [24.29.98.233]
4 8 ms 7 ms 7 ms gig7-3.nycmnyrdc-rtr1.nyc.rr.com [24.29.119.29]
5 7 ms 8 ms 7 ms 24.29.119.146
6 9 ms 9 ms 6 ms pop2-nye-P10-0.atdn.net [66.185.141.33]
7 100 ms 199 ms 198 ms bb1-nye-P1-0.atdn.net [66.185.151.64]
8 14 ms 12 ms 13 ms bb2-ash-P10-0.atdn.net [66.185.152.87]
9 12 ms 13 ms 12 ms pop3-ash-P3-0.atdn.net [66.185.136.7]
10 12 ms 15 ms 13 ms if-10-0.core3.AEQ-Ashburn.teleglobe.net [63.243.
149.97]
11 13 ms 20 ms 13 ms ix-14-2.core3.AEQ-Ashburn.teleglobe.net [63.243.
149.110]
12 19 ms 13 ms 14 ms ge-0-0-0-p110.msr2.dcn.yahoo.com [216.115.108.5]
13 13 ms 13 ms 13 ms ge2-2.bas1-m.dcn.yahoo.com [216.109.120.142]
14 14 ms 13 ms 13 ms w2.rc.vip.dcn.yahoo.com [216.109.112.135]
Trace complete.
If we saw this Trace Route, we could imply that a customer complaining of slow speed is experiencing this because of Hop number 7 Which is reporting higher than normal ICMP response times. If we were truly seeing a “Routing Issue” then what we would see is subsequent hops, as shown below, would be adversely affected as well:
1 6 ms 8 ms 8 ms 10.44.32.1
2 9 ms 8 ms 8 ms pos1-0-nycmnyo-rtr1.nyc.rr.com [24.29.101.9]
3 8 ms 6 ms 7 ms 24-29-104-205.nyc.rr.com [24.29.104.205]
4 8 ms 8 ms 7 ms pos3-0-nycmnyq-rtr1.nyc.rr.com [24.29.100.62]
5 7 ms 10 ms 6 ms 24-29-104-209.nyc.rr.com [24.29.104.209]
6 7 ms 9 ms 16 ms pos1-0-nycmnyk-rtr2.nyc.rr.com [24.29.100.57]
7 7 ms 7 ms 17 ms pos4-0-nycmnyk-rtr1.nyc.rr.com [24.29.101.233]
8 107 ms 109 ms 120 ms 24-29-113-221.nyc.rr.com [24.29.113.221]
9 115 ms 117 ms 116 ms tenge-0-0-0.nwrknjmd-rtr.nyc.rr.com [24.29.119.9
4]
10 95 ms 97 ms 98 ms 4.79.188.33
11 91 ms 94 ms 94 ms ae-1-51.bbr1.Newark1.Level3.net [4.68.99.1]
12 212 ms 124 ms 88 ms as-2-0.bbr2.NewYork1.Level3.net [4.68.128.138]
13 90 ms 112 ms 114 ms ae-22-52.car2.NewYork1.Level3.net [4.68.97.53]
14 91 ms 90 ms 97 ms telia-level3-10ge.NewYork1.Level3.net [4.68.110.
82]
15 117 ms 115 ms 115 ms nyk-bb1-link.telia.net [213.248.83.225]
16 93 ms 125 ms 117 ms nyk-b3-pos1-0-0.telia.net [213.248.82.18]
17 96 ms 107 ms 100 ms nac-110814-nyk-b3.c.telia.net [213.248.82.94]
18 117 ms 122 ms 119 ms 12.ae0.gbr1.tl9.nac.net [209.123.11.71]
19 122 ms 120 ms 119 ms 33.ge-3-0-0.gbr2.nwr.nac.net [209.123.11.7]
20 100 ms 102 ms 99 ms 0.so-0-3-0.gbr1.oct.nac.net [209.123.11.233]
21 105 ms 103 ms 103 ms www.dslreports.com [209.123.109.175]
In this example you san clearly see that at hop 8, the latency spikes, and continues on down the path. Our first example is showing QoS Packet Prioritization and also a “Self Defense” function routers have against sending ICMP responses back in a timely manner. This can create a very confusing result,
There we go.....again
