Paquet IP et TTL
Fermé
Azerty768
-
11 juin 2012 à 20:16
brupala Messages postés 106115 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 28 mars 2023 - 12 juin 2012 à 18:01
brupala Messages postés 106115 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 28 mars 2023 - 12 juin 2012 à 18:01
A voir également:
- Ttl ip
- Ethernet n'a pas de configuration ip valide - Guide
- Localiser ip - Guide
- Changer adresse ip - Guide
- Adresse ip telephone - Guide
- Connaitre son adresse ip - Guide
4 réponses
sdj79
Messages postés
295
Date d'inscription
samedi 16 décembre 2000
Statut
Contributeur
Dernière intervention
30 avril 2013
118
11 juin 2012 à 23:54
11 juin 2012 à 23:54
Bonsoir,
Il n'y a pas de raison qu'une machine déroge la règle du TTL-1 au passage. Par contre, la valeur de base du paquet, lorsqu'il est créé varie.
C'est l'application qui génère le paquet qui peut décider de donner telle ou telle valeur (entre 1 et 255).
C'est d'ailleurs sur ce principe que repose la commande Traceroute.
Il n'y a pas de raison qu'une machine déroge la règle du TTL-1 au passage. Par contre, la valeur de base du paquet, lorsqu'il est créé varie.
C'est l'application qui génère le paquet qui peut décider de donner telle ou telle valeur (entre 1 et 255).
C'est d'ailleurs sur ce principe que repose la commande Traceroute.
Ahh d'accords merci je comprends mieux ! Je pensais qu'un paquet avait systèmatiquement un TTL à 255.
Pourquoi la valeur du TTL varie d'un OS à l'autre ? Ca pose un problème de le laisser à 255 ?
Deuxième question qui me vient à l'esprit. La valeur du TTL correspond uniquement à l'allez (émetteur vers recepteur) ou bien allez-retour (émetteur vers recepteur, ensuite recepteur qui répond à l'emetteur) ?
Pourquoi la valeur du TTL varie d'un OS à l'autre ? Ca pose un problème de le laisser à 255 ?
Deuxième question qui me vient à l'esprit. La valeur du TTL correspond uniquement à l'allez (émetteur vers recepteur) ou bien allez-retour (émetteur vers recepteur, ensuite recepteur qui répond à l'emetteur) ?
Bonjour,
Ce qu'il faut savoir sur le Time To Live, c'est qu'il a été mis en place pour que les paquets ne soit pas routés à l'infini sur Internet. Cette valeur est aléatoire mais comme l'a précisé sdj79, elle va de 1 à 255, c'est à dire la valeur d'un octet en décimal.
Maintenant, aujourd'hui pour joindre une machine distante sur Internet, il est rare que tu dépasses 50-60 sauts. Donc que cela varie d'un OS à au autre n'est pas bien grave et le TTL correspond au au sens émetteur --> récepteur.
Ce qu'il faut savoir sur le Time To Live, c'est qu'il a été mis en place pour que les paquets ne soit pas routés à l'infini sur Internet. Cette valeur est aléatoire mais comme l'a précisé sdj79, elle va de 1 à 255, c'est à dire la valeur d'un octet en décimal.
Maintenant, aujourd'hui pour joindre une machine distante sur Internet, il est rare que tu dépasses 50-60 sauts. Donc que cela varie d'un OS à au autre n'est pas bien grave et le TTL correspond au au sens émetteur --> récepteur.
brupala
Messages postés
106115
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
28 mars 2023
13 804
12 juin 2012 à 16:41
12 juin 2012 à 16:41
Salut,
c'est juste, mais la valeur n'est pas aléatoire, elle est définie par l' application.
souvent 255 ou 128 ou 64, peu d'importance, car c'est vrai que si un paquet n'est pas arrivé au bout de 64 routeurs traversés, il y a des chances qu'il n'arrive pas plus au bout de 128.
Certains protocoles comme l'autoconfiguration ipv6 (multicast lestener report) ou ebgp forcent obligatoirement le TTL (hop limit) à 1 afin de s'assurer que les paquets ne vont pas aller se balader hors du segment.
c'est juste, mais la valeur n'est pas aléatoire, elle est définie par l' application.
souvent 255 ou 128 ou 64, peu d'importance, car c'est vrai que si un paquet n'est pas arrivé au bout de 64 routeurs traversés, il y a des chances qu'il n'arrive pas plus au bout de 128.
Certains protocoles comme l'autoconfiguration ipv6 (multicast lestener report) ou ebgp forcent obligatoirement le TTL (hop limit) à 1 afin de s'assurer que les paquets ne vont pas aller se balader hors du segment.
Oui, cela parait plus logique.
Par contre pour l'eBGP ce que tu dis n'est pas exact. Si le hop limit est paramétré à 1 ce n'est pas pour s'assurer que les paquets se baladent sur un autre segment (pour cela tu précises l'interface source utilisée par le routeur pour ce protocole), mais pour garantir la neutralité d'Internet (ce dont devrait s'inspirer nos politiciens) entre 2 routeurs de 2 AS différents.
En effet l'eBGP est le protocole qui aiguille le trafic mondial d'Internet, pour cela une neutralité doit être imposée entre chaque peer pour que l'un ne puisse pas écraser ou réécrire les annonces des autres. L'une des conditions pour cela est que les routeurs de 2 AS différents soient directement interconnectés en point à point pour ne pas ajouter d'équipements actifs pouvant modifier ces annonces, d'où le TTL=1.
Cependant, il s'est très vite avéré, compte-tenu du maillage d'un AS vers d'autres AS, que tout le monde ne pourrait pas s'interconnecter de la sorte. Donc les RFC ont évolué pour accepter de l'eBGP Multi-Hop où tu précises le nombre de sauts traversés (TTL) jusqu'à ton peer.
Par contre pour l'eBGP ce que tu dis n'est pas exact. Si le hop limit est paramétré à 1 ce n'est pas pour s'assurer que les paquets se baladent sur un autre segment (pour cela tu précises l'interface source utilisée par le routeur pour ce protocole), mais pour garantir la neutralité d'Internet (ce dont devrait s'inspirer nos politiciens) entre 2 routeurs de 2 AS différents.
En effet l'eBGP est le protocole qui aiguille le trafic mondial d'Internet, pour cela une neutralité doit être imposée entre chaque peer pour que l'un ne puisse pas écraser ou réécrire les annonces des autres. L'une des conditions pour cela est que les routeurs de 2 AS différents soient directement interconnectés en point à point pour ne pas ajouter d'équipements actifs pouvant modifier ces annonces, d'où le TTL=1.
Cependant, il s'est très vite avéré, compte-tenu du maillage d'un AS vers d'autres AS, que tout le monde ne pourrait pas s'interconnecter de la sorte. Donc les RFC ont évolué pour accepter de l'eBGP Multi-Hop où tu précises le nombre de sauts traversés (TTL) jusqu'à ton peer.
brupala
Messages postés
106115
Date d'inscription
lundi 16 juillet 2001
Statut
Membre
Dernière intervention
28 mars 2023
13 804
12 juin 2012 à 18:01
12 juin 2012 à 18:01
Merci de la précision sur ebgp, je n'avais pas regardé aussi loin ;-)