Re: IPv6 - NDP-Problem?

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