interpretar resultados de ping

Estoy haciendo ping a yahoo.com y estoy desconcertado por el resultado.

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

Entiendo vagamente el valor TTL como el número de saltos que atraviesa el paquete para llegar a su destino, pero no entiendo cómo TTL puede tener una variación tan dramática de +/- 1 en tan poco tiempo.

Además, parece que Yahoo tiene algún tipo de limitación de velocidad implementada ya que un ping persistente comenzará a agotar el tiempo de espera después de unos 20 paquetes. ¿Esto es normal? ¡bing.com ni siquiera me responde!

Al hacer ping a google.com, los TTL son consistentes.

Al hacer ping a Twitter.com a veces obtengo TTL = 249, pero generalmente TTL-58.

¿Que esta pasando? ¿Mi ISP no es bueno o hay una explicación menos siniestra?

Lo más probable es que esto sea causado por el equilibrio de carga en múltiples redes. Cada ping tomará una ruta diferente y, en consecuencia, tendrá un valor TTL diferente.

También leí acerca de los proveedores de motores de búsqueda que hacen cosas extrañas con TTL, pero simplemente está pasando por una ruta diferente en ambos sentidos.

Los valores de TTL son diferentes cuando provienen de diferentes sistemas operativos:

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

Y sí, algunos sitios dejarán de responder a ICMP después de un cierto período de tiempo o cuando se alcance un límite de velocidad. Creo que el DNS de Google en 8.8.8.8 finalmente se detiene después de un tiempo.

Otros han mencionado el escenario de trayectos múltiples para explicar la variación en el tiempo de retraso. Con los enlaces ECMP (Equal Cost Multi Path) puede tener un escenario según el resultado que proporcionó en el ping a Yahoo, donde el retraso cambia entre los resultados pero de manera razonablemente consistente. Por lo tanto, parece que su tráfico se está desplazando por los mismos dos o tres caminos, con diferentes longitudes (retrasos) (aunque eso es solo especulación, nadie puede decirlo con certeza con la información proporcionada).

Además, parece que Yahoo tiene algún tipo de limitación de velocidad implementada ya que un ping persistente comenzará a agotar el tiempo de espera después de unos 20 paquetes. ¿Esto es normal? ¡bing.com ni siquiera me responde!

¡Algunas redes filtran el tráfico ICMP, lo que me parece muy molesto! Así que eso podría explicar el escenario "sin pings en absoluto". Para escenarios en los que tiene algunas respuestas, o respuestas limitadas, la red podría estar implementando una tecnología como Control Plan Policing de Cisco (o su proveedor equivalente).

Al hacer ping a Twitter.com a veces obtengo TTL = 249, pero generalmente TTL-58.

Cuando tenga una variación de resultados menos estable, podrían estar presentes rutas de Ruta múltiple sin costo igual o un cambio en el ingeniero de tráfico debido a un problema de enlace en algún lugar de la ruta. De nuevo, no puedo decir con la información dada.

La variación de TTL en estos paquetes podría explicarse por uno o varios enrutadores que tardan mucho en procesar los paquetes. El TTL se reduce en uno después de cada salto si el tiempo a través del enrutador es inferior a un segundo. Si el tiempo empleado en el enrutador es mayor, un segundo TTL se reducirá en dos en lugar de uno.

Ver RFC791 página 29:

Tiempo para vivir

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.