Ich habe gerade ein NAS mit Debian Buster auf Debian Bullseye aktualisiert. Dies beinhaltete ein Kernel-Upgrade von 4.19.0 auf 5.9.0 und ein Systemd-Upgrade von 241 auf 247.1 (das System verwendet systemd-networkd zur Konfiguration).
Die Netzwerkkonfiguration ist mäßig komplex:
eno1/eno2: Dual-Port Intel I210 Onboard-Gigabit-Ethernet (unter Verwendung des igb-Treibers)
Hauptschnittstelle: 802.3ad-Bonding-Schnittstelle mit eno1/eno2 als physische Verbindungen
vlan60/vlan63: VLAN-Subschnittstellen, die main als Basis verwenden
main, vlan60, und vlan63haben alle IPv4- und IPv6-Adressen, aber auf eno1oder sind keine Adressen vorhanden eno2.
Alle Schnittstellen verwenden den Standard-MAC-Adressmodus, d. h. alle fünf verwenden die integrierte MAC-Adresse von eno1. Beim Versuch, dieses Problem zu lösen, habe ich lokal verwaltete MAC-Adressen auf vlan60und konfiguriert vlan63, aber das hat nicht geholfen (tatsächlich wurde dadurch die IPv6-Unterstützung auf unterbrochen main, aber ich habe nie herausgefunden, warum).
Mit der Buster-Konfiguration funktionierte das alles einwandfrei. Nach dem Upgrade auf Bullseye mainfunktioniert es einwandfrei, aber vlan60es vlan63wird kein Datenverkehr gesendet oder empfangen. Interner Datenverkehr zu/von ihren Adressen funktioniert einwandfrei, externer Datenverkehr jedoch nicht.
Beim Versuch, das Problem zu beheben, begann ich tcpdumpmit vlan63und bemerkte sofort, dass der Datenverkehr wieder zu fließen begann. Durch das Stoppen der Paketerfassung wurde der Datenverkehr erneut gestoppt.
Im Moment habe ich das System durch Ausführen von ip link eno1 set promisc onund zum Laufen ip link eno2 set promisc ongebracht, und alle Schnittstellen leiten problemlos Daten weiter. Es ist nicht notwendig, den Promiscuous-Modus auf den Schnittstellen höherer Ebene zu aktivieren, nur auf den physischen Schnittstellen.
Wenn der Promiscuous-Modus nicht aktiviert ist, scheinen die VLAN-Subschnittstellen keine Broadcast-Frames vom Netzwerk zu empfangen, was dazu führt, dass ARP und NDP nicht funktionieren.
Gab es zwischen diesen Kernel-Versionen (ich weiß, das sind viele Kernel-Versionen …) Verhaltensänderungen, die dies beeinflussen könnten?
Antwort1
Ich bin nicht sicher, was der Kernel geändert hat, aber ich hatte das gleiche Problem auf Proxmox VE 7.0 (Debian 11) mit Kernelversion 5.11.22-1. Das Problem war behoben, als ich die Kernelversion auf 5.11.22-3 aktualisierte.
Es könnte ein Kernelproblem sein. Aktualisieren Sie einfach auf eine neuere Kernelversion, dann tritt das Problem nicht mehr auf.