Bis zum Beginn eines neuen Flusses mit der Rate verbleiben noch einige Tage von OTUS. In diesem Zusammenhang möchten wir Ihnen eine Übersetzung nützlichen Materials zu diesem Thema zur Verfügung stellen.
Eine Reihe von Blogbeiträgen mit Tipps und Tricks zur Fehlerbehebung bei IPv6-Ping-Problemen (ICMPv6 Echo Request/Echo Reply)
Bitte beachten Sie, dass ich Linux (insbesondere Fedora 31) verwende, die Ping-Befehlssyntax für andere Betriebssysteme jedoch hoffentlich sehr ähnlich sein sollte.
Pingen Sie alle IPv6-Knoten auf einem Kanal an
Der erste und einfachste Tipp besteht darin, alle IPv6-Knoten auf der Verbindung anzupingen.
IPv6 verwendet Multicast-Adressen für alle Arten der Eins-zu-Viele-Kommunikation. Es gibt keine Broadcast- (oder Broadcast-)IPv6-Adressen. Dies unterscheidet IPv6 von IPv4, wo es mehrere Arten von Broadcast-Adressen gibt, beispielsweise die „Limited Broadcast“-Adresse 255.255.255.255 [RFC1122].
Es gibt jedoch eine „All-Nodes-Multicast“-IPv6-Adresse, daher werden wir diese verwenden, um alle IPv6-Knoten auf der Verbindung anzupingen. (Eine „Broadcast“-Adresse ist eigentlich nur eine speziell benannte Multicast-Adresse, bei der es sich um eine Multicast-Gruppe handelt, die alle Knoten umfasst. Beachten Sie, dass beispielsweise das „Gruppen“- oder Multicast-Adressbit in Ethernet-Broadcast-Adressen auf der Verbindungsschicht aktiviert ist ).
Multicast-IPv6-Adresse aller Knoten für den Kanal: ff02::1. ff bezeichnet eine Multicast-IPv6-Adresse. Die nächste 0 ist der Teil des Flags mit nicht gesetzten Bits.
Weiter 2 definiert den Bereich einer Multicast-Gruppe. Im Gegensatz zu Multicast-IPv4-Adressen haben Multicast-IPv6-Adressen einen Bereich. Der Bereichswert gibt den Teil des Netzwerks an, über den ein Multicast-Paket weitergeleitet werden darf. Sobald ein Paket die Grenze des angegebenen Bereichs erreicht, muss das Paket verworfen werden, unabhängig davon, ob sein Hop Count-Feld ungleich Null ist. Wenn die Hop-Anzahl vor Erreichen der angegebenen Multicast-Gruppengrenze Null erreicht, wird sie natürlich auch sofort zurückgesetzt. Hier ist eine vollständige Liste des IPv6-Multicast-Bereichs.
Schließlich wird die ::1 Gibt eine Multicast-Gruppe mit allen Knoten an.
Über die Adresse ff02::1 Es ist zu beachten, dass es mehrdeutig ist. Auf einem IPv6-Host mit mehreren Schnittstellen, z. B. einem Router oder einem Multihomed-Host, die Adresse ff02::1 Es gibt nichts, wo Sie angeben können, an welche Schnittstelle ICMPv6-Echo-Anfragen gesendet werden sollen, oder erwarten können, ICMPv6-Echo-Antworten zu erhalten, wenn sie eintreffen. ff02::1 ist gültig und kann auf allen Schnittstellen und Kanälen verwendet werden, die an den Multi-Interface-Knoten angeschlossen sind.
Wenn wir also alle IPv6-Knoten auf einem Link anpingen, müssen wir das Dienstprogramm irgendwie auch darüber informieren ping für IPv6, welche Schnittstelle verwendet werden soll.
Schnittstellen definieren – Befehlszeilenoption
Wie wir bereits gesehen haben, ist die All-Node-Multicast-Adresse, die wir verwenden möchten, − ff02::1 – Bietet keine Informationen darüber, welche Schnittstelle ICMPv6-Echo-Anfrage- und Echo-Antwortpakete senden und empfangen soll.
Wie geben wir also die Schnittstelle an, die für den Multicast-Adressraum oder den Unicast-Link-Local-Adressraum verwendet werden soll?
Die erste und naheliegendste Möglichkeit besteht darin, es als Parameter für die von uns verwendete Anwendung bereitzustellen.
Für den Nutzen ping Wir bieten es über die Option an -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 ~]$Mithilfe dieses Multicast-Pings für alle Knoten haben wir Antworten von 6 IPv6-Knoten erhalten. Die Antworten kamen von Link-Local-IPv6-Knotenadressen, beginnend mit dem Präfix fe80::/10.
Dass ping nicht unbegrenzt ICMPv6-Echoanfragen sendet, bis wir sie unterbrechen, geben wir normalerweise die Anzahl der zu sendenden Pakete über die Option -c an. Dies verhindert jedoch auch, dass Ping beim Senden einer Multicast-ICMPv6-Echo-Anfrage mehr als eine ICMPv6-Echo-Antwort akzeptiert und anzeigt. Stattdessen haben wir die Option -w verwendet, um anzugeben, dass der Ping nach 1 Sekunde abgeschlossen sein soll, unabhängig davon, wie viele ICMPv6-Echo-Anfragen oder Echo-Antworten gesendet oder empfangen wurden.
Eine weitere Sache, auf die Sie achten sollten, ist (DUP!) Ausgabe bei der zweiten und den folgenden Antworten. Diese Pakete werden als doppelte Antworten identifiziert, da sie denselben ICMP-Sequenzwert haben wie die einzelnen ICMPv6-Echoanforderungen, die zuerst gesendet wurden. Sie treten auf, weil eine ICMPv6-Multicast-Echo-Anfrage zu mehreren einzelnen Unicast-Antworten führt. Die Anzahl der Duplikate wird auch in der Statistikzusammenfassung angezeigt.
Schnittstellen definieren – Zonen-ID
Eine andere Möglichkeit, eine Schnittstelle zur Verwendung bereitzustellen, ist als Teil eines IPv6-Adressparameters.
Ein Beispiel dafür sehen wir in der Ping-Ausgabe, wo auch die Adressen der antwortenden IPv6-Hosts das Suffix haben %enp3s2zum Beispiel:
64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 msDiese Methode zur Spezifikation von Schnittstellen wird offiziell in [RFC4007], „IPv6 Defined Address Architecture“, beschrieben. Obwohl sie normalerweise als Betriebssystemschnittstelle bezeichnet werden, definieren sie tatsächlich etwas Allgemeineres – eine „Zone“ oder einen „Bereich“.
Der Grund für allgemeinere Zonen oder Bereichszonen liegt darin, dass ein IPv4007-Knoten, wie in [RFC6] erwähnt, über mehrere verschiedene IPv6-Schnittstellen verfügen kann, die mit demselben Kanal verbunden sind. Diese Schnittstellen sind Mitglieder derselben Zone.
Es sollte möglich sein, mehrere Schnittstellen innerhalb einer Zone unter dem Betriebssystem zu gruppieren; Derzeit weiß ich nicht, ob dies unter Linux möglich ist und wie es geht.
Verwendung des Suffixes %<zone_id>können wir die Befehlszeilenoption entfernen -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 ~]$Link-Local-Adressantworten
Von diesem Multicast-Ping für alle Knoten haben wir insgesamt 6 eindeutige Antworten erhalten.
Diese Antworten kamen von Unicast-Link-Local-IPv6-Hostadressen. Hier ist zum Beispiel die erste Antwort:
64 bytes from fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 time=0.106 msUnicast Link-Local IPv6-Adressen sind auf allen IPv6-fähigen Schnittstellen erforderlich [RFC4291], „IP Version 6 Addressing Architecture“. Der Grund dafür ist, dass ein IPv6-Knoten immer automatisch über eine Unicast-IPv6-Adresse verfügt, über die er zumindest mit anderen Knoten auf seinen direkt verbundenen Verbindungen kommunizieren kann. Dazu gehört die Kommunikation mit Anwendungen auf anderen Hosts über Link-Local-Hostadressen.
Dies vereinfacht den Entwurf und die Implementierung von Protokollen wie IPv6 Neighbor Discovery und OSPFv3. Außerdem können Endbenutzeranwendungen auf Hosts über den Kanal kommunizieren, ohne dass eine andere unterstützende IPv6-Infrastruktur auf dem Kanal erforderlich ist. Für die direkte Kommunikation zwischen verbundenen IPv6-Hosts ist kein IPv6-Router oder DHCPv6-Server für die Verbindung erforderlich.
Link-Local-Adressen beginnen mit einem 10-Bit-Präfix fe80, gefolgt von 54 Nullbits und dann einer 64-Bit-Schnittstellenkennung (IID). In der obigen ersten Antwort 2392:6213:a15b:66ff ist eine 64-Bit-IID.
Loop-Multicast
Standardmäßig werden Multicast-Pakete intern an den Knoten zurückgesendet, der sie gesendet hat. Dies geschieht sowohl für die IPv6- als auch für die IPv4-Adressierung.
Der Grund für dieses Standardverhalten liegt darin, dass beim Senden von Multicast-Paketen möglicherweise auch eine lokale Multicast-Anwendung auf dem sendenden Host selbst und irgendwo im Netzwerk ausgeführt wird. Diese lokale Anwendung muss auch Multicast-Pakete empfangen.
Wir können diesen lokalen Multicast-Loop in unserer Ping-Ausgabe sehen:
[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!)
...Die erste und schnellste Antwort (0,106 ms im Vergleich zu 0,453 ms) kommt von der Link-Local-Adresse, die auf der Schnittstelle selbst konfiguriert ist enp3s2.
[mark@opy ~]$ ip addr show dev enp3s2 | grep fe80
inet6 fe80::2392:6213:a15b:66ff/64 scope link noprefixroute
[mark@opy ~]$Dienstprogramm ping bietet eine Möglichkeit, lokales Multicast-Feedback mithilfe des Parameters zu unterdrücken -L. Wenn wir mit diesem Flag einen Multicast-Ping für alle Knoten senden, sind die Antworten auf entfernte Knoten beschränkt. Wir erhalten keine Antwort von der Link-Local-Adresse der sendenden Schnittstelle.
[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!)
...Ping-Link-Lokale Adressen
Wie Sie vielleicht erraten haben, liefern auch Unicast-Link-Local-Adressen allein nicht genügend Informationen, um anzugeben, über welche Schnittstelle sie erreicht werden sollen. Wie beim All-Node-Multicast-Ping müssen wir auch die Schnittstelle als Befehlszeilenparameter angeben ping oder Zonen-ID mit Adresse beim Pingen von Link-Local-Adressen.
Diese Zeit können wir nutzen -cum die Anzahl der gesendeten und empfangenen Pakete und Antworten zu begrenzen ping, da wir Unicast-Ping durchführen.
[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 ~]$(Alle) anderen IPv6-Adressen anpingen?
In diesem Artikel haben wir gesehen, wie man mithilfe einer All-Nodes-Multicast-IPv6-Adresse alle IPv6-Knoten auf einem Kanal anpingt ff02::1. Wir haben auch gesehen, wie man angibt, welche Schnittstelle mit einer Multicast-IPv6-Adresse für alle Knoten verwendet werden soll, da die Adresse selbst diese Informationen nicht bereitstellen kann. Wir haben entweder die Befehlszeilenoption verwendet ping, oder die Schnittstelle mit dem Suffix angegeben %<zone_id>.
Dann haben wir etwas über Unicast-Link-Local-Adressen gelernt, bei denen es sich um Adressen handelt, die zur Beantwortung aller Multicast-ICMPv6-Echoanfragen aller Knoten verwendet werden.
Wir haben auch gesehen, wie Multicast-Pakete standardmäßig an den sendenden Knoten zurückgesendet werden und wie man dies für das Dienstprogramm deaktiviert ping.
Schließlich haben wir eine einzelne Link-Local-Adresse mit dem Suffix gepingt %<zone_id>, da Link-Local-Adressen selbst auch keine Informationen über die ausgehende Schnittstelle liefern.
Wie wäre es also, alle anderen Knoten anzupingen und ihre globalen Unicast-Adressen (GUAs) (d. h. ihre öffentlichen Adressen im Internet) oder ihre eindeutigen lokalen Unicast-Adressen (ULAs) zu erhalten? Wir werden uns dies im nächsten Blogbeitrag ansehen.
Das ist alles.
Mehr zu unserem Kurs erfahren Sie unter.
Source: habr.com