verliert ständig Netzwerkverbindung (Ethernet)

[Malz1902]

Habe einen Intel NUC, auf diesem läuft Proxmox, seit gestern ist Version 9 vorher 8.4. Problem war bereits mit Version 8.4
PVE hat eine statische IP, auch alle VMs und CTs haben jeweils eine statische IP. Nach X Stunden verlieren alle VMs, CTs und Proxmox die Netzwerkverbindung. Ich kann die Geräte weder anpingen, noch die Weboberfläche aufrufen, auch in der Fritz.box tauschen die Geräte nicht mehr auf. Es hilft nur einmal das LAN Kabel zu entfernen und wieder zu verbinden, danach ist der NUC samt Proxmox, VMs und CTs wieder erreichbar. Was könnte hier das Problem sein? In welcher Log könnte ich schauen, ob ein Fehler vorliegt? Solltet Ihr weitere Infos benötigen, kann ich euch die gerne liefern.

Problem besteht erst seit ca. 3 Wochen, dafür lief das Ganze 3 Jahre ohne Probleme

 

[jim_os]

Das wird mit ziemlicher Sicherheit an der in dem NUC verbauten Intel NIC liegen, allerdings hättest Du das Problem dann eigentlich schon seit Kernel 6.8.12-9 und auch schon vor PVE 8.4 haben müssen.

Zu dem Intel NIC Problem siehe die div. Diskussionen dazu hier im Forum, wie z.B. diese hier. Also erst einmal das klären und z.B. den passenden ethtool Befehl nutzen und dann sieht man weiter.

VG Jim

 

[ThoSo]

Prüfe mal die Fritz!box, falls der PVE direkt an einem Port hängt auf die Energiesparfuktionen. Den LAN Port 1 und 4 bitte meiden.
Am besten einen kleinen Switch dazwischen hängen.

 

[jim_os]

Ich weiß zwar nicht genau was @ThoSo jetzt mit

direkt an einem Port hängt auf die Energiesparfuktionen. Den LAN Port 1 und 4 bitte meiden.

meint und ob er vielleicht einfach nur den Green Mode meint


der aber das von Dir beschriebene Problem eigentlich nicht hervorrufen dürfte, aber sein Posting hat mich noch auf eine Idee gebracht. Nutzt Du eine FB zu der es bereits ein Update auf Fritz!OS 8.20 gab und wenn ja hast Du das installiert? Falls ja: AVM hat an ihrer EEE (Energy Efficient Ethernet) Funktion "herumgebastelt" und damit gibt es - lt. anderen Usern - jetzt ggf. Probleme. Wenn Du also bereits 8.20 nutze dann kannst Du EEE ja auch mal deaktivieren.

1. Klicken Sie in der Benutzeroberfläche der FRITZ!Box auf "Heimnetz".
2. Klicken Sie im Menü "Heimnetz" auf "Netzwerk".
3. Klicken Sie auf die Registerkarte "Netzwerkeinstellungen".
4. Klicken Sie bei dem verwendeten LAN-Anschluss auf die Schaltfläche
   
   (Bearbeiten).
5. Deaktivieren Sie die Option "Energy Efficient Ethernet".
6. Klicken Sie zum Speichern der Einstellungen auf "Übernehmen".

Vielleicht meinte @ThoSo ja auch schon dieses Problem mit Fritz!OS 8.20?

Ich nutze hier Fritz!OS 8.20 noch nicht und ich pers. glaube bei Deinem Problem immer noch eher an das bekannte Problem mit den Intel NICs. Edit: Was hier bei meinem NUC8 in Verbindung mit Proxmox auch besteht. Wobei ich den NUC8 aktuell nicht für Proxmox nutze.

VG Jim

 

[bl1mp]

Hey,
die Ursache für den Fehler könnte ein paar Ursachen haben. Da sind noch ein paar Ursachen die mir in den Sinn kommen als Ursache,
falls es nicht an den Einstellungen der Fritzbox liegt:

- Es könnte es auch an der Verkabelung liegen.
- Hast du ggf. einer der VMs/einem Gerät im Netzwerk ausversehen die gleiche IP-Addresse zugeteilt? (Das könnte dann die ARP-Tabelle des Routers stören.)

Systematische Informationen zu einzelnen Interfaces findest du im Betriebssytem unter /sys/class/net/<interface_name>.
Zum besseren Verständnis der Konfiguration, hast du in der Datei /etc/network/interfaces für das Interface allow-hotplug oder auto eingetragen?


BG, Lucas

 

[jim_os]

@bl1mp Nichts gegen Deine Ideen und Vorschläge, weil Ideen und Vorschläge sind immer gut und könnten ggf. helfen, aber @Malz1902 hat u.a. geschrieben:

Problem war bereits mit Version 8.4
...
PVE hat eine statische IP, auch alle VMs und CTs haben jeweils eine statische IP.
...
Nach X Stunden verlieren alle VMs, CTs und Proxmox die Netzwerkverbindung.
...
dafür lief das Ganze 3 Jahre ohne Probleme

Wie groß ist da die Wahrscheinlichkeit das es evtl. am LAN-Kabel, oder an evtl. doppelt vergebenen IPs liegt?

VG Jim

 

[ThoSo]

@jim_os - Ich habe mir das gerade mal auf der Fritte 7590 mit dem EEE angesehen :




Das sind die "default" Einstellungen nach der Fw8.20 - den PowerMode habe ich bei mir schon immer aktiviert und am EEE habe ich bisher noch nie herumgespielt - hatte den nicht auf dem Schirm.
Wie man sieht, ist der aber bei automatisch wohl freiwillig" inaktiv" - hätte den jetzt glatt ausgemacht.
Allerdings habe ich an einem Port einen kleinen 1Gb Switch hängen - da ich auch physisch zwei Stränge habe und bei einem Neustart der Fritte in Netz keine Unterbrechung meines Netzwerkes will.

Insofern, war ich nur beim 1Git/s Power Mode.
Ein "maken" auf dem Port kann auch sein.
Ein Kabel kann man übrigens nie ganz ausschließen - was sich aber durch tauschen dann ausschließen lässt.

 

[jim_os]

und am EEE habe ich bisher noch nie herumgespielt - hatte den nicht auf dem Schirm.

Diese Einstellung in Deinem Screensot gibt es m.W. auch erst seit Fritz!OS 8.20 (zumindest bei einer FB7590) und lt. anderen Usern soll es damit wohl auch ein Problem geben. Wie gesagt nutze ich hier bei meiner 7590 noch nicht 8.20, sondern die Version 8.02. Die 0-er Version von AVM - also x.x0 - sind m.M.n. eh immer mit etwas Vorsicht zu genießen, sodass ich diese meistens auslasse und auf eine Version x.x1 oder x.x2 warte.

Aktuell scheint die beste Vorgehensweise wohl zu sein EEE besser zu deaktivieren. Wobei - wie üblich - die EEE-Funktion natürlich nicht bei allen Usern (die gleichen) Probleme macht.

war ich nur beim 1Git/s Power Mode.

Die Ports auf/in den Green Mode zu schalten dürfte aber eigentlich nicht zu dem genannten Problem führen, denn auch im Green Mode schalten sich die Ports ja nicht irgendwann einfach ab, sondern es wird nur die Geschwindigkeit auf 100 Mbit/s verringert.

Ein Kabel kann man übrigens nie ganz ausschließen

Das ist schon klar, aber @Malz1902 hatte ja auch geschrieben

Nach X Stunden verlieren alle VMs, CTs und Proxmox die Netzwerkverbindung.
...

Es hilft nur einmal das LAN Kabel zu entfernen und wieder zu verbinden,

und die Wahrscheinlichkeit das ein LAN-Kabel erst x Stunden lang funktioniert, dann plötzlich die Verbindung verliert und sie wieder aufbaut wenn man es einmal abzieht, ist m.M.n. doch schon sehr gering. Ein LAN-Kabel hat üblicherweise auch keine thermischen Probleme, die so gut wie als einzige Möglichkeit für so ein Verhalten dann in Betracht kommen könnten. Aber ok, ein LAN-Kabel ist - so quasi als letzte Hoffnung falls in dem Fall nichts helfen sollte - ja auch mal schnell getauscht.

VG Jim

 

[ThoSo]

Hast du das Kabel gesehen? Ich nicht. Aber es soll auch Kabel geben, wo die Nase ab ist und dann verrutschen… alles schon da gewesen.
Jetzt soll er mal unsere Ideen prüfen und bitte berichten.
Bin mal gespannt.

 

[jim_os]

alles schon da gewesen.

Lass uns diesbezüglich eine virtuelle Wette abschließen. Ich wette das Kabel ist es nicht.

Jetzt soll er mal unsere Ideen prüfen und bitte berichten.

Genau - aber z.z.

Bin mal gespannt.

Dto.

VG Jim

 

[Josch]

Habe einen Intel NUC, auf diesem läuft Proxmox, seit gestern ist Version 9 vorher 8.4. Problem war bereits mit Version 8.4
PVE hat eine statische IP, auch alle VMs und CTs haben jeweils eine statische IP. Nach X Stunden verlieren alle VMs, CTs und Proxmox die Netzwerkverbindung. Ich kann die Geräte weder anpingen, noch die Weboberfläche aufrufen, auch in der Fritz.box tauschen die Geräte nicht mehr auf. Es hilft nur einmal das LAN Kabel zu entfernen und wieder zu verbinden, danach ist der NUC samt Proxmox, VMs und CTs wieder erreichbar. Was könnte hier das Problem sein? In welcher Log könnte ich schauen, ob ein Fehler vorliegt? Solltet Ihr weitere Infos benötigen, kann ich euch die gerne liefern.

Problem besteht erst seit ca. 3 Wochen, dafür lief das Ganze 3 Jahre ohne Probleme

Hatte gleiches Problem. Dieses Script hat geholfen. Zumindest hatte ich seit dem keinen Ausfall mehr. Es hilft übrigens temporär, wenn man das LAN-Kabel kurz trennt und wieder verbindet.

 

[jim_os]

Dieses Script hat geholfen.

Dafür braucht es nicht unbedingt dieses Script, weil das auch nur den entsprechenden ethtool Befehl ausführt,

[Service]
Type=oneshot
# Disable all offloading features for Intel $DRIVER
ExecStart=/sbin/ethtool -K $SELECTED_INTERFACE gso off gro off tso off tx off rx off rxvlan off txvlan off sg off
RemainAfterExit=true

was ich in #2 ja bereits erwähnt hatte. Bevor man das/ein Script auf PVE loslässt sollte man auf jeden Fall klären ob das auch bei der genutzten PVE-Version funktioniert und m.M.n. noch besser, vielleicht auch im Vorfeld verstehen was dieses Script dann macht.

Es hilft übrigens temporär, wenn man das LAN-Kabel kurz trennt und wieder verbindet.

Es hilft nur einmal das LAN Kabel zu entfernen und wieder zu verbinden,

VG JIm

 

[GMBauer]

Bevor man das/ein Script auf PVE loslässt sollte man .... vielleicht auch im Vorfeld verstehen was dieses Script dann macht.

Das sind aber hohe Ansprüche....

 

[bl1mp]

Wie groß ist da die Wahrscheinlichkeit das es evtl. am LAN-Kabel, oder an evtl. doppelt vergebenen IPs liegt?

Einfach der Vollständigkeit halber:

Das LAN-Kabel muss nicht vollständig defekt sein, es kann auch einfach sein, dass es Beschädigungen hat (oder ein UTP-Kabel ist mit Überlagerungen), die zu Störeffekten führen, die dazu führen können, dass wenn die Hosts beide autonegotian eingeschaltet haben sich gegenseitig runter handeln. Das geht dann manchmal eine Weile gut, dann schaltet eine Seite ab. Da vmtl. die Verbindung nicht gemonitored wird, sieht es dann nach einer Weile so aus als wäre der Port einfach aus. Das lässt sich ggf. mit ethtool testen, das zeigt die aktuell verwendete Geschwindigkeit an und kann dann einen Hinweis auf eine potenzielle Degration geben.

Bei einer doppelt verwendeten IP-Addresse kommt es immer darauf an, wer zuletzt die ARP-Tabelle befüllt hat.
Bei meinen WiFi eingebundenen Heizkörper Thermostaten oder nur periodisch laufenden Systemen (z.B. Containern), kann das manchmal eine Weile dauern.

Treiberprobleme auf einer der beiden Seite (nach einem Update) könnten auch eine Ursache sein.
Hab schon 10G-Karten gesehen, die dann nach 10 Minuten an einer 1G-Verbindung Amok liefen, überhitzten und vmtl. durch die thermischen Einschränkungen nur noch sporadische Verbindungen zustande brachten.

BG, Lucas

 

[jim_os]

Das sind aber hohe Ansprüche....

Du weißt doch: Die Hoffnung stirbt bekanntlich zuletzt.

Einfach der Vollständigkeit halber:

Der TE setzt ja wohl einen NUC8i5BEH ein - wovon ich hier selber zwei Stück seit Jahren im Einsatz habe. In dem NUC ist eine Intel I219-V NIC verbaut und sehr wahrscheinlich in der (rev 30) Variante. U.a. die Intel I219-V NICs haben das bekannte "e1000 Problem", bei dem es dann genau zu dem von dem TE genannten Effekten und Problem kommt. Woher ich das weiß? Weil ich das Problem mit dem NUC8i3BEH auch schon mal im Jahr 2022 hatte, als ich den noch für Proxmox genutzt habe. Auch schon damals musste man per ethtool Befehl die entsprechenden Einstellungen für die NIC machen und schon war das Problem gelöst. Daran hat sich bis heute nichts geändert, nur das es zwischendurch mal Kernel-Versionen gab bei denen die Anpassung per ethtool Befehl - warum auch immer - nicht notwendig war, weil das Problem mit der Kernel-Version x, y oder z nicht aufgetreten ist.

Was mich bei dem TE nur wundert ist - wie ich ja bereits geschrieben hatte - das das Problem bei ihm nicht schon vorher mit einem Kernel ab der Version 6.8.12-9 aufgetreten ist, denn eigentlich tritt das Problem bereits seit der Version 6.8.12-9 bei vielen Intel NICs wieder auf. Davor gab es halt Kernel-Versionen bei denen das Problem nicht aufgetreten ist. Aber welche Kernel-Version der TE dann wann und womit genutzt hat hat er ja auch nicht geschrieben, sondern nur das das Problem bei ihm bereits mit PVE 8.4 bestanden hat.

Wie schon gesagt: Wie groß ist in dem Fall die Wahrscheinlichkeit das es nicht an der Intel NIC liegt, sondern irgendeinen anderen Grund hat?

Aber ich bin hier jetzt auch raus. Da das Problem bei dem TE ja auch schon seit 3 Wochen besteht scheint eine Lösung ja auch nicht so dringend zu sein. Ergo gibt es hier und jetzt für mich auch keinen Grund mehr mir darüber Gedanken zu machen und/oder darüber zu diskutieren.

VG JIm

 

[GMBauer]

Da er sich auch nicht mehr meldet, egal mit welcher Rückmeldung, dürfte das Problem wohl gelöst sein.