3
HyperV Probleme nach Netzwerkloop
Hallo zusammen,
Folgende Situation:
Durch einen Redundanzlink entstand ein Loop im Netzwerk, der aber von RSTP schnell aufgelöst wurde, sodass die Netzwerkfunktionalität wieder voll gegeben war. Ein angeschlossener Windows Server mit Hyper-V ist dabei komplett eingefroren und hat auf keine Eingaben von Maus/Tastatur reagiert. Nach 5 Minuten hat er sich dann wieder eingekriegt. Soweit so gut.
Auf einem anderen HyperV Failover Cluster (2022) im gleichen Netz laufen einige Win Server-VMs (sämtliche Versionen, teilweise In Place Upgegraded von 2012 auf 2022), die sehr träge reagiert haben. RDP-Verbindungen brauchen bspw. extrem lange und reagierten sehr zäh. Beim Versuch, die betroffenen VMs zu pingen, ging ca. jedes 2-3 Paket ins Leere. Die erfolgreichen Pings brauchten mindestens 20ms. Auch 24 Stunden später zeigte sich das gleiche Verhalten. Nach einem Neustart einer VM war dort alles wieder beim Alten mit Reaktionszeiten <1ms. Die Hypervisor waren jedoch jederzeit bestens erreichbar. Das Netzwerk ist mehr als ausreichend dimensioniert.
Ist dieses Verhalten normal? Kann ein Switching Loop diese Nachwirkungen haben und die gesamte Infrastruktur lahmlegen, auch wenn die Schleife schon lange aufgelöst ist? Mir war das bisher in diesem Ausmaß nicht bekannt.
Danke im Voraus,
Jonas
Folgende Situation:
Durch einen Redundanzlink entstand ein Loop im Netzwerk, der aber von RSTP schnell aufgelöst wurde, sodass die Netzwerkfunktionalität wieder voll gegeben war. Ein angeschlossener Windows Server mit Hyper-V ist dabei komplett eingefroren und hat auf keine Eingaben von Maus/Tastatur reagiert. Nach 5 Minuten hat er sich dann wieder eingekriegt. Soweit so gut.
Auf einem anderen HyperV Failover Cluster (2022) im gleichen Netz laufen einige Win Server-VMs (sämtliche Versionen, teilweise In Place Upgegraded von 2012 auf 2022), die sehr träge reagiert haben. RDP-Verbindungen brauchen bspw. extrem lange und reagierten sehr zäh. Beim Versuch, die betroffenen VMs zu pingen, ging ca. jedes 2-3 Paket ins Leere. Die erfolgreichen Pings brauchten mindestens 20ms. Auch 24 Stunden später zeigte sich das gleiche Verhalten. Nach einem Neustart einer VM war dort alles wieder beim Alten mit Reaktionszeiten <1ms. Die Hypervisor waren jedoch jederzeit bestens erreichbar. Das Netzwerk ist mehr als ausreichend dimensioniert.
Ist dieses Verhalten normal? Kann ein Switching Loop diese Nachwirkungen haben und die gesamte Infrastruktur lahmlegen, auch wenn die Schleife schon lange aufgelöst ist? Mir war das bisher in diesem Ausmaß nicht bekannt.
Danke im Voraus,
Jonas
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: 7716420947
Url: https://administrator.de/contentid/7716420947
Ausgedruckt am: 24.11.2024 um 17:11 Uhr
3 Kommentare
Neuester Kommentar
Moin @jonas48,
ja, das kann dir bei einem Loop schon mal passieren und zwar nicht nur mit Hyper-V sondern auch mit VMware. 😔
Wir booten nach solchen Ereignissen, zur Sicherheit immer die gesamte Serverumgebung einmal komplett durch.
Wer war der Übeltäter?
Beste Grüsse aus BaWü
Alex
Ist dieses Verhalten normal? Kann ein Switching Loop diese Nachwirkungen haben und die gesamte Infrastruktur lahmlegen, auch wenn die Schleife schon lange aufgelöst ist? Mir war das bisher in diesem Ausmaß nicht bekannt.
ja, das kann dir bei einem Loop schon mal passieren und zwar nicht nur mit Hyper-V sondern auch mit VMware. 😔
Wir booten nach solchen Ereignissen, zur Sicherheit immer die gesamte Serverumgebung einmal komplett durch.
Wer war der Übeltäter?
Beste Grüsse aus BaWü
Alex
Danke für die Antwort.
Dass sowas den Hypervisor etwas mitnimmt, kann ich ja noch nachvollziehen. Immerhin machen die virtuellen Switches in HyperV ja auch mit. Und auch ein Client wird durch die vielen ARP-Requests etwas gefordert. Aber wenn der Broadcast-Storm vorbei ist, darf das doch keine Nachwirkungen mehr haben!? Also wie ist das zu erklären? Ich würde das gerne verstehen...
Dann wären ja Protokolle wie RSTP fast überflüssig, wenn eine Schleife zwar aufgelöst wird, aber dennoch die ganze Infrastruktur (zumindest im betroffenen Netz) den Bach runter geht.
Zitat von @MysticFoxDE:
ja, das kann dir bei einem Loop schon mal passieren und zwar nicht nur mit Hyper-V sondern auch mit VMware.😔
Dass sowas den Hypervisor etwas mitnimmt, kann ich ja noch nachvollziehen. Immerhin machen die virtuellen Switches in HyperV ja auch mit. Und auch ein Client wird durch die vielen ARP-Requests etwas gefordert. Aber wenn der Broadcast-Storm vorbei ist, darf das doch keine Nachwirkungen mehr haben!? Also wie ist das zu erklären? Ich würde das gerne verstehen...
Wir booten nach solchen Ereignissen, zur Sicherheit immer die gesamte Serverumgebung einmal komplett durch.
Dann wären ja Protokolle wie RSTP fast überflüssig, wenn eine Schleife zwar aufgelöst wird, aber dennoch die ganze Infrastruktur (zumindest im betroffenen Netz) den Bach runter geht.
Wer war der Übeltäter?
Ich
Moin @jonas48,
100% kann ich es dir nicht erklären, aber ich habe eine Vermutung.
Das SDN des Hyper-V ist je nach dessen Konfiguration zum Teil sehr lastempfindlich, vor allem in der Default Konfiguration und ein Loop ist für einen (v)Switch quasi ein absolutes Horrorszenario.
Schau mal im Ereignislog des entsprechenden Hyper-V's nach, dort sollten eigentlich ein paar Fehler zu finden sein.
Dann wären ja Protokolle wie RSTP fast überflüssig, wenn eine Schleife zwar aufgelöst wird, aber dennoch die ganze Infrastruktur (zumindest im betroffenen Netz) den Bach runter geht.
Wenn die Theorie in der Praxis immer so gut funktionieren würde, hätte ich nicht schon diverseste Male zu den Kunden rausflitzen müssen, um zuerst den Loop zu finden und danach noch zu helfen den Laden IT-technisch wieder zum Laufen zu bringen.
Auch gut ... dann musstest du ja nicht lange suchen. 😁
Mach dir kein Kopf, das passiert früher oder später so gut wie jedem von uns. 🤪
Gruss Alex
Dass sowas den Hypervisor etwas mitnimmt, kann ich ja noch nachvollziehen. Immerhin machen die virtuellen Switches in HyperV ja auch mit. Und auch ein Client wird durch die vielen ARP-Requests etwas gefordert. Aber wenn der Broadcast-Storm vorbei ist, darf das doch keine Nachwirkungen mehr haben!? Also wie ist das zu erklären? Ich würde das gerne verstehen...
100% kann ich es dir nicht erklären, aber ich habe eine Vermutung.
Das SDN des Hyper-V ist je nach dessen Konfiguration zum Teil sehr lastempfindlich, vor allem in der Default Konfiguration und ein Loop ist für einen (v)Switch quasi ein absolutes Horrorszenario.
Schau mal im Ereignislog des entsprechenden Hyper-V's nach, dort sollten eigentlich ein paar Fehler zu finden sein.
Wir booten nach solchen Ereignissen, zur Sicherheit immer die gesamte Serverumgebung einmal komplett durch.
Dann wären ja Protokolle wie RSTP fast überflüssig, wenn eine Schleife zwar aufgelöst wird, aber dennoch die ganze Infrastruktur (zumindest im betroffenen Netz) den Bach runter geht.
Wenn die Theorie in der Praxis immer so gut funktionieren würde, hätte ich nicht schon diverseste Male zu den Kunden rausflitzen müssen, um zuerst den Loop zu finden und danach noch zu helfen den Laden IT-technisch wieder zum Laufen zu bringen.
Wer war der Übeltäter?
Ich Auch gut ... dann musstest du ja nicht lange suchen. 😁
Mach dir kein Kopf, das passiert früher oder später so gut wie jedem von uns. 🤪
Gruss Alex
