Hallo Andreas,
Am 02.02.22 um 19:34 schrieb Andreas Fett:
Hallo Rico,
On Wed, Feb 02, 2022 at 02:12:17PM +0100, Rico Koerner wrote:
Aufgrund dieses Fehlerbildes vermute ich das Problem im NDP-Bereich, kenne mich aber damit zu wenig aus, um es weiter zu lokalisieren.
Hmm... ohne da jetzt konkret irgendwas erkennen zu können. Aber zum Eingrenzen wäre ein Blick in "bridge fdb" sowie den Neigbor Cache aka "ip -6 n" interessant (letzteres in den Gästen und auf dem Host) zu dem Zeitpunkt wo es ausfällt interessant.
Momantan funktionieren wieder mal alle, aber zumindest hab ich jetzt einen Ansatz, wo ich weitersuchen kann. Was erwartest du darin zu finden bzw. zu vermissen? Beide Ausgaben sehen im korrekten Zustand auf dem Host schon sehr umfangreich auch. Im Gast ist es noch übersichtlich. Ich hab mir die Ausgaben jetzt schon mal in Dateien gespeichert, vielleicht bringt ein diff im Fehlerfall schneller Erkenntnisse, als alles manuell zu kontrollieren. Zwischenzeitlich werd ich mal versuchen, die Einträge den zugehörigen NICs zuzuordnen.
Inzwischen hab ich eine VM erwischt, die kurz nachdem ich ip -6 n abgefragt hab, wieder online war:
~# diff ip6n-20220203-1427 ip6n-20220203-1429 3c3 < $Prefix:1003::1 dev ens9 lladdr 0c:c4:7a:45:38:1e router REACHABLE ---
$Prefix:1003::1 dev ens9 lladdr 0c:c4:7a:45:38:1e router STALE
9c9 < $Prefix::1 dev ens9 lladdr f2:0b:a4:d1:20:01 router REACHABLE ---
$Prefix::1 dev ens9 lladdr f2:0b:a4:d1:20:01 router DELAY
Für den Host blieb keine Zeit. Der Fehler ist hier bei einem Ping von einem externen System aufgefallen. Welche Verbindungen netzintern gestört waren, konnte ich so schnell auch noch nicht rausfinden, aber vielleicht hilft das schon mal weiter.
Und dann vll mal nen tcpdump um zu sehen ob da irgendwer zu diesem Zeitpunkt IPv6 Neighbor Solicitations schickt auf die keiner antwortet.
Wenn du mir dazu noch ein Beispiel schicken kannst, wie ich das am besten rausfiltere, spart mir das viel Zeit.
Da bei Dir alle Adressen statisch konfiguriert sind sollten die alle ne lifetime von "permanent" haben. Aber es würde sicherlich mal nicht schaden sich auf den Interfaces davon zu überzeugen, dass da wirklich nur die statisch konfigurierten + die fe80 Dinger drauf sind. Nicht das da RAs reinkommen und die Teile mit den Adressen arbeiten die sie sich per SLAAC aus nem RA konfigurieren... die sind ja raus gebridged "sehen" also die Aussenwelt.
Weitere IP-Adressen kann ich schon mal ausschließen: Host: 5: vswitch0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff inet6 $Prefix:1001::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever
Gast: 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UP group default qlen 1000 link/ether xx:xx:xx:xx:xx:xx brd ff:ff:ff:ff:ff:ff altname enp0s3 inet6 $Prefix:1101::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::xxxx:xxxx:xxxx:xxxx/64 scope link valid_lft forever preferred_lft forever
Prinzipiell ist für sonnen Betrieb kein zusätzlicher daemon oder sysctl erforderlich, die ganze Automagie is im Linux Kernel und per default an.
Die Erkenntnis ist auch schon was wert.
Grüsse Andreas
Gruß Rico