Nur noch wenige Tage bis zum Start des neuen Kurses "Netzwerktechniker" Eine Reihe von Blog-Artikeln, die sich mit Tipps und Empfehlungen zur Fehlerbehebung bei IPv6-Ping-Problemen (ICMPv6 Echo Request/Echo Reply) beschäftigen.
Bitte beachten Sie, dass ich Linux (insbesondere Fedora 31) verwende, aber die Syntax des Befehls ping sollte auf anderen Betriebssystemen sehr ähnlich sein.
Der erste und einfachste Rat ist, alle IPv6-Knoten im Netzwerk anzupingen.
Ping aller IPv6-Knoten im Netzwerk
IPv6 verwendet Multicast-Adressen für alle Arten von „ein zu vielen“-Kommunikation. Es gibt keine Broadcast- oder weitverbreiteten IPv6-Adressen. Das unterscheidet IPv6 von IPv4, wo es mehrere Arten von Broadcast-Adressen gibt, wie zum Beispiel die "limited broadcast" Adresse 255.255.255.255 [RFC1122].
IPv6 verwendet Multicast-Adressen für alle Arten von "Eins-zu-vielen"-Kommunikation. Es gibt keine Broadcast- (oder breit gestreuten) IPv6-Adressen. Dies unterscheidet IPv6 von IPv4, wo es mehrere Arten von Broadcast-Adressen gibt, wie beispielsweise die "limited broadcast"-Adresse 255.255.255.255 [RFC1122].
Es gibt jedoch eine „All-Nodes-Multicast“ (gemeinsame Multicast) IPv6-Adresse, die wir zum Pingen aller IPv6-Knoten im Netzwerk verwenden werden. Die „Broadcast“-Adresse ist tatsächlich einfach eine speziell benannte Multicast-Adresse, die eine Gruppe von Multicast-Adressen umfasst, die alle Knoten beinhaltet. Beachten Sie, dass beispielsweise das „Gruppen“-Bit oder das Bit der Multicast-Adresse in den Broadcast-Adressen von Ethernet auf der Datenebene enthalten ist.
All-Nodes-Multicast IPv6-Adresse für den Kanal: ff02::1. ff bezeichnet die Multicast IPv6-Adresse. Die folgende 0 ist der Teil des Flags mit nicht gesetzten Bits.
Weiter 2 definiert den Bereich der Multicast-Gruppe. Im Gegensatz zu Multicast IPv4-Adressen haben Multicast IPv6-Adressen einen Scope (Sichtbereich). Der Scope-Wert gibt den Teil des Netzwerks an, über den das Multicast-Paket weitergeleitet werden darf. Sobald das Paket die Grenze des angegebenen Scopes erreicht, muss es verworfen werden, unabhängig davon, ob der Hop Count ungleich null ist. Natürlich wird der Hop Count ebenfalls sofort zurückgesetzt, wenn er vor dem Erreichen der angegebenen Multicast-Gruppen-Grenze null erreicht. Hier ist die vollständige Liste der Multicast-Scope für IPv6.
Letztendlich ::1 weist die all-nodes Multicast-Gruppe zu.
Über die Adresse ff02::1 ist zu beachten, dass sie mehrdeutig ist. An einem IPv6-Knoten mit mehreren Schnittstellen, wie einem Router oder einem Multi-Netzwerk-Host, gibt es in der Adresse ff02::1 nichts, was angeben könnte, an welche Schnittstelle ICMPv6-Echo-Anfragen gesendet oder von welchen Schnittstellen ICMPv6-Echo-Antworten erwartet werden, wenn sie eintreffen. ff02::1 gültig ist und auf jeder der Schnittstellen und Kanäle, die an einem Multi-Schnittstellen-Knoten angeschlossen sind, verwendet werden kann.
Daher müssen wir beim Pingen aller IPv6-Knoten auf dem Kanal auch irgendwie der Utility mitteilen. ping Für IPv6, welches Interface soll verwendet werden?
Definitionsschnittstellen - Befehlszeilenparameter
Wie wir bereits gesehen haben, ist die Multicast-Adresse all-nodes, die wir verwenden möchten - ff02::1 – gibt keine Informationen darüber, über welches Interface die Echo-Anfragen und Echo-Antworten von ICMPv6 gesendet und empfangen werden sollen.
Wie können wir also das Interface angeben, das für den Adressbereich der Multicast-Adressen oder der Unicast-Link-Local-Adressen verwendet werden soll?
Die erste und offensichtlichste Möglichkeit besteht darin, es als Parameter für die Anwendung bereitzustellen, die wir verwenden.
Für das Tool ping geben wir es über die Option -I.
[mark@opy ~]$ ping -w 1 -I enp3s2 ff02::1
ping: Warnung: Die Quelladresse könnte auf einem anderen Gerät als: enp3s2 ausgewählt werden
PING ff02::1(ff02::1) von :: enp3s2: 56 Datenbytes
64 Bytes von fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 Zeit=0.438 ms
64 Bytes von fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 Zeit=0.589 ms (DUP!)
64 Bytes von fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 Zeit=5.15 ms (DUP!)
64 Bytes von fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 Zeit=58.0 ms (DUP!)
64 Bytes von fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 Zeit=62.3 ms (DUP!)
64 Bytes von fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 Zeit=62.8 ms (DUP!)
--- ff02::1 Ping-Statistik ---
1 Paket übertragen, 1 empfangen, +5 Duplikate, 0% Paketverlust, Zeit 0ms
RTT min/avg/max/mdev = 0.438/31.544/62.786/29.566 ms
[mark@opy ~]$Mit diesem All-Nodes Multicast Ping haben wir Antworten von 6 IPv6-Knoten erhalten. Die Antworten kamen von den Link-Local IPv6-Adressen, beginnend mit dem Präfix fe80::/10.
Um ping haben wir nicht ununterbrochen ICMPv6 Echo-Anfragen gesendet, bis wir den Vorgang abgebrochen haben. Üblicherweise geben wir die Anzahl der zu sendenden Pakete über die Option -c an. Allerdings erlaubt dies auch nicht, dass ping mehr als eine ICMPv6 Echo-Antwort beim Senden eines Multicast ICMPv6 Echo-Requests annimmt und anzeigt. Stattdessen haben wir den Parameter -w verwendet, um anzugeben, dass ping nach 1 Sekunde enden soll, unabhängig von der Anzahl der gesendeten oder empfangenen ICMPv6 Echo-Anfragen oder -Antworten.
Ein weiterer Punkt, der beachtet werden sollte, ist (DUP!) die Ausgabe bei der zweiten und den nachfolgenden Antworten. Diese Pakete werden als Duplikate der Antwort identifiziert, da sie denselben ICMP Sequenzwert haben wie die einzelnen ICMPv6 Echo-Anfragen, die ursprünglich gesendet wurden. Sie erscheinen, weil der Multicast ICMPv6 Echo-Request zu mehreren individuellen Unicast-Antworten führt. Die Anzahl der Duplikate wird ebenfalls in der Zusammenfassung der Statistik angegeben.
Schnittstellendefinitionen — Zone ID
Eine weitere Möglichkeit, eine Schnittstelle bereitzustellen, ist ein Teil des IPv6-Adresseparameters.
Ein Beispiel dafür können wir in der Ausgabe des Ping-Befehls sehen, wo die Adressen der antwortenden IPv6-Knoten ebenfalls einen Suffix haben. %enp3s2, zum Beispiel:
64 Bytes von fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 Zeit=0,438 msDiese Art der Schnittstellendefinition ist in [RFC4007] "Architektur mit festgelegten IPv6-Adressen" formal beschrieben. Obwohl sie üblicherweise als Betriebssystemschnittstelle bezeichnet werden, definieren sie tatsächlich etwas Allgemeineres – eine "Zone" oder "Geltungsbereich".
Der Grund für das Vorhandensein allgemeinerer Zonen oder Geltungsbereiche liegt darin, dass, wie in [RFC4007] erwähnt, ein IPv6-Knoten mehrere verschiedene IPv6-Schnittstellen haben kann, die an dasselbe Netzwerk angeschlossen sind. Diese Schnittstellen sind Mitglieder einer Zone.
Es sollte möglich sein, mehrere Schnittstellen innerhalb einer Zone unter dem Betriebssystem zu gruppieren; Momentan weiß ich nicht, ob dies unter Linux möglich ist und wie es durchgeführt werden kann.
Mit dem Suffix %, können wir das Kommandozeilenargument -I ping.
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 Datenbytes
64 Bytes von fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 Zeit=0,106 ms
64 Bytes von fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 Zeit=0,453 ms (DUP!)
64 Bytes von fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 Zeit=0,606 ms (DUP!)
64 Bytes von fe80::7e31:f5ff:fe1b:9fdb%enp3s2: icmp_seq=1 ttl=64 Zeit=6,23 ms (DUP!)
64 Bytes von fe80::f7f8:15ff:fe6f:be6e%enp3s2: icmp_seq=1 ttl=64 Zeit=157 ms (DUP!)
64 Bytes von fe80::877d:4ff:fe1a:ad79%enp3s2: icmp_seq=1 ttl=64 Zeit=159 ms (DUP!)
64 Bytes von fe80::877d:4ff:fe1a:b881%enp3s2: icmp_seq=1 ttl=64 Zeit=161 ms (DUP!)
64 Bytes von fe80::23d:e8ff:feec:958c%enp3s2: icmp_seq=1 ttl=64 Zeit=179 ms (DUP!)
--- ff02::1%enp3s2 Pingstatistiken ---
1 Paket gesendet, 1 empfangen, +7 Duplikate, 0% Paketverlust, Zeit 0ms
rtt min/avg/max/mdev = 0,106/82,858/179,216/81,281 ms
[mark@opy ~]$Antworten von Link-Local-Adressen
Von diesem All-Nodes-Multicast-Ping haben wir insgesamt 6 einzigartige Antworten erhalten.
Diese Antworten stammen von Unicast-Link-Local-Adressen der IPv6-Knoten. Zum Beispiel, hier ist die erste Antwort:
64 Bytes von fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 Zeit=0,106 msLink-Local IPv6-Adressen sind auf allen Schnittstellen erforderlich, die IPv6 unterstützen [RFC4291], "Architektur der IP-Version-6-Adressierung". Der Grund dafür ist, dass ein IPv6-Knoten immer automatisch über eine Unicast IPv6-Adresse verfügt, die er nutzen kann, um zumindest mit anderen Knoten über direkt angeschlossene Verbindungen zu kommunizieren. Dies umfasst die Kommunikation mit Anwendungen anderer Hosts über die Link-Local-Adressen der Hosts.
Dies vereinfacht die Entwicklung und Implementierung von Protokollen wie IPv6 Neighbor Discovery und OSPFv3. Es ermöglicht auch Endanwenderanwendungen auf Hosts, Daten über die Verbindung auszutauschen, ohne dass eine andere unterstützende IPv6-Infrastruktur nötig ist. Für die direkte Verbindung von angeschlossenen IPv6-Hosts ist kein IPv6-Router oder DHCPv6-Server erforderlich.
Link-Local-Adressen beginnen mit einem 10-Bit-Präfix fe80, gefolgt von 54 Null-Bits und dann einem 64-Bit-Schnittstellenidentifikator (IID). In der obigen ersten Antwort 2392:6213:a15b:66ff — ist dies der 64-Bit IID.
Schleifen-Multicast
Standardmäßig werden Multicast-Pakete intern an den Knoten zurückgesendet, der sie gesendet hat. 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 lokal lauschende Multicast-Anwendung, die auf dem sendenden Host läuft, sowie irgendwo im Netzwerk vorhanden sein kann. Diese lokale Anwendung sollte ebenfalls die Multicast-Pakete empfangen.
Wir können diesen lokalen Multicast-Zyklus in unserem Ping-Ausgang sehen:
[mark@opy ~]$ ping -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 Datenbytes
64 Bytes von fe80::2392:6213:a15b:66ff%enp3s2: icmp_seq=1 ttl=64 Zeit=0.106 ms
64 Bytes von fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 Zeit=0.453 ms (DUP!)
...Die erste und schnellste Antwort (0,106 ms im Vergleich zu 0,453 ms) stammt von der Link-Local-Adresse, die auf dem Interface 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 stellt eine Möglichkeit zur Verfügung, lokale Echo-Rückmeldungen von Multicast-Übertragungen mit dem Parameter zu unterdrücken -L. Wenn wir ein Ping an alle Knoten mit diesem Flag senden, werden die Antworten auf entfernte Knoten beschränkt. Wir erhalten keine Antwort von der Link-Local-Adresse des sendenden Interfaces.
[mark@opy ~]$ ping -L -w 1 ff02::1%enp3s2
PING ff02::1%enp3s2(ff02::1%enp3s2) 56 Datenbytes
64 Bytes von fe80::1d36:1fff:fefd:82be%enp3s2: icmp_seq=1 ttl=64 Zeit=0,383 ms
64 Bytes von fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 Zeit=0,467 ms (DUP!)
...Ping-Link-Local-Adresse
Wie Sie sich vorstellen können, bieten Unicast-Link-Local-Adressen allein nicht genügend Informationen, um anzugeben, welches Interface für den Zugriff verwendet werden soll. Ähnlich wie beim All-Nodes-Multicast-Ping müssen wir auch hier das Interface als Befehlszeilenparameter angeben. ping oder die Zone-ID mit der Adresse beim Pingen von Link-Local-Adressen.
Diesmal können wir -c, um die Anzahl der gesendeten und empfangenen Pakete zu begrenzen ping, da wir einen Unicast-Ping ausfü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 Datenbytes
64 Bytes von fe80::f31c:ccff:fe26:a6d9%enp3s2: icmp_seq=1 ttl=64 Zeit=0,395 ms
--- fe80::f31c:ccff:fe26:a6d9%enp3s2 Ping-Statistik ---
1 gesendetes Paket, 1 empfangen, 0% Paketverlust, Zeit 0ms
RTT min/avg/max/mdev = 0,395/0,395/0,395/0,000 ms
[mark@opy ~]$Pingen (alle) anderen IPv6-Adressen?
In diesem Artikel haben wir gesehen, wie man alle IPv6-Knoten im Kanal anpingt, indem man die All-Nodes-Multicast-IPv6-Adresse verwendet. ff02::1. Wir haben auch gesehen, wie man angibt, welches Interface mit einer all-nodes Multicast IPv6-Adresse verwendet werden soll, da die Adresse allein nicht genügend Informationen bietet. Wir haben entweder den Befehlszeilenparameter verwendet ping, oder das Interface über den Suffix angegeben. %.
Dann haben wir etwas über Unicast Link-Local-Adressen gelernt, die Adressen sind, die für Antworten auf all-nodes Multicast Echo-ICMPv6-Anfragen 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 Einzel-Link-Local-Adresse gepingt, indem wir den Suffix verwendet haben %, da Link-Local-Adressen allein ebenfalls keine Informationen über das ausgehende Interface bereitstellen.
Was ist mit dem Pingen aller anderen Knoten und dem Erhalten ihrer globalen Unicast-Adressen (GUA) (d.h. ihrer öffentlichen Adressen im Internet) oder ihrer einzigartigen lokalen Unicast-Adressen (ULA)? Dies werden wir im nächsten Blogartikel betrachten.
Das ist alles.
Mehr Informationen zu unserem Kurs finden Sie in der.
Quelle: habr.com
