Pingen Sie alle IPv6-Hosts auf dem Kanal an

Es verbleiben noch einige Tage bis zum Start eines neuen Streams im Kurs "Network Engineer" von OTUS. In diesem Zusammenhang möchten wir Ihnen die Übersetzung von nützlichem Material zum Thema mitteilen.




Eine Reihe von Blog-Artikeln über Tipps und Tricks zur IPv6-Ping-Fehlerbehebung (ICMPv6-Echoanforderung / Echoantwort)

Bitte beachten Sie, dass ich Linux (speziell Fedora 31) verwende, jedoch hoffentlich die Ping-Befehlssyntax für andere Betriebssysteme sollte sehr ähnlich sein.

Pingen Sie alle IPv6-Hosts auf dem Kanal an


Der erste und einfachste Tipp ist, alle IPv6-Hosts auf dem Kanal zu pingen.

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 verschiedene Arten von Broadcast-Adressen gibt, z. B. "Limited Broadcast" -Adresse 255.255.255.255 [RFC1122].

Es gibt jedoch eine IPv6-Adresse für alle Knoten, sodass wir alle IPv6-Knoten im Kanal anpingen können. (Eine "Broadcast" -Adresse ist eigentlich nur eine speziell benannte Multicast-Adresse, eine Multicast-Gruppe, die alle Knoten enthält. Beachten Sie, dass beispielsweise das "Gruppen" - oder Multicast-Adressbit in Ethernet-Broadcast-Adressen auf Verbindungsebene enthalten ist.)

Multicast-IPv6-Adresse für alle Knoten für den Kanal: ff02::1. ffBezeichnet eine Multicast-IPv6-Adresse. Die nächste 0 ist Teil des Flags mit nicht gesetzten Bits.

Ferner 2definiert der Bereich der Multicast - Gruppe. Im Gegensatz zu IPv4-Multicast-Adressen haben IPv6-Multicast-Adressen einen Gültigkeitsbereich. Der Gültigkeitsbereich gibt den Teil des Netzwerks an, über den Multicast-Pakete zulässig sind. Sobald das Paket die Grenze des angegebenen Bereichs erreicht, sollte das Paket verworfen werden, unabhängig davon, ob sein Hop Count-Feld ungleich Null ist. Wenn der Konvertierungszähler vor Erreichen des angegebenen Randes der Multicast-Gruppe Null erreicht, wird er natürlich auch sofort zurückgesetzt. Hier ist eine vollständige Liste der IPv6-Multicast-Bereiche.

Gibt schließlich ::1die Multicast-Gruppe für alle Knoten an.

Über die Adresse ff02::1ist zu beachten, dass sie nicht eindeutig ist. Auf einem IPv6-Host mit mehreren Schnittstellen, z. B. einem Router oder einem Multihomed-Host, ff02::1gibt es in der Adresse nichts, an dem Sie angeben können, an welche Schnittstelle ICMPv6-Pings gesendet werden sollen, oder auf ICMPv6-Pings warten sollen, wenn diese eintreffen. ff02::1gü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 dem Kanal anpingen, müssen wir dem Dienstprogramm pingfür IPv6 auch irgendwie mitteilen, welche Schnittstelle verwendet werden soll.

Schnittstellendefinition - Befehlszeilenoption


Wie wir bereits gesehen haben, ff02::1liefert die Multicast-Adresse für alle Knoten, die wir verwenden möchten , keine Informationen darüber, an welche Schnittstelle ICMPv6-Echoanforderungs- und Echoantwortpakete gesendet und empfangen werden sollen.

Wie geben wir die Schnittstelle an, die für den Multicast-Adressraum oder die Unicast-Link-Local-Adressen verwendet wird?

Der erste und naheliegendste Weg besteht darin, ihn als Parameter für die von uns verwendete Anwendung bereitzustellen.

Für das Dienstprogramm pingstellen wir es über die Option zur Verfügung -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 ~]$


Mit diesem Multicast-Ping für alle Knoten haben wir Antworten von 6 IPv6-Knoten erhalten. Die Antworten kamen von den Link-Local-IPv6-Adressen des Hosts, beginnend mit dem Präfix fe80::/10.

Um zu pingverhindern, dass ICMPv6-Echoanforderungen endlos fortgesetzt werden, bis wir sie abbrechen, geben wir normalerweise die Anzahl der Pakete an, die über die Option -c gesendet werden sollen. Dies verhindert jedoch auch, dass Ping mehr als eine ICMPv6-Echoantwort empfängt und anzeigt, wenn eine Multicast-ICMPv6-Echoanforderung gesendet wird. Stattdessen haben wir die Option -w verwendet, um anzugeben, dass der Ping nach 1 Sekunde abgeschlossen sein soll, unabhängig davon, wie viele ICMPv6-Pings oder Pings gesendet oder empfangen wurden.

Eine andere Sache, auf die Sie achten sollten, ist (DUP!) Schlussfolgerung zur zweiten und nachfolgenden Antwort. Diese Pakete werden als Duplikate der Antwort identifiziert, da sie denselben ICMP-Sequenzwert haben wie die einzelnen ICMPv6-Pings, die zuerst gesendet wurden. Sie werden angezeigt, weil die ICMPv6-Multicast-Echoanforderung zu mehreren einzelnen Unicast-Antworten führt. Die Anzahl der Duplikate ist auch in der Statistikübersicht angegeben.

Schnittstellendefinition - Zonen-ID


Eine andere Möglichkeit, eine zu verwendende Schnittstelle bereitzustellen, ist Teil des IPv6-Adressparameters.

Ein Beispiel hierfür können wir in der Ping-Ausgabe beobachten, wo die Adressen der antwortenden IPv6-Knoten ebenfalls ein Suffix haben %enp3s2, zum Beispiel:

64 bytes from fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 time=0.438 ms


Diese Methode zum Definieren von Schnittstellen wird in [RFC4007], „Architektur mit angegebenen IPv6-Adressen“, offiziell 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 IPv6-Host, wie in [RFC4007] erwähnt, mehrere verschiedene IPv6-Schnittstellen haben kann, die mit demselben Kanal verbunden sind. Diese Schnittstellen sind Mitglieder derselben Zone.

Es sollte möglich sein, mehrere Schnittstellen innerhalb der Zone unter dem Betriebssystem zu gruppieren. Derzeit weiß ich nicht, ob dies unter Linux möglich ist und wie es geht.

Mit dem Suffix %<zone_id>können wir den Befehlszeilenparameter 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-lokale Adressantworten


Von diesem Multicast-Ping für alle Knoten haben wir insgesamt 6 eindeutige Antworten erhalten.

Diese Antworten stammten 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 ms


Unicast Link-Local IPv6-Adressen erforderlich für alle IPv6-fähigen Schnittstellen [RFC4291], IP-Adressierungsarchitektur Version 6. Der Grund dafür ist, dass der IPv6-Host immer automatisch eine Unicast-IPv6-Adresse hat, die er verwenden kann, um zumindest über seine direkt verbundenen Kanäle mit anderen Hosts zu kommunizieren. Dies umfasst die Kommunikation mit Anwendungen anderer Hosts über Link-Local-Hostadressen.

Dies vereinfacht die Entwicklung und Implementierung von Protokollen wie IPv6 Neighbor Discovery und OSPFv3. Außerdem können Endbenutzeranwendungen auf den 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 ein DHCPv6-Server in Verbindung erforderlich.

Link-Local-Adressen beginnen mit einem 10-Bit-Präfix fe80, gefolgt von 54 Null-Bits, gefolgt von einer 64-Bit-Schnittstellenkennung (IID). In der ersten Antwort oben 2392:6213:a15b:66ffist dies eine 64-Bit-IID.

Looped Multicast


Standardmäßig werden Multicast-Pakete intern an den Knoten zurückgegeben, der sie sendet. Dies geschieht sowohl für IPv6- als auch für IPv4-Adressen.

Der Grund für dieses Standardverhalten liegt darin, dass beim Senden von Multicast-Paketen möglicherweise auch eine abhörende lokale Multicast-Anwendung auf dem sendenden Host selbst sowie irgendwo im Netzwerk ausgeführt wird. Diese lokale Anwendung sollte auch Multicast-Pakete empfangen.

Wir können diese Multicast-Lokalschleife 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 ~]$


Das Dienstprogramm pingbietet eine Möglichkeit, das lokale Feedback von Multicast-Mailing mithilfe eines Parameters zu unterdrücken -L. Wenn wir einen Multicast-Ping für alle Knoten mit diesem Flag senden, sind die Antworten auf die Remote-Knoten beschränkt. Wir erhalten keine Antwort von der Link-Local-Adresse der Absenderschnittstelle.

[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-Local-Adressen


Wie Sie sich vorstellen können, bieten Unicast-Link-Local-Adressen selbst auch nicht genügend Informationen, um anzugeben, über welche Schnittstelle sie erreicht werden sollen. Wie im Fall von Multicast-Ping für alle Knoten müssen wir auch die Schnittstelle als Befehlszeilenparameter pingoder Zonen-ID mit der Adresse angeben, wenn Link-Local-Adressen gepingt werden.

Dieses Mal können wir -cdie Anzahl der gesendeten und empfangenen Pakete und Antworten 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 ~]$


Ping (alle) anderen IPv6-Adressen?


In diesem Artikel haben wir gesehen, wie alle IPv6-Knoten auf einem Kanal mit einer Multicast-IPv6-Adresse für alle Knoten gepingt werden ff02::1. Wir haben auch gesehen, wie angegeben werden kann, welche Schnittstelle mit der Multicast-IPv6-Adresse aller Knoten verwendet werden soll, da die Adresse allein diese Informationen nicht bereitstellen kann. Wir haben entweder einen Befehlszeilenparameter verwendet pingoder eine Schnittstelle durch ein Suffix angegeben %<zone_id>.

Dann lernten wir Unicast Link-Local-Adressen kennen, die verwendet werden, um auf Multicast-ICMPv6-Echoanforderungen für alle Knoten zu antworten.

Wir haben auch gesehen, wie Multicast-Pakete standardmäßig zum sendenden Host zurückkehren und wie dies für das Dienstprogramm deaktiviert wird ping.

Schließlich haben wir eine einzelne Link-Local-Adresse mit dem Suffix gepingt%<zone_id>da Link-Local-Adressen allein keine Informationen über die ausgehende Schnittstelle liefern.

Wie wäre es also mit einem Ping aller anderen Knoten und dem Abrufen ihrer globalen Unicast-Adressen (GUAs) (dh ihrer öffentlichen Internetadressen) oder ihrer eindeutigen lokalen Unicast-Adressen (ULAs)? Wir werden dies im nächsten Blog-Beitrag behandeln.

Das ist alles.

Mehr über unseren Kurs erfahren Sie im Tag der offenen Tür .

All Articles