☰

Die IPv6-Konnektivität geht plötzlich verloren und gleichzeitig wird der Status des IPv6-Nachbarrouters veraltet. Wie kann ich das vermeiden?

tag-icon • tag-icon ipv6 arp best-practices
Die IPv6-Konnektivität geht plötzlich verloren und gleichzeitig wird der Status des IPv6-Nachbarrouters veraltet. Wie kann ich das vermeiden?

Ich habe eine VM auf einem Host mit Bridged Networking (also mit eigener MAC-Adresse). Sowohl Host als auch VM laufen unter CentOS. Ihr Netzwerk wird durch einfache /etc/sysconfig/network-scripts/ifcfg-enpXsYDateien verwaltet, die die statischen IP-Adressen enthalten. IPv4 funktioniert einwandfrei.

Ich habe der VM eine IPv6-Adresse zugewiesen (der Host hat auch eine), die im Rechenzentrum korrekt geroutet wird. Die meisten Verbindungen verwenden jedoch IPv4 (noch kein DNS AAAA-Eintrag für die Maschine, IPv6 wird noch getestet).

Wenn ich die VM hochfahre, verfügt sie über volle IPv6-Konnektivität.nach einer Weile funktioniert die IPv6-Konnektivität nicht mehr(IPv6-Magie?). Ich habe das Problem auf Nachbardaten (ARP/NDISC-Cache) eingegrenzt:

IPv6 funktioniert nicht, kann nicht per IPv6 ein- oder ausgehend pingen oder eine Verbindung herstellen, dann sehe ich:

# ip -6 neighbour 
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router STALE

Fix/Workaround zum Aktualisieren des Cache:

# ip -6 neighbour flush dev enp1s2
# ip -6 neighbour
(empty, as expected)

Anschließend ping6füllt der Host innerhalb der VM den Cache:

# ping6 2912:1375:23:9a6c::2
PING 2912:1375:23:9a6c::2(2912:1375:23:9a6c::2) 56 data bytes
64 bytes from 2912:1375:23:9a6c::2: icmp_seq=1 ttl=64 time=2.35 ms
64 bytes from 2912:1375:23:9a6c::2: icmp_seq=2 ttl=64 time=0.468 ms
^C
# ip -6 neighbour
fe80::1 dev enp1s2 lladdr 0c:86:72:2e:04:28 router REACHABLE
2912:1375:23:9a6c::2 dev enp1s2 lladdr 08:21:4b:b7:f8:31 DELAY

Gültigkeit der IPv6-Nachbar-/ARP-Tabelle wiederhergestellt und Konnektivität funktioniert ein- und ausgehend!

Meine Fragen sind also:

  1. Warum wird der Cache veraltet?
  2. Was kann ich tun, um dies zu vermeiden?
  3. Warum/wie behebt der obige Befehl das Problem?

Natürlich könnte ich diese Befehle in einem cronJob ausführen (wie oft?), aber ich nehme an, dass das nicht wirklich notwendig sein kann, damit IPv6 generell funktioniert?

PS: Ich habe für Tests ein Skript verwendet:Der IPv6-Stack bricht etwa alle 20 Minuten zusammen. Kann das durch RFCs erklärt werden?

PPS: Firewall-Konfiguration (gekürzte Ausgabe, hoffentlich alle relevanten Teile):

# ip6tables -nvL
Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 9023  709K ACCEPT     icmpv6    !lo    *       ::/0                 ::/0                
Chain OUTPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 9360  785K ACCEPT     icmpv6    *      !lo     ::/0                 ::/0

ICMPv6 wird also auf der VM akzeptiert. Muss ich die Filterung auf dem Host überprüfen?

Antwort1

Im Allgemeinen ist ein Stale State eine gute Sache, eigentlich ist es akzeptabel, dass wir einen Stale State haben.

Schauen wir uns RFC 4861, Abschnitt 5.1 an:

  STALE       The neighbor is no longer known to be reachable but until traffic is sent to the neighbor, no attempt should be made to verify its reachability.

Es ist nicht bekannt, dass der Nachbar länger erreichbar ist (Timer abgelaufen, in letzter Zeit kein Verkehr, was auch immer) und die Erreichbarkeit wird „bestätigt“, sobald wieder Verkehr an den Nachbarn gesendet wird.

Es besteht also kein Problem, wenn Sie erneut Datenverkehr an den Nachbarn senden können.

verwandte Informationen