interpreting ping results

Question

I'm pinging yahoo.com and am I'm puzzled by the result.

C:\Users\jon>ping -t yahoo.com

Pinging yahoo.com [98.138.253.109] with 32 bytes of data:
Reply from 98.138.253.109: bytes=32 time=195ms TTL=46
Reply from 98.138.253.109: bytes=32 time=230ms TTL=44
Reply from 98.138.253.109: bytes=32 time=175ms TTL=45
Reply from 98.138.253.109: bytes=32 time=208ms TTL=44
Reply from 98.138.253.109: bytes=32 time=180ms TTL=46
Reply from 98.138.253.109: bytes=32 time=206ms TTL=44
Reply from 98.138.253.109: bytes=32 time=209ms TTL=44
Reply from 98.138.253.109: bytes=32 time=173ms TTL=46
Reply from 98.138.253.109: bytes=32 time=170ms TTL=46
Reply from 98.138.253.109: bytes=32 time=224ms TTL=45
Reply from 98.138.253.109: bytes=32 time=200ms TTL=45
Reply from 98.138.253.109: bytes=32 time=172ms TTL=46
Reply from 98.138.253.109: bytes=32 time=258ms TTL=44

I vaguely understand the TTL value as the number of hops that the packet traverses to reach its destination, but I don't understand how TTL can have such a dramatic +/- 1 variance in such a short amount of time.

Also, it seems Yahoo has some kind of rate-limiting implemented as a persistent ping will start timing out after about 20 packets. Is this normal? bing.com doesn't even reply to me!

When pinging google.com the TTLs are consistent.

When pinging Twitter.com sometimes I get TTL=249, but usually TTL-58.

What's going on? Are my ISP up to no good or is there a less sinister explanation?

Answer 1

Most likely this is caused by load balancing across multiple networks. Each ping will take a different path and accordingly will have a difference TTL value.

I also read about search engine providers doing strange things with TTL, but its just going through a different route either way.

TTL values are different when sourced from different operating systems:

• Windows: 128
• Linux: 64
• Cisco: 255
• Solaris: 255

And yes, some sites will stop responding to ICMP after a certain amount of time, or when a rate limit is hit. I believe Google's DNS on 8.8.8.8 eventually stops after a while.

Answer 2

Others have mentioned the multipath scenario to explain the variation in delay time. With ECMP (Equal Cost Multi Path) links you can have a scenario as per the output you provided in the ping to Yahoo, where the delay changes between results but reasonably consistently. So it looks like your traffic is being hashed over the same two or three paths, with varying lengths (delays) (although that is only speculation, I no one can say for certain with the information given).

Also, it seems Yahoo has some kind of rate-limiting implemented as a persistent ping will start timing out after about 20 packets. Is this normal? bing.com doesn't even reply to me!

Some networks do filter ICMP traffic which I find hugely annoying! So that could explain the "no pings at all" scenario. For scenarios where you have some replies, or limited replies, the network could be implementing a technology like Cisco's Control Plan Policing (or their vendor equivalent).

When pinging Twitter.com sometimes I get TTL=249, but usually TTL-58.

When you are having less stable result variation, un-Equal Cost Multi Path routes could be present, or a change in traffic engineer due to a link issue some where in the path. Again, can't say with the information given.

Answer 3

The variance of TTL on these packets could be explained by a router(s) that are taking a long time to process the packets. TTL is decremented by one after each hop if the time through the router is less than one second. If the time taken through the router is greater that one second TTL will be decremented by two rather than one.

See RFC791 page 29:

Time to Live

The time to live is set by the sender to the maximum time the
datagram is allowed to be in the internet system.  If the datagram
is in the internet system longer than the time to live, then the
datagram must be destroyed.

This field must be decreased at each point that the internet header
is processed to reflect the time spent processing the datagram.
Even if no local information is available on the time actually
spent, the field must be decremented by 1.  The time is measured in
units of seconds (i.e. the value 1 means one second).  Thus, the
maximum time to live is 255 seconds or 4.25 minutes.  Since every
module that processes a datagram must decrease the TTL by at least
one even if it process the datagram in less than a second, the TTL
must be thought of only as an upper bound on the time a datagram may
exist.  The intention is to cause undeliverable datagrams to be
discarded, and to bound the maximum datagram lifetime.

Some higher level reliable connection protocols are based on
assumptions that old duplicate datagrams will not arrive after a
certain time elapses.  The TTL is a way for such protocols to have
an assurance that their assumption is met.