Est-il normal qu'un FAI ait deux fois la même IP sur un même itinéraire?


8

Si je traceroute hors de mon réseau domestique, je vois la même IP deux fois de suite directement après mon routeur:

  1     1 ms     1 ms     1 ms  router
  2    17 ms    16 ms    16 ms  217.0.117.61
  3    16 ms    16 ms    16 ms  217.0.117.61
  4    17 ms    17 ms    17 ms  87.186.233.102
  5    26 ms    24 ms    24 ms  217.239.39.2
  6    24 ms    24 ms    25 ms  ...

Est-ce normal ou pourrait-il s'agir d'une mauvaise configuration de la part du FAI?


3
Si l'IP se trouve sur des sauts non adjacents, une mauvaise configuration est probable. mais dans votre cas, ils sont adjacents, ce qui pourrait signifier que cet appareil réduit simplement le paquet TTL deux fois.
Robert

Réponses:


14

Si cela se produit une fois ou rarement

Tous les paquets IP ont un champ de durée de vie ( TTL ). Ce champ est décrémenté de un par chaque routeur qui transfère un paquet. Si un routeur décrémente le TTL à 0, il abandonne le paquet et génère un paquet d'erreur ICMP TTL dépassé et le renvoie à l'expéditeur.

Traceroute utilise cette fonctionnalité pour envoyer des paquets avec des TTL augmentant séquentiellement. Cela permet à traceroute de construire une image du chemin entre la source et la destination.

Dans votre cas, il y avait probablement deux chemins possibles de votre routeur vers 217.0.117.61, où l'un était plus long que l'autre. Donc, ce qui s'est passé était:

  1. Le paquet envoyé avec TTL = 1 a atteint votre routeur, qui a répondu.
  2. Le paquet envoyé avec TTL = 2
    • atteint votre routeur, qui a décrémenté le TTL à 1 et l'a envoyé,
    • atteint alors 217.0.117.61, qui a répondu.
  3. Le paquet envoyé avec TTL = 3
    • atteint votre routeur, qui a décrémenté le TTL à 2 et l'a envoyé,
    • puis atteint un routeur inconnu, qui a décrémenté le TTL à 1 et l'a envoyé,
    • atteint alors 217.0.117.61, qui a répondu.

C'est pourquoi vous avez deux fois la même entrée. Cela aurait pu être pire, avec chaque IP répertoriée deux fois, mais apparemment le routeur pour donner la première réponse 217.0.117.61 n'a plus jamais participé à la trace, donc tous les paquets suivants sont passés par le routeur inconnu dont l'IP n'a jamais été retournée.

Si cela arrive toujours

Ensuite, c'est à cause de la façon dont votre FAI a configuré son réseau. Les adresses IP de votre liste appartiennent à Deutsche Telekom AG qui possède un énorme réseau interne avec des nœuds sophistiqués hautes performances, dont l'un semble répondre deux fois.

Il y a quelques explications possibles:

  • Le FAI dispose d'un pare-feu qui répond aux demandes de traceroute. Un pare-feu d'entreprise est un ordinateur spécialisé à part entière. Il peut répondre aux demandes de tracroute, s'il est programmé pour, avec l'adresse IP programmée, qui peut être celle du nœud qu'il protège.

  • Un routeur d'entreprise peut répondre à la fois à partir de ses interfaces internes et externes. Un tel routeur à haute vitesse et à haut débit est en fait un réseau dans une boîte avec des sous-routeurs spécialisés comme composants. Les réponses peuvent provenir des sous-routeurs orientés vers l'avant et vers l'arrière, répondant avec la même IP.


Il est toujours deux fois sur le chemin. Comment pourrait-il ne pas passer le routeur inconnu dans le deuxième cas?
Adam Lindberg

2
Si cela se produit toujours, c'est à cause de la façon dont votre FAI a configuré son réseau. Il y a quelques autres explications que je n'ai pas mentionnées car moins probables: (1) Le FAI a un pare-feu qui répond aux demandes de traceroute, (2) La demande passe un NAT au FAI et vous obtenez une réponse à la fois de son intérieur et les interfaces externes, mais l'interface interne mappe son IP à celle externe.
harrymc

Toutes les adresses IP que vous avez répertoriées se trouvent au sein de Deutsche Telekom AG. Il est logique qu'ils aient un énorme réseau interne avec de nombreuses traductions,
harrymc

1

Étant donné que cela se produit de manière cohérente, je pense que la cause la plus probable est un bogue dans l'un des micrologiciels des routeurs qui fait qu'il ne parvient pas à supprimer le paquet de trace (et à envoyer un rapport "TTL dépassé") quand il le devrait, ou à l'envoyer avant devrait. Voici un exemple du premier problème de la page de manuel BSD traceroute :

A sample use and output might be:

 [yak 71]% traceroute nis.nsf.net.
 traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 56 byte packet
 1 helios.ee.lbl.gov (128.3.112.1)  19 ms 19 ms  0 ms
 2 lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 3 lilac-dmc.Berkeley.EDU (128.32.216.1)  39 ms  39 ms  19 ms
 4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23)  39 ms  40 ms  39 ms
 [...]

Note that lines 2 & 3 are the same.  This is due to a buggy kernel on the
2nd hop system - lbl-csam.arpa - that forwards packets with a zero ttl (a
bug in the distributed version of 4.3 BSD).

Dans cet exemple, c'est le deuxième routeur qui a le bogue, et le troisième routeur est répertorié à la fois # 2 et # 3.

D'un autre côté, considérez ce qui se passerait si le deuxième routeur avait un bogue qui lui faisait perdre des paquets lorsque le TTL atteignait 1 au lieu de 0:

  1. Le paquet de trace envoyé avec TTL = 1 est décrémenté à 0 au premier routeur, ce qui le supprime et signale que TTL a été dépassé, et il apparaît donc comme le saut # 1. Tout va bien ici.
  2. Le paquet envoyé avec TTL = 2 est décrémenté à 1 au premier routeur; puis le deuxième routeur le décrémente à 0, le supprime et le signale, et il apparaît donc comme le saut # 2. Encore une fois, tout va bien ici.
  3. Le paquet envoyé avec TTL = 3 est décrémenté à 2 au premier routeur; puis le deuxième routeur le décrémente à 1, le supprime et le signale par erreur, et il apparaît donc comme le saut # 3.

Encore une fois, c'est le deuxième routeur qui a un bogue, mais dans ce cas, c'est le deuxième routeur qui est répertorié deux fois (dans l'exemple de la page de manuel, c'est le troisième qui est répertorié deux fois).

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.