Hallo Liste,

ich habe bei Hetzner mehrere Server mit einem vSwitch verbunden und dort ein öffentliches /64-Netz angebunden. Das Gateway ist dabei ein Juniper-Router bei Hetzner innerhalb des /64-Netzes ($Prefix::1). vSwitch bedeutet in dem Falle, daß auf der vorhandenen NIC ein zusätzliches VLAN konfiguriert wird, welches mit dem vSwitch verbunden ist.

Das sieht auf dem Server etwa so aus: auto vlan4000 iface vlan4000 inet manual vlan-raw-device enp195s0

auto vswitch0 iface vswitch0 inet6 static address $Prefix:1001::1/64 bridge_ports vlan4000 bridge_stp on bridge_maxwait 10 up ip link set $IFACE mtu 1400 up ip -6 rule add from $Prefix:1001::1/64 lookup vswitch0 up ip -6 rule add to $Prefix:1001::1/64 lookup vswitch0 up ip -6 route add default via $Prefix::1 dev $IFACE table vswitch0 down ip -6 route del default via $Prefix::1 dev $IFACE table vswitch0 down ip -6 rule del from $Prefix:1001::1/64 lookup vswitch0 down ip -6 rule del to $Prefix:1001::1/64 lookup vswitch0

Damit VMs darüber angebunden werden können ist das hier als Bridge konfiguriert. Die zusätzlichen Routen/Rules sind nur für die Kommunikation außerhalb des Netzes relevant, innerhalb würde es auch ohne auskommen.

In der VM ist das Netzwerk, abgesehen von der geänderten MTU, ohne besondere Einstellungen mit einer statischen IP konfiguriert:

allow-hotplug enp3s0 iface enp3s0 inet6 static address $Prefix:1101::1/64 gateway $Prefix::1 up ip link set $IFACE mtu 1400

Grundsätzlich funktioniert das so, alle Verbindungen in allen Richtungen sind möglich. Allerdings bricht an einzelnen VMs irgendwann die Verbindung ab, anscheinend hauptsächlich an VMs, an denen kein ständiger Traffic verursacht wird. Zuerst ist das Problem hauptsächlich bei Verbindungen von/nach außen aufgefallen, während intern scheinbar alles funktionierte. Hetzner bestätigte mir, daß die zugehörigen Mac/IPv6-Adressen währenddessen nicht im Router gelistet sind, weshalb ich das Problem zuerst auch dort verortet hatte. Der Support konnte mir dabei aber auch nicht weiterhelfen.

Bei einem ausgiebigen Ping-Test ist dann aber aufgefallen, daß teilweise auch interne Verbindungen aussteigen, sodaß ich den Fehler jetzt eher auf dem Host oder den VMs suchen würde.

Folgendes Test-Szenario (alles Debian 11): 2 Server (Hosts) mit jeweils 2 VMs, Einzelpings aller 5s Pings laufen in beiden Richtungen zwischen allen Beteiligten. Nach einiger Zeit bricht ausschließlich 1 Verbindung ab, manchmal sogar nur eine Richtung davon. Mal ist es die Verbindung von und/oder zum Host, während sich die VMs untereinander als auch mit dem 2. Server weiterhin erreichen, manchmal ist es auch eine VM-Verbindung innerhalb des Servers, während die Verbindung vom/zum Host noch steht.

Das Problem tritt aber auch älteren Hostsystemen (Debian 9/10) auf.

Die Firewall kann ebenso ausgeschlossen werden, da das Problem auch bei deaktivierter Firewall auftritt. Allerdings zeigt ein icmp log/count auch, daß keine Pakete nach der allow-ndp-Regel mehr übrig bleiben.

chain inbound_ipv6 { icmpv6 type echo-request accept icmpv6 type { nd-router-advert, nd-neighbor-solicit, nd-neighbor-advert } accept ip6 nexthdr ipv6-icmp log prefix "[nftables] ICMPv6 Accept: " counter packets 0 bytes 0 limit rate 20/second accept }

Parallel dazu ist ein 2. vSwitch mit einer ähnlichen IPv4-Konfiguration und eine 2. NIC in den VMs konfiguriert, wo das Problem nicht auftaucht. Hier fehlt lediglich die IP-Adresse und die zusätzlichen Routen auf dem Host. Darüber wurden die VMs auch während des Tests beobachtet.

Mit gerouteten IPv6-Verbindungen über das zum Server gehörige IPv6-Netz treten auch keine Probleme auf. Ein allgemeines IPv6- oder Bridge-Problem sollte damit auch ausgeschlossen sein.

Es wurde auch ohne zusätzliche IPv6-Regeln auf dem Host getestet, um das als Fehlerquelle auszuschalten.

Das einzige erkennbare Muster sind Zeitspannen. Der Ausfall erfolgt nach ca. 20-30 min und in den meisten Fällen führte zusätzlicher Traffic auf noch bestehenden Verbindungen nach kurzer Zeit (20-30s) dazu, daß die Verbindung wieder funktionierte.

Aufgrund dieses Fehlerbildes vermute ich das Problem im NDP-Bereich, kenne mich aber damit zu wenig aus, um es weiter zu lokalisieren.

Sind dafür zusätzliche Kerneleinstellungen (sysctl) nötig? Oder ein zusätzlicher Daemon?

Gruß Rico