Proxmox Ausfall beeinträchtigt externen DHCP

[florian.kr]

Hallo Zusammen,

ich habe zum zweiten mal einen merkwürdigen Seiteneffekt festgestellt:

Hat Proxmox Probleme, sind keine DHCP Anfragen mehr möglich. Außer man deaktiviert die Netzwerkports, fährt die Server runter oder nimmt sie irgendwie vom Netz.

Wir haben einen Cluster mit zwei baugleichen Lenovo Servern geerbt. Der damalige Admin hatte eine pfSense mit managed HP Switchen, den 2-Server Cluster mit RAID und ZFS konfiguriert. So wie vorhanden haben wir das erstmal laufen lassen, um dann Stück für Stück umzubauen.

Während dessen ist in der unglücklichen RAID ZFS Kombination mal eine Platte abgeraucht. Proxmox war nicht mehr ansprechbar. Das hatte das ganze Netzwerk lahmgelegt, es wurden keine Adressen mehr vergeben. Die Switche waren damals auch so konfiguriert, dass die Adressen über DHCP bezogen wurden. Eigentlich über die vollkommen unabhängige pfSense. Gut, Platte wurde getauscht, ging dann wieder. Es gab keine für's Netzwerk notwendigen VM's auf der Kiste.

Jetzt ist knapp ein Jahr vergangen.

Wir haben komplett umgebaut. Die pfSense ist weg, die Switche sind jetzt alle von Ubiquiti, DHCP macht die UDMPro, der Cluster wurde "gelöscht" - also neu aufgesetzt mit Proxmox 8, ZFS ohne Hardware RAID und ein dritter älterer IBM Server wurde fürs Quorum ohne Replikation eingebunden. Also eigentlich ein ganz anderes System.

Jetzt gab's vor kurzem ein Update, wo durch die neue Kernelversion die Device ID's der NIC's geändert wurden. Ein manueller Eingriff war da zu erwarten. Unerwartet war aber, dass wieder keine DHCP Anfragen funktioniert haben. Wer zufällig noch/schon eine Adresse hatte konnte z. B. ins Internet etc., statisch vergeben auch, aber sonst gings nicht. Die Server fuhren hoch, melden keine Fehler in den Logs, sie waren nur nicht erreichbar.

Alle ausschalten, das Netzwerkkabel ziehen oder Ports deaktivieren behebt das Problem. Ich hab da etwas verwundert rum probiert. Dann hab ich die NIC's wieder richtig konfiguriert, hoch gefahren, läuft. Aktuell gibt es auch nichts in den VM's, was fürs Netzwerk zwingend erforderlich wäre.

Ich bin da etwas ratlos, was die Ursache betrifft. Dass der Cluster nicht erreichbar ist leuchtet mir ein. Was aber die Verbindung zum DHCP beeinflusst, ist mir grad ein Rätsel.

Hat da jemand einen Ansatz?

Konfigurationsdetails wollte ich euch erstmal ersparen, da das Setup ja funktioniert.

Grüße

Florian

 

[Falk R.]

Hi, ich hätte die HP Switches den von ubiquity vorgezogen, aber nicht das Problem. Eigentlich hat der Hypervisor nie etwas direkt mit dem Netzwerk oder DHCP zu tun. DHCP Requests sind ja Broadcasts, ist das ein großes Layer2 Netzwerk oder gibt es VLANs? Wenn es VLANs gibt, wer routet und wie sind die iphelper Adressen eingetragen?
Wenn das ein Layer2 Netzwerk ist, habt ihr irgendwo anders ein großes Problem. In dem Fall würde ich das Hypervisor Management komplett abschotten.
Außerdem würde ich auch mal die Spanning Tree Konfiguration überprüfen, denn STP sorgt auch gern mal für ganz komische Phänomene wenn es nicht korrekt läuft.

 

[cwt]

STP wäre - wie @Falk R. schon schrieb - ein Ansatz. Sowohl die Topologie-Settings und Priority in den Switchen selbst als auch die jeweiligen Ports (Edgeports sowie Trunks/LAGs/MLAGs). Wie sind die PVEs angebunden? Ist in den Bridges ggf. STP aktiv?

 

[florian.kr]

Hi,

um den Hersteller solls nicht gehen. Ich kenne Cisco, HP, Alcatel und andere. Im Vergleich finde ich die UniFi Reihe gut. Es gibt ein paar Punkte, wo das "Enterprise Grade" Versprechen nicht ganz so zutrifft. Dafür bessern sie bei Featurerequests viel Community freundlicher nach. Für vermutlich 80% der KMU reichts aber wohl.

Das Netz ist natürlich segmentiert, mit mehreren VLAN's, alles läuft über die UDMPro. RSTP ist im Netz aktiviert. Wenn es hier zu Problemen kommen würde,würde dies i. R. im Controller angezeigt werden. Das war nicht der Fall. Die Server befinden sich in einem Netzsegment.

STP ist im Cluster an den Schnittstellen bzw. der Bridge deaktiviert (default). Es erfolgte auch keine ersichtliche Deaktivierung des LAN Ports am Switch oder eine andere Meldung zum STP. Es gibt hier auch keine Möglichkeit einen Loop zu erzeugen. Proxmox fährt hoch, ohne die Schnittstellen zu konfigurieren. Welche Auswirkungen sollte das bzgl. STP haben? Außer Proxmox streut bei einer Fehlkonfiguration willkürliche STP Pakete ins Netz? Da hätte ich mich erstmal auf die Angaben im Controller und die aktivierten Ports verlassen. Wenn STP einen Port sperrt dürfte die statische Adressvergabe auch nicht funktionieren. Daher hätte ich STP eigentlich ausgeschlossen.

Es wird auch kein Link Aggregation o. ä. vorgenommen. Die Server sind ganz gewöhnlich per LAN Kabel am Switch angeschlossen - NIC zu Switch Port 1:1. Das VLAN ist nicht getagged, sondern Port basierend.

Wir haben mehrer Standorte mit je 500-1000 User, überall UniFi, außer an einem haben wir einen "qualitäts" Hersteller - btw viel schlechter als UniFi. Es gibt keine Netzwerkprobleme, außer an dem einen Standort, wenn der Proxmox Cluster hustet.

Der Zusammenhang mit dem DHCP verwundert mich ja selbst. Es war allerdings deutlich nachvollziehbar, dass man das Problem mit dem Cluster und der Fehlkonfiguration "ein- und ausschalten" konnte.

Die weitere Netzwerkkonfiguration wie Trunk Ports etc. funktioniert im regulär gewohntem Zustand. Wenn da was falsch wäre sollte es ja unabhängig davon Probleme machen oder auch bei heruntergefahrenem Cluster weiterhin bestehen.

Vielen Dank schon mal für den Input.

Grüße

Florian

 

[Falk R.]

Hi,

um den Hersteller solls nicht gehen. Ich kenne Cisco, HP, Alcatel und andere. Im Vergleich finde ich die UniFi Reihe gut. Es gibt ein paar Punkte, wo das "Enterprise Grade" Versprechen nicht ganz so zutrifft. Dafür bessern sie bei Featurerequests viel Community freundlicher nach. Für vermutlich 80% der KMU reichts aber wohl.

Da frage mal Netzwerker, spätestens beim Troubleshooting flucht jeder. Aber soll ja nicht zum Thema werden.

Das Netz ist natürlich segmentiert, mit mehreren VLAN's, alles läuft über die UDMPro. RSTP ist im Netz aktiviert. Wenn es hier zu Problemen kommen würde,würde dies i. R. im Controller angezeigt werden. Das war nicht der Fall. Die Server befinden sich in einem Netzsegment.

Das wäre das erste Gerät was Spanning Tree Probleme automatisch erkennt. Ich bin zwar nur der Server/Storage Futzi aber ich musste schon oft genug Netzwerke Troubleshooten. Spanning Tree Falschkonfigurationen oder andere Probleme findest du in der Regel erst am betroffenen Gerät.

STP ist im Cluster an den Schnittstellen bzw. der Bridge deaktiviert (default). Es erfolgte auch keine ersichtliche Deaktivierung des LAN Ports am Switch oder eine andere Meldung zum STP. Es gibt hier auch keine Möglichkeit einen Loop zu erzeugen. Proxmox fährt hoch, ohne die Schnittstellen zu konfigurieren. Welche Auswirkungen sollte das bzgl. STP haben? Außer Proxmox streut bei einer Fehlkonfiguration willkürliche STP Pakete ins Netz? Da hätte ich mich erstmal auf die Angaben im Controller und die aktivierten Ports verlassen. Wenn STP einen Port sperrt dürfte die statische Adressvergabe auch nicht funktionieren. Daher hätte ich STP eigentlich ausgeschlossen.

Hast du die PVE Ports auf Portfast? (edge)

Es wird auch kein Link Aggregation o. ä. vorgenommen. Die Server sind ganz gewöhnlich per LAN Kabel am Switch angeschlossen - NIC zu Switch Port 1:1. Das VLAN ist nicht getagged, sondern Port basierend.

Wir haben mehrer Standorte mit je 500-1000 User, überall UniFi, außer an einem haben wir einen "qualitäts" Hersteller - btw viel schlechter als UniFi. Es gibt keine Netzwerkprobleme, außer an dem einen Standort, wenn der Proxmox Cluster hustet.

Der Zusammenhang mit dem DHCP verwundert mich ja selbst. Es war allerdings deutlich nachvollziehbar, dass man das Problem mit dem Cluster und der Fehlkonfiguration "ein- und ausschalten" konnte.

Die weitere Netzwerkkonfiguration wie Trunk Ports etc. funktioniert im regulär gewohntem Zustand. Wenn da was falsch wäre sollte es ja unabhängig davon Probleme machen oder auch bei heruntergefahrenem Cluster weiterhin bestehen.

Die UDMPro macht ja das Routing. Sind da IP-Helper Adressen vergeben oder habt ihr vom DHCP jeweils Ports in alle Netze?

 

[florian.kr]

Da frage mal Netzwerker, spätestens beim Troubleshooting flucht jeder. Aber soll ja nicht zum Thema werden.

Warum? Das sind Linux Kisten, du hast dort die üblichen Logs in /var/log oder journalctl mit remote logging Möglichkeiten. Die meisten Dienste sind aus dem GNU/Linux Umfeld und das Troubleshooting steht und fällt mit der Kommunikationsfreudigkeit dieser Dienste. Ich empfinde diese allgemein als sehr gut, im Vergleich zu manch kryptischer Meldung von namenhaften Herstellern. Wäre man bei Proxmox nicht falsch, wenn man Linux ein schlechtes Troubleshooting nachsagen würde?
Wenn deine Admins Netzwerk- und Serverinfrastruktur betreiben sind doch gleich lautende Fehlermeldungen eher ein Segen?
UniFi muss andere Kanten schleifen und das scheinen sie auch zu machen. Wie gesagt für die meisten reichts wohl, die Produktionsstraße im kongolesischen Dschungel macht dann nur Cisco.

Das wäre das erste Gerät was Spanning Tree Probleme automatisch erkennt. Ich bin zwar nur der Server/Storage Futzi aber ich musste schon oft genug Netzwerke Troubleshooten. Spanning Tree Falschkonfigurationen oder andere Probleme findest du in der Regel erst am betroffenen Gerät.

Im Controller tauchen Logs auf und die Topologie basiert auf (R)STP. Der einzelne Portstatus kann ausgelesen werden. Wenn es dir dort alles durcheinander würfelt, die Logs voll laufen und Ports willkürlich gesperrt werden erkennt der Admin das Problem zentral, nicht das Gerät selbst. Ist natürlich kein Wunderkasten. In Bezug auf mein Problem gab es 0,0 Auffälligkeiten. Bei UniFi werden die Geräte zentral konfiguriert. Eine fehlerhafte Konfiguration stellt man i. R. im Controller fest. Am Gerät soll nichts konfiguriert werden.

Hast du die PVE Ports auf Portfast? (edge)

Andere Frage: Ich hab ein Notebook am Switch angeschlossen. Port Status "Forwarding", so auch beim einzigen UP Link zum Aggregation Switch, so auch der einzige UP Link zur UDMPro. Ich konfiguriere die Adressen statisch und kann vom Ping bis Google alles, auch zu anderen Geräten im Netz, stabil. Parallel läuft DHCPing und erhält keine Antwort solange Proxmox "läuft".

Inwiefern ist (R)STP hierfür verantwortlich?
Inwiefern ist es jetzt sinnvoll, sich auf STP festzufahren? Ich halte das erstmal für ausgeschlossen. Du nicht? Warum?

(R)STP würde mir ja sämtlichen Datenverkehr deaktivieren, sollte den Port auf "Discarding" setzen und nicht nur DHCP verschlucken. So dann auch auf allen Ebenen in der Topologie. Die Switche sollten ausfallen, wenn der Port geblockt wird etc. Es verhält sich aber alles normal, wie es soll. Außer DHCP.

Wenn ich eine durchgängig aktive Verbindung habe, u. a. auch einen Download laufen lassen kann und nur kein DHCP Request funktioniert, inwiefern ist das ein Spanning-Tree Problem? Ich hab das oben nur kurz erwähnt, dass bei statischer Vergabe "alles funktioniert".

Die UDMPro macht ja das Routing. Sind da IP-Helper Adressen vergeben oder habt ihr vom DHCP jeweils Ports in alle Netze?

Die UDM hat je Netz auch eine Schnittstelle mit Adresse.

Danke für den Input.

Grüße

Florian

 

[cwt]

Wenn Du STP und Fehlkonfigs in den Switchen ausschliessen kannst, wäre eine tiefergehende Analyse wahrscheinlich hilfreich (Wireshark o.ä.). Noch eine Randfrage: welche NICs verwendest Du in den PVEs? Ggf. gäbe es da noch Probleme (hardwareseitiges VLAN filtering, bei SFP u.U. Probleme mit den Modulen, etc.).

 

[florian.kr]

TCPDump steht auf der ToDo, wenn ich mal ein Zeitfenster für eine Downtime habe.

Vee'rbaut sind NIC's von Intel - X722 ohne SFP.

Ich schließe nichts zu 100% aus. Beim STP sehe ich nur, dass man sich da unnötig festfahren könnte.

Danke für den Input.

Grüße

Florian

 

[Falk R.]

Ich habe selbst nie Unify in den Händen gehabt, ist mir persönlich zu teuer für die Leistung. Das ist aber meine Meinung.
Anscheinend machen die ja doch noch einiges anders als alle andern Hersteller. Das man auf die Linux Logs zugreifen kann, war mir neu, da ich schon fluchende Admins hatte, die auf der GUI keine vernünftigen Fehlermeldungen hatten und die CLI war extrem eingeschränkt. Kann aber auch an den Modellen liegen.

Klar geht der Port wo du dich anschließt in Forwarding, sonst wäre der Port geblockt. Setzt man einen Port auf Edge/Portfast oder bei manchen auch disable STP, dann wird der Port niemals geblockt, auch nicht temporär bei einer Neuberechnung.

Dein Fehler könnte damit zusammenhängen, dass Ports temporär nicht erreichbar sind oder die Routinginstanz eventuell die DHCP Requests nicht korrekt weiterleitet. Da du anscheinend keine Portchannels (bonds) benutzt, würde ich ARP Cache Fehler eigentlich ausschließen. Aber du kannst ja mal schauen was der ARP Cache der Switches sagt, wenn das Problem wieder auftaucht.