jsysde
Goto Top

NIC-Teaming-Probleme mit Intel-NICs

Moin zusammen.

Ich stolpere hier gerade über ein merkwürdiges Phänomen in Verbindung mit Windows Server (2012R2/2016/2019/2022) und NIC-Teaming mit Intel I350 und Intel ET Adaptern. Die meisten Server, auf denen die Probleme auftreten, sind HyperV-Hosts, es trifft aber auch zwei Hardware-DCs. Auf Servern, die mit Intel X<nnn>-Adaptern ausgerüstet sind, besteht das Problem nicht.

Problem: Auf all diesen Servern liefert netstat -e verworfene bzw. fehlerhafte Pakete. Aber auch nur dort, die jeweiligen Switchports sind absolut sauber, dort sind keinerlei Fehler zu sehen. Auch sind alle Server einwandfrei erreichbar und verrichten klaglos ihren Dienst. Auf allen betroffenen Servern ist das NIC-Teaming via Server Manager oder PowerShell eingerichtet worden.

Wir setzen CheckMK als Monitoring-Software ein, seit dem Update auf 2.2.0p27 sehen wir plötzlich massig Warnung/Alarme von diesen Systemen, ausgelöst durch diese Änderungen: https://checkmk.com/werk/16879

Kurz gesagt, diese ominösen Fehler waren schon immer da, wir haben sie bis dato schlicht nicht bemerkt bzw. sie wurden nicht visualisiert.

Hat jemand ne Idee, was da passiert?
Danke euch.

Cheers,
jsysde

Content-ID: 61607054121

Url: https://administrator.de/forum/nic-teaming-probleme-mit-intel-nics-61607054121.html

Ausgedruckt am: 24.12.2024 um 18:12 Uhr

aqui
aqui 18.06.2024 um 14:17:25 Uhr
Goto Top
Die Kardinalsfrage ist natürlich WELCHE Art von Teaming?
Zu mindestens mit einem klassischen LACP basiertem Teaming lässt sich das hier im Dauerbetrieb auf Cisco Nexus Switches wie auch Catalyst 9k im Stackwise Virtual Stack und ICX 7850 im HW Stack nicht nachvollziehen oder irgendwie reproduzieren.
Dort sind sämtliche Logs mit ET Adapter LAGs über Tage völlig unauffällig.
jsysde
jsysde 18.06.2024 um 14:43:08 Uhr
Goto Top
Moin.

Oops, sorry - betrifft sowohl switch-independent als auch LACP-Teams. Eingesetzte Switches reichen von TP-Link, Zyxel über Cisco bis zu Juniper, teils als Virtual Chassis, teils stand-alone. Wie gesagt, auf den Switches sehe ich diese Fehler auch nicht, die tauchen nur auf den Windows-Maschinen auf.

Cheers,
jsysde
MysticFoxDE
MysticFoxDE 18.06.2024 um 15:49:55 Uhr
Goto Top
Moin @jsysde,

Oops, sorry - betrifft sowohl switch-independent als auch LACP-Teams. Eingesetzte Switches reichen von TP-Link, Zyxel über Cisco bis zu Juniper, teils als Virtual Chassis, teils stand-alone. Wie gesagt, auf den Switches sehe ich diese Fehler auch nicht, die tauchen nur auf den Windows-Maschinen auf.

schalte mal testweise VMQ und VMMQ auf den vNIC's der entsprechenden VM's aus.

Respektive, du solltest auf den I350 generell VMQ und SRIOV deaktivieren, da diese NIC's eh nicht mal ansatzweise ausreichend, sowohl VMQ-Queue-Pairs, als auch SRIOV-Queue-Pairs bereitstellen.

Gruss Alex
aqui
aqui 18.06.2024 um 16:27:21 Uhr
Goto Top
die tauchen nur auf den Windows-Maschinen auf.
Wäre ja eigentlich sehr ungewöhnlich. Ein grundsätzlicher LAG Fehler betrifft ja immer beide Seiten?!
jsysde
jsysde 18.06.2024 um 16:49:48 Uhr
Goto Top
Moin.
Zitat von @aqui:
die tauchen nur auf den Windows-Maschinen auf.
Wäre ja eigentlich sehr ungewöhnlich. Ein grundsätzlicher LAG Fehler betrifft ja immer beide Seiten?!
Welcome to my world - ich gucke auch grad blöd aus der Wäsche, weil ich bisher auch immer dachte, dem wäre so.

Cheers,
jsysde
jsysde
jsysde 18.06.2024 um 16:57:01 Uhr
Goto Top
Moin.
Zitat von @MysticFoxDE:
schalte mal testweise VMQ und VMMQ auf den vNIC's der entsprechenden VM's aus.
Gesagt, getan. Einen HyperV-Host leer geräumt, aktuellsten Treiber für die I350 installiert, dann:
Get-NetAdapterVmq | Set-NetAdapterVmq -Enabled:$False
netsh int tcp set global rsc=disabled
Get-NetAdapterRsc | Disable-NetAdapterRSC
Get-VMSwitch | Set-VMSwitch -EnableSoftwareRSC:$False
Get-VM | Get-VMNetworkAdapter | Set-VMNetworkAdapter -VmqWeight 0

Reboot, zwei, drei VMs zurück auf diesen Host - Fehler ist der gleiche. Monitoring schimpft, netstat -e zählt hoch.

[...]Respektive, du solltest auf den I350 generell VMQ und SRIOV deaktivieren
SR-IOV war da noch nie aktiv.

Der Witz dabei: Auf einem HyperV-Host sehe ich die Fehler auf einem LACP-Team, dessen VMSwitch _NICHT!_ im Management-OS auftaucht. Auf nem anderen HyperV-Host ist nur das LACP-Team betroffen, dass ausschließlich für da Management-OS genutzt wird, also gar kein VMSwitch dran gebunden ist.

Und nach wie vor sind die Switch-Interfaces alle sauber, da wird nicht ein einziger Error gezählt.
Bin grad völlig ratlos.

Cheers,
jsysde
jsysde
jsysde 18.06.2024 um 17:01:15 Uhr
Goto Top
Nachtrag:
Der größte Witz - es funktioniert alles, wir haben NULL Probleme im täglichen Betrieb.

Es ist nur CheckMK, das seit dem Update immer wieder Warnungen oder Alarme ausgibt. Wobei wir hier über Errors im Promille-Bereich reden:
screenshot 2024-06-18 170012
screenshot 2024-06-18 170028

Cheers,
jsysde
jsysde
jsysde 19.06.2024 um 09:30:41 Uhr
Goto Top
Moin.

Die gestern gemachten Anpassungen haben das "Problem" nicht verbessert, sondern im Gegenteil, verschlimmert. Ich sehe jetzt deutlich mehr Warnungen/Alarme als vor den Anpassungen.

Frage in die Runde:
Das es mit Intel X-<nnn> NICs keinerlei Probleme gibt - welchen Unterschied zu den I350-/ET-Adaptern habe ich übersehen?

Cheers,
jsysde
MysticFoxDE
MysticFoxDE 20.06.2024 um 07:56:43 Uhr
Goto Top
Moin @jsysde,

Die gestern gemachten Anpassungen haben das "Problem" nicht verbessert, sondern im Gegenteil, verschlimmert. Ich sehe jetzt deutlich mehr Warnungen/Alarme als vor den Anpassungen.

sorry, dass ich jetzt erst antworte, ich sitze diese Woche jedoch selber an einem ähnlichen Problem dran und zwar mit DELL Enterprise Hardware und Broadcom NIC's. 🤮

Frage in die Runde:
Das es mit Intel X-<nnn> NICs keinerlei Probleme gibt - welchen Unterschied zu den I350-/ET-Adaptern habe ich übersehen?

Die I350er unterscheiden sich in machen Dingen schon extrem von den X5xx oder gar X7xx oder X8xx Adaptern, vor allem im Bereich der Virtualisierungs-Features. Bei 1G benötigst du diese aber nicht wirklich.

Deine Probleme kommen höchstwahrscheinlich durch eine Fehlkonfiguration zustande, aber keine Sorge, nicht durch dich verursacht, sondern entweder durch Intel oder höchstwahrscheinlich eher durch MS.

Ich komme am WE wieder zurück, dann kann ich mir dein Problem auch etwas genauer anschauen.

Gruss Alex
aqui
aqui 08.07.2024 um 09:51:22 Uhr
Goto Top
Wenn es das denn nun war bitte dann auch nicht vergessen deinen Thread hier als erledigt zu schliessen!
Wie kann ich einen Beitrag als gelöst markieren?