Target Name: RVCS021015DT.
IP: 172.27.35.114
Date/Time: 9/16/2013 11:13:43 AM to 9/16/2013 11:16:14 AM

Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 150 0 0.0 0 7 1 [10.28.128.1]
2 150 0 0.0 0 1 0 [10.45.8.62]
3 38 0 0.0 0 6 0 [10.160.0.225]
4 147 110 74.8 0 2 0 [10.255.254.29]
5 150 0 0.0 1 4 1 [172.31.254.242]
6 150 0 0.0 1 8 3 [10.160.1.200]
7 150 0 0.0 1 12 2 [10.45.2.1]
8 150 0 0.0 0 8 0 [172.27.35.114]

If you could see the graph for hop 4 there is a displayed pattern of packet loss ever 30 - 45 second for 50 seconds with a trace interval of every 1 second.

----
Tracing one hop beyond hop 4;
Target Name: N/A
IP: 172.31.254.242
Date/Time: 9/16/2013 11:15:06 AM to 9/16/2013 11:17:37 AM

Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 150 0 0.0 0 6 1 [10.28.128.1]
2 150 0 0.0 0 3 0 [10.45.8.62]
3 109 0 0.0 0 4 0 [10.160.0.226]
4 150 37 24.7 0 7 0 [10.255.254.29]
5 150 0 0.0 0 17 1 [172.31.254.242]

If you could see the graph for hop 4 there is a displayed pattern of packet loss every 50 second for 18 seconds with a trace interval of every 1 second.


-----

however when tracing directly to hop 4;
Target Name: N/A
IP: 10.255.254.29
Date/Time: 9/16/2013 11:14:26 AM to 9/16/2013 11:16:57 AM

Hop Sent Err PL% Min Max Avg Host Name / [IP]
1 150 0 0.0 0 7 1 [10.28.128.1]
2 150 0 0.0 0 4 0 [10.45.8.62]
3 97 0 0.0 0 12 0 [10.160.0.225]
4 150 0 0.0 0 2 0 [10.255.254.29]

dos / command prompt traces do not show PL.


Looking for help in understanding this observed behavior.

Thank you!

Hi, Giles.

This is pretty typical.

All intermediate hop data is gathered by sending out packets with artificially lowered TTL. Each hop lowers the TTL by 1, so if we set TTL to 4, when the packet reaches hop 4 then TTL = 0. Whenever a router for someone else receives a packet with TTL=0, it stops forwarding and sends a reply back to the sender that say "TTL Expired in transit!", along with its hop information.

We take advantage of this to map out all the information about intermediate hops - but an intermediate hop also knows that these replies are pretty low priority. If it starts to run out of time (or bandwidth, or sometimes patience) for doing this job, it might just throw the packet away, rather than replying. That's what you're seeing with hop 4.

This is why it's important to focus *first* on the final destination. When you see problems with the final destination, then you look back at intermediate hops for guidance about where the problem originates.

In your example, the final destination is responding just fine (no packet loss). That sounds like exactly what you're seeing with the command prompt. Since the command prompt only looks at the final destination (no intermediate hops), that's pretty much right what you should expect.

The thing that's making you think there's a problem is the packet loss at hop 4. We talk about this phenomenon in several places, but here are a couple of articles:

http://www.nessoft.com/kb/5
http://www.nessoft.com/kb/24
and an analogy:
http://www.pingplotter.com/manual/standard/voiptroubleshooting.html#traffic

Hopefully, that helps explain what's going on.

- Pete

Cheers for that Pete!