Il reste quelques jours avant le début d'un nouveau flux au cours "Network Engineer" d'OTUS. À cet égard, nous souhaitons partager avec vous la traduction de documents utiles sur le sujet.
Une série d'articles de blog sur les conseils et astuces de dépannage du ping IPv6 (ICMPv6 Echo Request / Echo Reply)Veuillez noter que j'utilise Linux (spécifiquement Fedora 31), cependant j'espère que la syntaxe de la commande ping pour d'autres systèmes d'exploitation devrait être très similaire.Envoyez un ping à tous les hôtes IPv6 sur le canal
La première et la plus simple astuce consiste à envoyer une requête ping à tous les hôtes IPv6 sur le canal.IPv6 utilise des adresses de multidiffusion pour tous les types de communications un-à-plusieurs. Il n'y a pas d'adresses IPv6 de diffusion (ou de diffusion). Cela distingue IPv6 d'IPv4, où il existe plusieurs types d'adresses de diffusion, par exemple, l'adresse de "diffusion limitée" 255.255.255.255 [RFC1122].Cependant, il existe une adresse IPv6 «multidiffusion tous nœuds», nous allons donc l'utiliser pour envoyer une requête ping à tous les nœuds IPv6 du canal. (Une adresse de «diffusion» n'est en fait qu'une adresse de multidiffusion nommée spécialement, qui est un groupe de multidiffusion qui inclut tous les nœuds. Notez que, par exemple, le bit d'adresse de «groupe» ou de multidiffusion est inclus dans les adresses de diffusion Ethernet au niveau de la liaison).Adresse IPv6 de multidiffusion de tous les nœuds pour le canal: ff02::1. ffindique une adresse IPv6 de multidiffusion. Le 0 suivant fait partie de l'indicateur avec des bits non définis.Définit en outre 2la zone du groupe de multidiffusion. Contrairement aux adresses de multidiffusion IPv4, les adresses de multidiffusion IPv6 ont une portée. La valeur d'étendue indique la partie du réseau sur laquelle les paquets de multidiffusion sont autorisés. Une fois que le paquet atteint la limite de la portée spécifiée, le paquet doit être éliminé, que son champ Nombre de sauts soit différent de zéro. Bien sûr, si le compteur de conversion atteint zéro avant d'atteindre la frontière spécifiée du groupe de multidiffusion, il est également immédiatement réinitialisé. Voici une liste complète de la portée de multidiffusion IPv6.Enfin, ::1indique le groupe de multidiffusion tous nœuds.À propos de l'adresse, ff02::1il convient de noter qu'elle est ambiguë. Sur un hôte IPv6 avec plusieurs interfaces, comme un routeur ou un hôte multi-hôte, ff02::1il n'y a rien dans l'adresse où vous pouvez spécifier à quelle interface envoyer des pings ICMPv6 ou attendre des pings ICMPv6 à leur arrivée. ff02::1valide et peut être utilisé sur n'importe quelle interface et canal attaché au nœud multi-interface.Par conséquent, lorsque nous envoyons une requête ping à tous les nœuds IPv6 sur le canal, nous devons également indiquer à l'utilitaire pingIPv6 quelle interface utiliser.Définition d'interface - Option de ligne de commande
Comme nous l'avons déjà vu, l'adresse de multidiffusion de tous les nœuds que nous voulons utiliser - ff02::1- ne fournit aucune information sur l'interface à laquelle envoyer et recevoir les paquets de demande d'écho et de réponse d'écho ICMPv6.Alors, comment pouvons-nous spécifier l'interface qui sera utilisée pour l'espace d'adressage multicast ou les adresses Link-Local unicast?Le premier et le plus évident est de le fournir comme paramètre pour l'application que nous utilisons.Pour l'utilitaire, pingnous le fournissons via l'option -I.[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warning: source address might be selected on device other than: enp3s2
PING ff02::1(ff02::1) from :: enp3s2: 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.589 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=5.15 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=58.0 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=62.3 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=62.8 ms (DUP!)
--- ff02::1 ping statistics ---
1 packets transmitted, 1 received, +5 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$
À l'aide de ce ping multidiffusion de tous les nœuds, nous avons reçu des réponses de 6 nœuds IPv6. Les réponses provenaient des adresses IPv6 Link-Local de l'hôte, en commençant par le préfixe fe80::/10.Pour pingempêcher les requêtes d'écho ICMPv6 de continuer sans fin jusqu'à ce que nous l'abandonnions, nous spécifions généralement le nombre de paquets à envoyer via l'option -c. Cependant, cela empêche également le ping de recevoir et d'afficher plus d'une réponse d'écho ICMPv6 lors de l'envoi d'une demande d'écho ICMPv6 multicast. Au lieu de cela, nous avons utilisé l'option -w pour indiquer que le ping doit se terminer après 1 seconde, quel que soit le nombre de pings ou de pings ICMPv6 envoyés ou reçus.Une autre chose à laquelle prêter attention est (DUP!) conclusion sur la deuxième réponse et les réponses suivantes. Ces paquets sont identifiés comme des doublons de la réponse, car ils ont la même valeur de séquence ICMP que les pings ICMPv6 individuels qui ont été envoyés en premier. Ils apparaissent car la demande d'écho de multidiffusion ICMPv6 entraîne plusieurs réponses individuelles de monodiffusion. Le nombre de doublons est également indiqué dans le résumé des statistiques.Définition d'interface - ID de zone
Une autre façon de fournir une interface à utiliser fait partie du paramètre d'adresse IPv6.Nous pouvons voir un exemple de cela dans la sortie ping, où les adresses des nœuds IPv6 qui répondent ont également un suffixe %enp3s2, par exemple:64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms
Cette méthode de définition des interfaces est officiellement décrite dans [RFC4007], "Architecture avec adresses IPv6 spécifiées". Bien qu'ils soient généralement appelés interface du système d'exploitation, ils définissent en fait quelque chose de plus général - une «zone» ou une «étendue».La raison d'avoir des zones plus générales ou des zones d'étendue est parce que, comme mentionné dans [RFC4007], un hôte IPv6 peut avoir plusieurs interfaces IPv6 différentes connectées au même canal. Ces interfaces sont membres de la même zone.Il devrait être possible de regrouper plusieurs interfaces dans la zone sous le système d'exploitation; Actuellement, je ne sais pas si cela est possible sous Linux et comment le faire.En utilisant le suffixe %<zone_id>, nous pouvons supprimer le paramètre de ligne de commande -I ping.[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.606 ms (DUP!)
64 bytes from fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 time=6.23 ms (DUP!)
64 bytes from fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 time=157 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 time=159 ms (DUP!)
64 bytes from fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 time=161 ms (DUP!)
64 bytes from fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 time=179 ms (DUP!)
--- ff02::1%enp3s2 ping statistics ---
1 packets transmitted, 1 received, +7 duplicates, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.106/82.858/179.216/81.281 ms
[mark@opy ~]$
Réponses d'adresse de liaison locale
De ce ping multicast tous les nœuds, nous avons reçu un total de 6 réponses uniques.Ces réponses provenaient des adresses d'hôte IPv6 Unicast Link-Local. Par exemple, voici la première réponse:64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
Adresses IPv6 Unicast Link-Local requises sur toutes les interfaces IPv6 [RFC4291], architecture d'adressage IP version 6. La raison en est que l'hôte IPv6 a toujours automatiquement une adresse IPv6 unicast, qu'il peut utiliser, au moins pour communiquer avec d'autres hôtes via ses canaux directement connectés. Cela inclut la communication avec les applications d'autres hôtes via des adresses d'hôte Link-Local.Cela simplifie le développement et la mise en œuvre de protocoles tels que la découverte de voisins IPv6 et OSPFv3. Il permet également aux applications d'utilisateur final sur les hôtes de communiquer sur le canal sans nécessiter d'autre infrastructure IPv6 de support sur le canal. La communication directe entre les hôtes IPv6 connectés ne nécessite pas de routeur IPv6 ou de serveur DHCPv6 pour la connexion.Les adresses Link-Local commencent par un préfixe 10 bits fe80, suivi de 54 bits zéro, suivi d'un identifiant d'interface 64 bits (IID). Dans la première réponse ci 2392:6213:a15b:66ff- dessus , il s'agit d'un IID 64 bits.Multidiffusion en boucle
Par défaut, les paquets de multidiffusion sont renvoyés en interne au nœud qui les envoie. Cela se produit pour les adresses IPv6 et IPv4.La raison de ce comportement par défaut est que lors de l'envoi de paquets de multidiffusion, il peut également y avoir une application de multidiffusion locale en cours d'exécution sur l'hôte d'envoi lui-même, ainsi que quelque part sur le réseau. Cette application locale doit également recevoir des paquets de multidiffusion.Nous pouvons voir cette boucle locale de multidiffusion dans notre sortie ping:[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 ms
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.453 ms (DUP!)
...
La première et la plus rapide réponse (0,106 ms contre 0,453 ms) provient de l'adresse Link-Local configurée sur l'interface elle-même enp3s2.[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$
L'utilitaire pingfournit un moyen de supprimer les commentaires locaux du mailing multicast à l'aide d'un paramètre -L. Si nous envoyons un ping multidiffusion de tous les nœuds avec cet indicateur, les réponses sont limitées aux nœuds distants. Nous ne recevons pas de réponse de l'adresse Link-Local de l'interface de l'expéditeur.[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 data bytes
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.383 ms
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.467 ms (DUP!)
...
Adresses Ping Link-Local
Comme vous pouvez le deviner, les adresses Link-Local unicast elles-mêmes ne fournissent pas suffisamment d'informations pour indiquer l'interface à utiliser pour les atteindre. Comme dans le cas du ping multicast sur tous les nœuds, nous devons également spécifier l'interface en tant que paramètre de ligne de commande pingou ID de zone avec l'adresse lors du ping des adresses Link-Local.Cette fois, nous pouvons utiliser -cpour limiter le nombre de paquets et de réponses envoyés et reçus ping, car nous effectuons un ping unicast.[mark@opy ~]$ ping -c 1 fe80::f31c:ccff:fe26:a6d9%enp3s2
PING fe80::f31c:ccff:fe26:a6d9%enp3s2(fe80::fad1:11ff:feb7:3704%enp3s2) 56 data bytes
64 bytes from fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 time=0.395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.395/0.395/0.395/0.000 ms
[mark@opy ~]$
Ping (toutes) les autres adresses IPv6?
Dans cet article, nous avons vu comment exécuter une commande ping sur tous les nœuds IPv6 sur un canal à l'aide d'une adresse IPv6 multidiffusion tous nœuds ff02::1. Nous avons également vu comment spécifier l'interface à utiliser avec l'adresse IPv6 de multidiffusion tous nœuds, car l'adresse seule ne peut pas fournir ces informations. Nous avons utilisé un paramètre de ligne de commande pingou spécifié une interface via un suffixe %<zone_id>.Ensuite, nous avons découvert les adresses Link-Local unicast, qui sont les adresses utilisées pour répondre aux demandes d'écho ICMPv6 multicast tous nœuds.Nous avons également vu comment les paquets de multidiffusion retournent par défaut à l'hôte d'envoi et comment les désactiver pour l'utilitaire ping.Enfin, nous avons envoyé une requête ping à une seule adresse Link-Local en utilisant le suffixe%<zone_id>car les adresses Link-Local seules ne fournissent pas d'informations sur l'interface sortante.Qu'en est-il donc d'envoyer une requête ping à tous les autres nœuds et d'obtenir leurs adresses Unicast globales (GUA) (c'est-à-dire leurs adresses Internet publiques) ou leurs adresses Unicast locales uniques (ULA)? Nous en parlerons dans le prochain article de blog.C'est tout.Vous pouvez en savoir plus sur notre cours dans la journée portes ouvertes .