10
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
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
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 61607054121
Url: https://administrator.de/contentid/61607054121
Ausgedruckt am: 27.09.2024 um 22:09 Uhr
10 Kommentare
Neuester Kommentar
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.
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.
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
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
Moin @jsysde,
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
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
1die tauchen nur auf den Windows-Maschinen auf.
Wäre ja eigentlich sehr ungewöhnlich. Ein grundsätzlicher LAG Fehler betrifft ja immer beide Seiten?!
Moin.
Cheers,
jsysde
Zitat von @aqui:
Welcome to my world - ich gucke auch grad blöd aus der Wäsche, weil ich bisher auch immer dachte, dem wäre so.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?!Cheers,
jsysde
Moin.
Reboot, zwei, drei VMs zurück auf diesen Host - Fehler ist der gleiche. Monitoring schimpft, netstat -e zählt hoch.
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
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:schalte mal testweise VMQ und VMMQ auf den vNIC's der entsprechenden VM's aus.
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 0Reboot, 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
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:
Cheers,
jsysde
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:
Cheers,
jsysde
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
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
Moin @jsysde,
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. 🤮
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
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?
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
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?
Wie kann ich einen Beitrag als gelöst markieren?
