interprétation des résultats de ping


11

Je clique sur yahoo.com et je suis perplexe devant le résultat.

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

Je comprends vaguement la valeur TTL comme le nombre de sauts que le paquet traverse pour atteindre sa destination, mais je ne comprends pas comment TTL peut avoir une variation aussi dramatique de +/- 1 en si peu de temps.

En outre, il semble que Yahoo ait mis en place une sorte de limitation de débit, car un ping persistant commencera à expirer après environ 20 paquets. Est-ce normal? bing.com ne me répond même pas!

Lorsque vous envoyez une requête ping à google.com, les TTL sont cohérents.

Lorsque j'effectue un ping sur Twitter.com, j'obtiens parfois TTL = 249, mais généralement TTL-58.

Que se passe-t-il? Mon FAI est-il inutile ou y a-t-il une explication moins sinistre?


1
L'équilibrage de charge ibgp par l'un de vos amonts est une cause possible, mais nous n'avons pas suffisamment d'informations pour le savoir. Vous pouvez le découvrir en trachant ... pls google for mtr et explorez plus
Mike Pennington

Si vous pouvez fournir votre IP source (curl my.ip.fi ), je peux essayer plusieurs points de vue pour voir les options de chemin de retour
ytti

Réponses:


14

Cela est probablement dû à l'équilibrage de charge sur plusieurs réseaux. Chaque ping prendra un chemin différent et aura donc une valeur TTL différente.

J'ai également lu que les fournisseurs de moteurs de recherche font des choses étranges avec TTL, mais que cela passe par une route différente dans les deux cas.

Les valeurs TTL sont différentes lorsqu'elles proviennent de différents systèmes d'exploitation:

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

Et oui, certains sites cesseront de répondre à ICMP après un certain temps ou lorsqu'une limite de taux est atteinte. Je crois que le DNS de Google sur 8.8.8.8 s'arrête finalement après un certain temps.


6

D'autres ont mentionné le scénario à trajets multiples pour expliquer la variation du temps de retard. Avec les liens ECMP (Equal Cost Multi Path), vous pouvez avoir un scénario selon la sortie que vous avez fournie dans le ping vers Yahoo, où le délai change entre les résultats mais de manière raisonnablement cohérente. Il semble donc que votre trafic soit haché sur les mêmes deux ou trois chemins, avec différentes longueurs (retards) (bien que ce ne soit que de la spéculation, je ne peux pas dire avec certitude avec les informations fournies).

En outre, il semble que Yahoo ait mis en place une sorte de limitation de débit, car un ping persistant commencera à expirer après environ 20 paquets. Est-ce normal? bing.com ne me répond même pas!

Certains réseaux filtrent le trafic ICMP que je trouve extrêmement ennuyeux! Cela pourrait donc expliquer le scénario «pas de pings du tout». Pour les scénarios dans lesquels vous avez des réponses, ou des réponses limitées, le réseau peut implémenter une technologie telle que Cisco Control Plan Policing (ou leur équivalent fournisseur).

Lorsque j'effectue un ping sur Twitter.com, j'obtiens parfois TTL = 249, mais généralement TTL-58.

Lorsque vous avez une variation de résultat moins stable, des itinéraires à chemins multiples à coût égal peuvent être présents, ou un changement d'ingénieur du trafic en raison d'un problème de liaison à un endroit du chemin. Encore une fois, je ne peux pas dire avec les informations fournies.


3

La variance de TTL sur ces paquets pourrait s'expliquer par un ou des routeurs qui mettent beaucoup de temps à traiter les paquets. TTL est décrémenté de un après chaque saut si le temps passé par le routeur est inférieur à une seconde. Si le temps pris par le routeur est supérieur à une seconde TTL sera décrémenté de deux plutôt que d'un.

Voir RFC791 page 29:

Temps de vivre

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.

2
Avec des temps de ping inférieurs à 300 ms, il est peu probable que ce soit un facteur dans ce cas, bien qu'il soit bon pour les gens de comprendre que c'est également une fonction de TTL.
Apprendre

Je serais très inquiet si un saut prenait plus d'une seconde pour traiter un paquet. Mais je n'étais pas au courant de cela, je pensais que le champ avait changé en passant par un processeur, belle trouvaille!
Artanix

3
Le TTL n'est pas décrémenté temporairement dans la vraie vie comme le RFC le suggère, il s'agit strictement du «nombre de sauts» et est nommé comme tel dans IPv6.
ytti

@ytti, c'est vrai que cela devrait être le cas, mais certains appareils seront conformes à cette section du RFC. Bien que la plupart des appareils grand public ne le soient pas, j'ai vu cet étui d'angle sur du matériel "hors marque".
Apprendre

Je l'ai vu aussi ... c'est comme ça que je le savais.
GerryEgan
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.