Wiederkehrende Verbindungsprobleme und ungewöhnliche Kernel Nachrichten

[stkw]

Ich kämpfe seit einigen Tagen mit dem Problem dass sich das Webinterface von Proxmox immer wieder verabschiedet und nach wenigen Sekunden dann doch wieder erreichbar ist. Scheinbar startet hier der Dienst immer wieder neu oder es ist ein Netzwerkproblem. Generell bleiben aber alle VMs ansprechbar und auch deren Netzwerkdienste sind erreichbar, auch wenn das Webinterface von Proxmox ausfällt.

Heute ist mir aufgefallen dass ich folgende Nachrichten im Syslog habe welche ich für ungewöhnlich halte:
(Diese Nachrichten tauchen alle paar Sekunden auf, scheinbar aber erst seit den letzten Kernel Updates)

Dec 06 10:00:24 pve kernel: br-ecacd9f68f57: port 2(vethc123a7c) entered blocking state
Dec 06 10:00:24 pve kernel: br-ecacd9f68f57: port 2(vethc123a7c) entered disabled state
Dec 06 10:00:24 pve kernel: device vethc123a7c entered promiscuous mode
Dec 06 10:00:24 pve kernel: br-ecacd9f68f57: port 3(vethbf26f6f) entered blocking state
Dec 06 10:00:24 pve kernel: br-ecacd9f68f57: port 3(vethbf26f6f) entered disabled state
Dec 06 10:00:24 pve kernel: device vethbf26f6f entered promiscuous mode
Dec 06 10:00:24 pve kernel: br-ecacd9f68f57: port 3(vethbf26f6f) entered blocking state
Dec 06 10:00:24 pve kernel: br-ecacd9f68f57: port 3(vethbf26f6f) entered forwarding state
Dec 06 10:00:25 pve kernel: br-ecacd9f68f57: port 3(vethbf26f6f) entered disabled state
Dec 06 10:00:25 pve kernel: eth0: renamed from vethad78576
Dec 06 10:00:25 pve kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethbf26f6f: link becomes ready
Dec 06 10:00:25 pve kernel: br-ecacd9f68f57: port 3(vethbf26f6f) entered blocking state
Dec 06 10:00:25 pve kernel: br-ecacd9f68f57: port 3(vethbf26f6f) entered forwarding state
Dec 06 10:00:26 pve kernel: eth0: renamed from vethb4f8052
Dec 06 10:00:26 pve kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethc123a7c: link becomes ready
Dec 06 10:00:26 pve kernel: br-ecacd9f68f57: port 2(vethc123a7c) entered blocking state
Dec 06 10:00:26 pve kernel: br-ecacd9f68f57: port 2(vethc123a7c) entered forwarding state
Dec 06 10:00:26 pve kernel: br-ecacd9f68f57: port 4(veth7a32bf4) entered blocking state
Dec 06 10:00:26 pve kernel: br-ecacd9f68f57: port 4(veth7a32bf4) entered disabled state
Dec 06 10:00:26 pve kernel: device veth7a32bf4 entered promiscuous mode
Dec 06 10:00:26 pve kernel: br-ecacd9f68f57: port 4(veth7a32bf4) entered blocking state
Dec 06 10:00:26 pve kernel: br-ecacd9f68f57: port 4(veth7a32bf4) entered forwarding state
Dec 06 10:00:27 pve kernel: br-ecacd9f68f57: port 4(veth7a32bf4) entered disabled state
Dec 06 10:00:27 pve kernel: br-ecacd9f68f57: port 2(vethc123a7c) entered disabled state
Dec 06 10:00:27 pve kernel: vethb4f8052: renamed from eth0
Dec 06 10:00:27 pve kernel: eth0: renamed from vethf14815f
Dec 06 10:00:27 pve kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth7a32bf4: link becomes ready
Dec 06 10:00:27 pve kernel: br-ecacd9f68f57: port 4(veth7a32bf4) entered blocking state
Dec 06 10:00:27 pve kernel: br-ecacd9f68f57: port 4(veth7a32bf4) entered forwarding state
Dec 06 10:00:27 pve kernel: br-ecacd9f68f57: port 2(vethc123a7c) entered disabled state
Dec 06 10:00:27 pve kernel: device vethc123a7c left promiscuous mode
Dec 06 10:00:27 pve kernel: br-ecacd9f68f57: port 2(vethc123a7c) entered disabled state
Dec 06 10:00:29 pve kernel: eth0: renamed from veth6cf1b8b
Dec 06 10:00:29 pve kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth2091b20: link becomes ready

Kann mir jemand sagen ob das mit den Webinterface Ausfällen zu tun haben könnte?

 

[gmed]

Was für eine Netzwerkkarte / Modul dafür nutzt der Host?

 

[stkw]

In dem Fall die interne Netzwerkkarte des Motherboards (ASUS Prime Z490M-Plus Gaming Mainboard Sockel 1200 (micro ATX, IntelZ490, USB 3.2 Gen 2, 2x M.2-Steckplätze, VRM-Kühler))
Alternativ hätte ich noch eine Intel NIC I350-T2 V2 als Alternative, wobei diese Probleme erst kürzlich begonnen haben.
Die Netzwerkconfig sieht wie folgt aus:

 

[gmed]

Welche Proxmox Version bzw. Kernel läuft bei dir?
In letzter Zeit ein dist-upgrade gemacht?

 

[stkw]

Sorry dass ich das nicht schon im ersten Post geschrieben habe:

Kernel Version Linux 5.4.78-1-pve #1 SMP PVE 5.4.78-1 (Mon, 30 Nov 2020 10:57:47 +0100)

PVE Manager Version pve-manager/6.3-2/22f57405

 

[gmed]

installiere ethtool, falls noch nicht vorhanden und probiere das mal aus:

/sbin/ethtool -K eno1 gso off gro off tso off && /sbin/ethtool -K eno1 tx off rx off

 

[stkw]

Darf ich fragen was der Befehl auslöst? Liest sich im ersten Moment so als würde ich die Netzwerkkarte abschalten oder zumindest receive und transmit abschalten.

 

[stkw]

Features for eno1:
rx-checksumming: on
tx-checksumming: on
        tx-checksum-ipv4: off [fixed]
        tx-checksum-ip-generic: on
        tx-checksum-ipv6: off [fixed]
        tx-checksum-fcoe-crc: off [fixed]
        tx-checksum-sctp: off [fixed]
scatter-gather: on
        tx-scatter-gather: on
        tx-scatter-gather-fraglist: off [fixed]
tcp-segmentation-offload: on
        tx-tcp-segmentation: on
        tx-tcp-ecn-segmentation: off [fixed]
        tx-tcp-mangleid-segmentation: off
        tx-tcp6-segmentation: on
udp-fragmentation-offload: off
generic-segmentation-offload: on
generic-receive-offload: on
large-receive-offload: off [fixed]
rx-vlan-offload: on
tx-vlan-offload: on
ntuple-filters: off [fixed]
receive-hashing: on
highdma: on [fixed]
rx-vlan-filter: off [fixed]
vlan-challenged: off [fixed]
tx-lockless: off [fixed]
netns-local: off [fixed]
tx-gso-robust: off [fixed]
tx-fcoe-segmentation: off [fixed]
tx-gre-segmentation: off [fixed]
tx-gre-csum-segmentation: off [fixed]
tx-ipxip4-segmentation: off [fixed]
tx-ipxip6-segmentation: off [fixed]
tx-udp_tnl-segmentation: off [fixed]
tx-udp_tnl-csum-segmentation: off [fixed]
tx-gso-partial: off [fixed]
tx-sctp-segmentation: off [fixed]
tx-esp-segmentation: off [fixed]
tx-udp-segmentation: off [fixed]
fcoe-mtu: off [fixed]
tx-nocache-copy: off
loopback: off [fixed]
rx-fcs: off
rx-all: off
tx-vlan-stag-hw-insert: off [fixed]
rx-vlan-stag-hw-parse: off [fixed]
rx-vlan-stag-filter: off [fixed]
l2-fwd-offload: off [fixed]
hw-tc-offload: off [fixed]
esp-hw-offload: off [fixed]
esp-tx-csum-hw-offload: off [fixed]
rx-udp_tunnel-port-offload: off [fixed]
tls-hw-tx-offload: off [fixed]
tls-hw-rx-offload: off [fixed]
rx-gro-hw: off [fixed]
tls-hw-record: off [fixed]

Ich weiß dass das jetzt nicht der gewünschte Befehl war, wollte aber vorab die Features zeigen die aktiviert sind.

 

[gmed]

Fragen ist immer gut*S*

tx und rx sind Schalter für das Kernel-Modul der NIC, welche das Nutzen von Prüfsummen aktivieren/ deaktivieren.
In meinem Beispiel wird beides abgeschaltet und die NIC damit nicht zusätzlich belastet.
Bei gso und tso geht es um Segmentierung von Packeten, welche hier auch abgeschaltet wird.

Also schaltest du damit sicher nicht deinen Netzwerkkarte aus.

du kannst auf der Konsole auch mal ethtool -h eingeben.
Dann erhälst du eine Auflistung der möglichen Optionen.

Übrigens musst du eno1 noch an die Bezeichnung deiner NIC anpassen, evtl. eth0 o.ä.

 

[gmed]

Features for eno1:
rx-checksumming: on
tx-checksumming: on

die werden mit meinem Befehl abgeschaltet

 

[gmed]

generic-segmentation-offload: on
generic-receive-offload: on

die auch

 

[gmed]

tcp-segmentation-offload: on

und der hier

 

[gmed]

Wir nutzen das bei dreien unserer Server auch und haben damit keine Probleme.
Übrigens übersteht diese Einstellung keinen Reboot.

Wenn diese Einstellung hilfreich ist, dann muss man sie über die interfaces-Datei in /etc/network/ permanent machen.
Sonst ist diese Einstellung nach jedem Neustart wieder weg.

 

[stkw]

Danke für die ausführliche Information - ich werde es testen und hier rückmelden.

 

[stkw]

Meine Probleme (die Erreichbarkeit, der WebUI) treten nun seltener auf, aber sind noch nicht komplett weg.
Danke trotzdem für den Tipp - es ist ein vielfaches besser.

 

[coldenburg]

Hast du auf deiner Bridgekonfiguration Spanning Tree abgeschaltet ?
Das sind nämlich Spanning Tree Meldungen in deinem Syslog.
Schau mal nach ob auf deinem Interface vmbr0 die Parameter „bridge-stp off“ und „ bridge-fd 0“ gesetzt sind.

 

[stkw]

Das sind die Einstellungen in /etc/network/interfaces für vmbr0:

auto vmbr0
iface vmbr0 inet static
        address 192.168.0.184/24
        gateway 192.168.0.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094

 

[Stoiko Ivanov]

br-ecacd9f68f57: port 2(vethc123a7c) entered blocking state

br-ecacd9f68f57: port 2(vethc123a7c) entered disabled state

Weder der bridge name noch der port-name sehen so aus wie jene, die von PVE erzeugt werden?
(vmbrX und veth$VMIDiX)

woher kommt br-ecacd9f68f57? - ist sie immer da? (`ip link` output)

 

[stkw]

Verzeihung für die ungenaue Angabe - diese Meldungen sind weg seit ich folgenden Befehl ausgeführt habe:
/sbin/ethtool -K eno1 gso off gro off tso off && /sbin/ethtool -K eno1 tx off rx off

 

[Stoiko Ivanov]

Freut prinzipiell zu hören.

Die Frage woher die bridge-interface names kommen wäre potentiell dennoch gut zu klären...