|
|
| (88 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) |
| Zeile 1: |
Zeile 1: |
| '''topic''' - Kurzbeschreibung | | '''IPv6 Neighbor Cache''' |
|
| |
|
| == Beschreibung == | | == Beschreibung == |
| == Neighbor Cache ==
| | [[File:ipv6Abbildung4.5.png|mini|Nodes am internen Link]] |
| ; Am internen Link sind nun drei Nodes vorhanden
| | * [[Router]] |
| * Der Router fuzzball sowie die Hosts lynx und felis
| | * [[Linux]] |
| * Sind alle Maschinen hochgefahren, sieht der interne Link wie in Abbildung 4.5 dargestellt aus.
| | * [[Windows]] |
|
| |
| ; [[Neighbor Discovery Protocol]]
| |
| Dank der Link-local Addresses waren die Nodes in der Lage miteinander auf dem internen Link zu kommunizieren.
| |
| * Wir haben dies mit diversen Echo Requests bereits ausprobiert.
| |
|
| |
|
| == Linux ==
| | ; Neighbor Discovery Protocol (NDP) |
| lynx internal eth1
| | * Über die Link-local Addresses können Nodes auf dem internen Link kommunizieren |
| | | * Dies kann mit [[Echo Requests]] getestet werden |
| eth0
| |
| | |
| Abbildung 4.5
| |
| Link internal mit fuzzball, lynx und felis
| |
| | |
| felis
| |
|
| |
|
| LAN1
| | ; Link-local Addresses zu Link-layer Addresses auflösen |
| | Nodes waren in der Lage die Link-local Addresses ihrer Nachbarn zu gültigen Link-layer Addresses aufzulösen |
| | * Unser Link internal ist ein virtuelles Ethernet, die Link-layer Addresses entsprechen in unserem Netz deshalb den bei Ethernet gebräuchlichen MAC-Adressen |
| | * Zuständig für die Auflösung von IPv6-Adressen zu Link-layer Addresses ist das Neighbor Discovery Protocol (NDP), spezifiziert in [[RFC/4861|RFC 4861]] |
|
| |
|
| Das heißt, die Nodes waren in der Lage die Link-local Addresses ihrer Nachbarn zu gültigen Link-layer Addresses aufzulösen.
| | ; [[NDP]] wird über [[ICMPv6]] transportiert |
| * Unser Link internal ist ein virtuelles Ethernet, die Link-layer Addresses entsprechen in unserem Netz deshalb den bei Ethernet gebräuchlichen MAC-Adressen.
| | * Damit ist es von IPv6 abhängig, wenn es IPv6-Adressen auflösen soll |
| * Zuständig für die Auflösung von IPv6-Adressen zu Link-layer Addresses ist das Neighbor Discovery Protocol (NDP), spezifiziert in RFC 4861 [NNSS07].
| | * Wie und warum das dennoch funktioniert, werden wir uns gleich anschauen |
| * NDP wird über ICMPv6 transportiert.
| | * Vorher machen wir uns aber noch mit den Neighbor Caches vertraut |
| * Damit ist es von IPv6 abhängig, wenn es IPv6-Adressen auflösen soll. | | * Jeder Node betreibt einen Neighbor Cache in dem er die Ergebnisse der Link-layerAdressauflösungen zwischenspeichert |
| * Wie und warum das dennoch funktioniert, werden wir uns gleich anschauen. | | Unter IPv4 haben wir für die Auflösung noch ARP benutzt, dessen Ergebnisse in der ARP-Tabelle zwischengespeichert wurden |
| * Vorher machen wir uns aber noch mit den Neighbor Caches vertraut. | |
| * Jeder Node betreibt einen Neighbor Cache in dem er die Ergebnisse der Link-layerAdressauflösungen zwischenspeichert. | |
| Übrigens: Unter IPv4 haben wir für die Auflösung noch ARP benutzt, dessen Ergebnisse in der ARP-Tabelle zwischengespeichert wurden.
| |
| Die Einträge in den Neighbor Caches sind je nach Betriebssystem und Zustand unterschiedlich lange gültig.
| |
| * Im Normalfall sind sie sehr kurzlebig.
| |
| * Wir brauchen für die folgenden Experimente deshalb mitunter mehrere Anläufe.
| |
| * Für das Einfangen eines ganz bestimmten Zustands müssen wir zum richtigen Zeitpunkt den Neighbor Cache auslesen.
| |
| * Manchmal ist es daher vorteilhaft, das nächste Kommando schon in der Zwischenablage bereit zu halten, um schneller reagieren zu können.
| |
|
| |
|
| Hinweis
| | ; Gültigkeit des Neighbor Caches |
| | Einträge im Neighbor Caches sind je nach Betriebssystem und Zustand unterschiedlich lange gültig |
| | * Im Normalfall sind sie recht kurzlebig |
| | * Daher sind für die folgenden Experimente mitunter mehrere Anläufe notwendig |
|
| |
|
| Wir wechseln zur Maschine felis und öffnen ein Terminal, zum Beispiel mit der bereits bekannten Methode Windows-Taste+R und cmd.
| | Für das Einfangen eines ganz bestimmten Zustands müssen wir zum richtigen Zeitpunkt den Neighbor Cache auslesen |
| * Um sicher zu gehen, dass sich Einträge im Neighbor | | * Manchmal ist es daher vorteilhaft, das nächste Kommando schon in der Zwischenablage bereitzuhalten, um schneller reagieren zu können |
|
| |
|
| == Windows == | | == Windows == |
| 4 Die Hosts Cache befinden werden, kommunizieren wir mit einem anderen Node auf dem Link.
| | [[IPv6/Host/Neighbor Cache/Windows]] |
| * Ein Echo Request an die Link-local Address von lynx bietet sich da an.
| |
|
| |
|
| Q
| | == Linux == |
| | [[IPv6/Host/Neighbor Cache/Linux]] |
|
| |
|
| C :\ Users \ user > ping -n 3 fe8 ::2 : ff : fe6 : d1e %12
| | == Zustände der Einträge == |
| Pinging fe8 ::2 : ff : fe6 : d1e %12 with 32 bytes of data :
| | {| class="wikitable big options" |
| Reply from fe8 ::2 : ff : fe6 : d1e %12: time <1 ms
| | |+ Bedeutungen der Zustände |
| Packets : Sent = 3 , Received = 3, Lost =
| | |- |
| ( % loss ) ,
| | ! Zustand !! Beschreibung |
| | | |- |
| Sobald eine Antwort eintrifft, können wir den Vorgang abbrechen und uns den Neighbor Cache ausgeben lassen.
| | | Incomplete || Es findet gerade eine Adressauflösung statt |
| * Das Kommando dazu geben wir unmittelbar nach dem letzten Echo Request ein:
| | * Diese konnte aber noch nicht erfolgreich beendet werden |
| Q
| | |- |
| | | | Reachable || Der zugehörige Nachbar gilt als erreichbar |
| Q
| | * Entweder findet gerade eine Kommunikation mit ihm statt oder eine solche ist erst wenige Sekunden her |
| | | |- |
| C :\ Users \ user > netsh interface
| | | Stale || Die Erreichbarkeit des zugehörigen Nachbarn ist unbekannt |
| Interface 12: LAN1
| | * Es fand kürzlich eine Kommunikation mit ihm statt |
| Internet Address
| | * Solange keine weitere Kommunikation beabsichtigt ist, sollte auf eine erneute Adressauflösung verzichtet werden |
| ---------------------------fe8 ::2 : ff : fe6 : d1e
| | |- |
| ff 2 ::1
| | | Delay || Der zugehörige Nachbar gilt nicht als erreichbar |
| ff 2 ::1: ff6 : d1e
| | * Es wurde aber wieder eine Kommunikation mit ihm gestartet |
|
| | * Bleibt eine Bestätigung der Erreichbarkeit durch die kommunizierende Schicht aus, wird auf IP-Schicht die Erreichbarkeit aktiv überprüft werden |
| ipv6 show neighbors
| | |- |
| Physical Address
| | | Probe || Der zugehörige Nachbar gilt nicht als erreichbar |
| ----------------- - -6 - d -1 e
| | * Seine Erreichbarkeit wird gerade aktiv geprüft |
| 33 -33 - - - - 1
| | * Sollte die Prüfung fehlschlagen, wird der Eintrag entfernt |
| 33 -33 - ff -6 - d -1 e
| | |} |
|
| |
| Type
| |
| --------Reachable
| |
| Permanent
| |
| Permanent
| |
|
| |
|
| Die IPv6-Adresse fe8 ::2 :ff:fe6 :d1e wurde korrekt zur Link-layer Address - - -6 - d-1e aufgelöst.
| | == Adressauflösung mitschneiden == |
| * Der Zustand des Eintrages ist Reachable, das heißt, der zugehörige Node gilt auf dem Link als erreichbar. | | ; Dass die Neighbor Caches funktionieren haben wir gerade gesehen |
| * Nach circa 20 Sekunden lassen wir uns den Neighbor Cache ein weiteres Mal ausgeben:
| | * Auch wissen wir dank der erfolgreichen Echo Requests, dass die Auflösung von IPv6-Adressen und Link-layer Addresses funktioniert |
| Q
| | * Es ist nun an der Zeit, die Frage nach dem Wie zu beantworten |
|
| |
|
| Q
| | ; Dazu suchen wir uns einen Node aus, der gerade einen leeren Neighbor Cache hat, zum Beispiel ''router'' |
| | * Das Kommando zum Anzeigen des Neighbor Caches ist uns aus den vorherigen Experimenten noch bekannt |
| | * Sollten sich noch gültige Einträge im Neighbor Cache befinden, warten wir noch etwas ab |
|
| |
|
| C :\ Users \ user > netsh interface
| | Wenn der Node seine IPv6-Nachbarn schließlich vergessen hat, starten wir Wireshark auf dem entsprechenden Interface, hier eth1 |
| Interface 12: LAN1
| |
| Internet Address
| |
| ---------------------------fe8 ::2 : ff : fe6 : d1e
| |
| ff 2 ::1
| |
| ff 2 ::1: ff6 : d1e
| |
|
| |
| ipv6 show neighbors
| |
| Physical Address
| |
| ----------------- - -6 - d -1 e
| |
| 33 -33 - - - - 1
| |
| 33 -33 - ff -6 - d -1 e
| |
|
| |
| Type
| |
| --------Stale
| |
| Permanent
| |
| Permanent
| |
|
| |
|
| Der Eintrag für die Adresse fe8 ::2 :ff:fe6 :d1e hat seinen Zustand zwischenzeitlich auf Stale gewechselt.
| | Um eine Adressauflösung zu erzwingen versenden wir wieder Echo Requests |
| * Die Nachbarn am Link können offensichtlich verschiedene Zustände haben.
| | user@router:~ '''ping6 -c3 fe80::200:ff:fe60:d1e%eth1''' |
| Neighbor Cache
| | PING fe80::200:ff:fe60:d1e%eth1 (fe80::200:ff:fe60:d1e) 56 data bytes |
| (Debian GNU/Linux 6)
| | 64 bytes from fe80::200:ff:fe60:d1e: icmp_seq=1 ttl=64 time=3.75 ms |
| | 3 packets transmitted, 3 received, 0% packet loss, time 2005 ms |
|
| |
|
| Die Zustände werden wir in einem weiteren Experiment, diesmal von lynx aus, untersuchen.
| | === Neighbor Solicitation === |
| * Wir verschicken Echo Requests an fuzzball, werden uns aber bei Eingabe der Adresse im letzten Zeichen vertippen.
| | [[Router Solicitation]] |
| * Die Echo Requests gehen an die
| |
|
| |
|
| 4.3 Neighbor Cache Adresse fe8 ::219:83ff:fe 9:17db.
| | === Solicited Node Multicast Address === |
| * Den Vorgang brechen wir vorerst nicht ab. | | [[File:ipv6SolicitedNodeMulticastAddress.png|mini|400px|Solicited Node Multicast Address]] |
| | Pakete an die Solicited Node Multicast Address eines Nodes können auch bei unbekannter Link-layer Address an diesen zugestellt werden |
| | * Wie genau das funktioniert werden wir in Abschnitt 4.5 Multicast lernen |
| | * Vorerst werden wir uns damit begnügen, dass es irgendwie funktioniert |
|
| |
|
| Q
| | ; Solicited Node Multicast Address |
| | | [[File:ipv6NeighborAdvertisement.png|mini|400px|Neighbor Advertisement]] |
| user@lynx :~ $ ping6 fe8 ::219:83 ff : fe 9 :17 db % eth
| |
| PING fe8 ::219:83 ff : fe 9 :17 db % eth '
| |
| ( fe8 ::219:83 ff : fe 9 :17 db ) 56 data bytes
| |
| From fe8 ::2 : ff : fe6 : d1e icmp_seq =1 Destination '
| |
| unreachable : Address unreachable
| |
| 48 packets transmitted ,
| |
| received , +42 errors , 1 % '
| |
| packet loss , time 47182 ms
| |
| | |
| Während lynx weiter fleißig Echo Requests versendet, öffnen wir ein zweites Terminal und schauen in diesem auf den Neighbor Cache.
| |
| * Unter Linux steht uns dafür das Kommando ip neighbor show zur Verfügung.
| |
| user@lynx :~ $ ip neighbor show
| |
| fe8 ::219:83 ff : fe 9 :17 db dev eth
| |
| | |
| INCOMPLETE
| |
| | |
| Wir lernen mit Incomplete einen weiteren Zustand kennen.
| |
| Nun brechen wir das Senden der Echo Requests im ersten Terminal ab, wechseln zügig in das zweite Terminal und lassen uns erneut den Neighbor Cache ausgeben.
| |
| user@lynx :~ $ ip neighbor show fe8 ::219:83 ff : fe 9 :17 db dev eth
| |
| | |
| FAILED
| |
| | |
| Sofern wir uns nicht zu viel Zeit gelassen haben, sehen wir noch den Zustand Failed bevor der Eintrag aus dem Neighbor Cache verschwindet.
| |
| * Failed ist allerdings kein Zustand den man in RFC 4861 [NNSS07] findet, sondern soll verdeutlichen, dass die Auflösung der Adresse nicht erfolgreich beendet werden konnte.
| |
| Den anderen Zuständen hingegen sind klare Bedeutungen zugeordnet:
| |
| | |
| ; Zustände der Einträge | |
| | |
| Incomplete Es findet gerade eine Adressauflösung statt.
| |
| * Diese konnte aber noch nicht erfolgreich beendet werden.
| |
| Reachable Der zugehörige Nachbar gilt als erreichbar.
| |
| * Entweder findet gerade eine Kommunikation mit ihm statt oder eine solche ist erst wenige Sekunden her.
| |
| | |
| 4 Die Hosts Stale Die Erreichbarkeit des zugehörigen Nachbarn ist unbekannt.
| |
| * Es fand kürzlich eine Kommunikation mit ihm statt.
| |
| * Solange keine weitere Kommunikation beabsichtigt ist, sollte auf eine erneute Adressauflösung verzichtet werden.
| |
| Delay Der zugehörige Nachbar gilt nicht als erreichbar.
| |
| * Es wurde aber wieder eine Kommunikation mit ihm gestartet.
| |
| * Bleibt eine Bestätigung der Erreichbarkeit durch die kommunizierende Schicht aus, wird auf IP-Schicht die Erreichbarkeit aktiv überprüft werden.
| |
| Probe Der zugehörige Nachbar gilt nicht als erreichbar.
| |
| * Seine Erreichbarkeit wird gerade aktiv geprüft.
| |
| * Sollte die Prüfung fehlschlagen, wird der Eintrag entfernt.
| |
| Adressauflösung mitschneiden
| |
| | |
| Dass die Neighbor Caches funktionieren haben wir gerade gesehen.
| |
| * Auch wissen wir dank der erfolgreichen Echo Requests, dass die Auflösung von IPv6-Adressen und Link-layer Addresses funktioniert.
| |
| * Es ist nun an der Zeit, die Frage nach dem Wie zu beantworten.
| |
| Dazu suchen wir uns einen Node aus, der gerade einen leeren Neighbor Cache hat, zum Beispiel fuzzball.
| |
| * Das Kommando zum Anzeigen des Neighbor Caches ist uns aus den vorherigen Experimenten noch bekannt.
| |
| * Sollten sich noch gültige Einträge im Neighbor Cache befinden, warten wir noch etwas ab.
| |
| Wenn der Node seine IPv6-Nachbarn schließlich vergessen hat, starten wir Wireshark auf dem entsprechenden Interface, hier eth1.
| |
| * Um eine Adressauflösung zu erzwingen versenden wir wieder Echo Requests:
| |
| | |
| Q
| |
| | |
| user@fuzzball :~ $ ping6 -c 3 fe8 ::2 : ff : fe6 : d1e % eth1
| |
| PING fe8 ::2 : ff : fe6 : d1e % eth1 ( fe8 ::2 : ff : fe6 : d1e ) '
| |
| 56 data bytes
| |
| 64 bytes from fe8 ::2 : ff : fe6 : d1e : icmp_seq =1 ttl =64 '
| |
| time =3.75 ms
| |
| 3 packets transmitted , 3 received , % packet loss , time '
| |
| 2 5 ms
| |
| | |
| 4.3 Neighbor Cache Abbildung 4.6
| |
| Neighbor Solicitation
| |
| | |
| Hat der betroffene Node wie gewünscht geantwortet stoppen wir die Aufzeichnung und schauen uns die Ergebnisse in Wireshark an.
| |
| Das erste Paket von Interesse ist eine Neighbor Solicitation genannte Nachricht (siehe Abbildung 4.6).
| |
| | |
| Neighbor Solicitation
| |
| | |
| Da das Neighbor Discovery Protocol ein in ICMPv6 eingebettetes Protokoll ist, fängt der spannende Teil mit einem ICMPv6-Header an.
| |
| * Der Nachrichtentyp hat die Nummer 135
| |
| und den Code 0.
| |
| * Neben der Checksum und reservierten Bytes existiert ein weiteres Feld, die Target Address.
| |
| * Sie enthält die aufzulösende IPv6-Adresse und gehört zum Ziel unseres Echo Requests.
| |
| * Danach folgt eine ICMPv6-Option namens Source Link-layer Address.
| |
| * Dabei handelt es sich um zusätzliche Informationen, die der Absender im Paket unterbringen kann.
| |
| * Hier hat fuzzball die Link-layer Address seines Interfaces freundlicherweise im Paket vermerkt.
| |
| * Der Gegenseite liefert er damit wertvolle Informationen für ihren eigenen Neighbor Cache.
| |
| * Ganz nebenbei ersparen solche Zusatzinformationen dem Link das ein oder andere Paket.
| |
| Aber wie konnte das Paket überhaupt beim richtigen Node am Link landen, wo wir doch seine Link-layer Address noch nicht kennen? Die Lösung ist im IPv6-Header des Paketes versteckt und lautet Solicited Node Multicast Address.
| |
| * Sie wird wie in Abbildung 4.7 dargestellt berechnet.
| |
| | |
| Solicited Node Multicast Address | |
| | |
| Pakete an die Solicited Node Multicast Address eines Nodes können auch bei unbekannter Link-layer Address an diesen
| |
| | |
| 4 Die Hosts Abbildung 4.7
| |
| Solicited Node Multicast Address
| |
| | |
| 00:00:00:60:0d:1e
| |
| | |
| Link-Layer Address (MAC)
| |
| | |
| ff02::1:ff60:0d1e
| |
| | |
| Solicited Node Multicast Address
| |
| | |
| Abbildung 4.8
| |
| Neighbor Advertisement | |
| | |
| zugestellt werden.
| |
| * Wie genau das funktioniert werden wir in Abschnitt 4.5 Multicast lernen.
| |
| * Vorerst werden wir uns damit begnügen, dass es irgendwie funktioniert.
| |
| Neighbor Advertisement
| |
| | |
| Natürlich antwortet der angesprochene Node kurz darauf.
| |
| Er tut dies mit einem sogenannten Neighbor Advertisement.
| |
| Wieder schauen wir in das Paket, ähnlich Abbildung 4.8, hinein.
| |
| Die Typnummer lautet nun 136, der Code bleibt unverändert und hat den Wert 0.
| |
| * Die Target Address gibt weiterhin an, für welche IPv6-Adresse eine Auflösung stattfindet.
| |
| * Neu ist das Feld Flags, das wir neugierig aufklappen.
| |
| * Wireshark erläutert die Flags eher sparsam, darum hier ihre Bedeutung:
| |
| Router Ein gesetztes Flag zeigt an, das es sich bei der Quelle um einen Router handelt.
| |
| * Das ist wichtig zu wissen, da ein Router an einem Link seine Rolle aufgeben kann.
| |
| Er wird dann zu einem normalen Host.
| |
| * Diese Änderung zeigt er durch das Nichtsetzen des Flags an.
| |
| Solicited Mit diesem Flag wird darauf hingewiesen, dass das Neighbor Advertisement die Folge einer vorhergehen Neighbor Solicitation ist.
| |
| * Der Empfänger bekommt damit die Erreichbarkeit eines Nodes bestätigt.
| |
| * Mit der
| |
| | |
| == 4.4 Interface Identifier ==
| |
| Information kann er seinen Neighbor Cache aktualisieren und Einträge im Zustand Stale oder Probe zurück auf Reachable setzen.
| |
| Override Mit dem Override-Flag kann die Quelle festlegen, was das Ziel des Neighbor Advertisements in den Neighbor Cache eintragen soll.
| |
| * Ist es gesetzt, werden existierende Einträge zu der angegeben Adresse überschrieben.
| |
| Ist es nicht gesetzt, darf es lediglich einen unvollständigen Eintrag ergänzen.
| |
| * Adressen, deren Einträge man nicht mit jedem Neighbor Advertisement überschreiben will, sind zum Beispiel Anycast Addresses.
| |
| * Wenn mehrere Anycast Hosts am Link vorhanden sind, laufen die anderen Hosts sonst Gefahr, ständig ihre Neighbor Caches zu überschreiben, ohne einen Nutzen daraus zu ziehen.
| |
| Die letzte Information im Paket ist die Source Link-layer Address, der eigentliche Grund der Anfrage.
| |
| Übrigens: An diesem Beispiel zeigt sich die Flexibilität von IPv6.
| |
| * Die ICMPv6-Optionen werden stets zusammen mit einer Längenangabe versendet.
| |
| * Sollte sich irgendwann eine LinkTechnologie durchsetzen die mehr als 6 Bytes für eine Linklayer Address benötigt, steht einer Vergrößerung der entsprechenden ICMPv6-Option nichts im Wege.
| |
| Der gesamte Prozess der Adressauflösung zwischen zwei Nodes auf dem Link besteht aus nur zwei Paketen.
| |
| * Von den Paketen musste keines an alle Nodes gesendet werden (siehe Abbildung 4.9).
| |
| * Gegenüber Broadcast stellt das eine deutliche Einsparung dar, gerade an Links mit vielen Nodes.
| |
| | |
| Ablauf einer typischen Adressauflösung
| |
|
| |
|
| | === Neighbor Advertisement === |
| | [[Neighbor Advertisement]] |
| <noinclude> | | <noinclude> |
|
| |
|
| Zeile 265: |
Zeile 101: |
| ===== Weblinks ===== | | ===== Weblinks ===== |
|
| |
|
| = TMP =
| |
|
| |
| == IPv6 - Neighbor Cache ==
| |
|
| |
| * Print Bei IPv6 wird die MAC-Adressenanfrage nicht wie bei IPv4 über das ARP-Protokoll realisiert, sondern über das Neighbor Discovery Protokoll (ein spezifisches ICMPv6-Protokoll). Dementsprechend werden die angefragten MAC-Adresse-IP-Adresse-Zuordnungen in den Neighbor-Cache abgelegt.
| |
|
| |
| Die Abfrage dieses Caches erfolgt über den Befehl: ip -6 neigh
| |
| Um eine MAC-Adressanfrage manuell zu initiieren kann das tool ndisc6 (neighbor discovery) verwendet werden.
| |
| Befehl: ndisc6 <IPv6-Zieladresse> <Quellinterface>
| |
| Beispiel: ndisc6 <2001:638:408:200::1> <eth1>
| |
|
| |
| == TMP ==
| |
|
| |
| = IPv6-Neighbour Cache =
| |
| Der Befehl <samp>show ipv6-neighbour-cache</samp> zeigt den aktuellen Neighbour Cache an.
| |
|
| |
| Die Ausgabe ist folgendermaßen formatiert:
| |
| <IPv6-Adresse> iface <Interface> lladdr <MAC-Adresse> (<Switchport>) <Gerätetyp> <Status> src <Quelle>
| |
| {| class="wikitable"
| |
| |+Tabelle 1. Bestandteile der Konsolenausgabe <samp>show ipv6-neighbour-cache</samp>
| |
| !Ausgabe
| |
| !Erläuterung
| |
| |-
| |
| |IPv6-Adresse
| |
| |Die IPv6-Adresse des benachbarten Gerätes.
| |
| |-
| |
| |Interface
| |
| |Das Interface, über das der Nachbar erreichbar ist.
| |
| |-
| |
| |MAC-Adresse
| |
| |Die MAC-Adresse des Nachbarn.
| |
| |-
| |
| |Switchport
| |
| |Der Switchport, auf dem der Nachbar festgestellt wurde.
| |
| |-
| |
| |Gerätetyp
| |
| |Gerätetyp des Nachbarn (Host oder Router).
| |
| |-
| |
| |Status
| |
| |Der Status der Verbindung zum benachbarten Gerät. Mögliche Einträge sind:
| |
|
| |
| * INCOMPLETE – Die Auflösung der Adresse ist noch im Gange und die Link Layer Adresse des Nachbarn wurde noch nicht bestimmt.
| |
| * REACHABLE – Der Nachbar ist in den letzten zehn Sekunden erreichbar gewesen.
| |
| * STALE – Der Nachbar ist nicht länger als REACHABLE qualifiziert, aber eine Aktualisierung wird erst durchgeführt, wenn versucht wird ihn zu erreichen.
| |
| * DELAY – Der Nachbar ist nicht länger als REACHABLE qualifiziert, aber es wurden vor kurzem Daten an ihn gesendet und auf Verifikation durch andere Protokolle gewartet.
| |
| * PROBE – Der Nachbar ist nicht länger als REACHABLE qualifiziert. Es werden Neighbour Solicitation Probes an ihn gesendet um die Erreichbarkeit zu bestätigen.
| |
| |-
| |
| |Quelle
| |
| |Die IPv6-Adresse, über die der Nachbar entdeckt wurde.
| |
| |}
| |
| Übergeordnetes Thema
| |
|
| |
| www.lancom-systems.de
| |
| {| class="wikitable"
| |
| |Befehle für die Konsole / Übersicht der IPv6-spezifischen show-Befehle
| |
| |With Frames
| |
| Übergeordnetes Thema
| |
| |}
| |
| [[Kategorie:IPv6/Host]] | | [[Kategorie:IPv6/Host]] |
|
| |
| </noinclude> | | </noinclude> |
