Re: IPv6 - NDP-Problem?

[Rico Koerner]

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.

~# 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

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: 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:

    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:

    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

5: vswitch0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc noqueue state UP group default qlen 1000 2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UP group default qlen 1000

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

OpenPGP_signature
Description: OpenPGP digital signature