22
ESXi massive Pingabrisse, VMs jedoch konstant online
Hallo zusammen,
ich habe das Problem, dass ein ESXi Host (aktueller Patchstand und keine bekannten Hardwareprobleme), wenn man einen Dauerping auf ihn macht, nur jeden 7. Ping zurück gibt. Dieses Muster bleibt über Stunden/Tage bestehen. 6 Verluste, 1 erfolgreich.
Die VMs, die auf dem Host liegen, laufen alle ordnungsgemäß und zeigen keine Ping-Abrisse. Das ist "die Gute Nachricht".
Die Leiden es ESXi machen natürlich auch beim Backup massive Probleme (quasi nicht oder nur eingeschränkt möglich).
... ABER
nun glaube ich, die Ursache gefunden zu haben. Kurz zum Hintergrund: Vor einigen Monaten wurde uns ein Klasse-C Netz zu knapp, daher haben wir auf ein Klasse-B Netz mit der Subnetzmaske 255.255.0.0 umgestellt (jeden Client, jeden Server, jeden sonstigen Host).
Dabei wurde der erwähnte problematische ESXi vergessen - nachdem ich die Subnetzmaske am Gerät von /24 auf /16 (so wie es ein soll) geändert habe, habe ich keine Probleme mehr.
Nun meine Frage: Kann dies tatsächlich die Ursache gewesen sein oder liegt hier ein Zufall vor?
PS: Die Symptome waren immer die selben, unabhängig ob ich mich im selben /24 Subnetz des erwähnten ESXi-Hosts befand oder "außerhalb" (im regulären /16er Netz).
ich habe das Problem, dass ein ESXi Host (aktueller Patchstand und keine bekannten Hardwareprobleme), wenn man einen Dauerping auf ihn macht, nur jeden 7. Ping zurück gibt. Dieses Muster bleibt über Stunden/Tage bestehen. 6 Verluste, 1 erfolgreich.
Die VMs, die auf dem Host liegen, laufen alle ordnungsgemäß und zeigen keine Ping-Abrisse. Das ist "die Gute Nachricht".
Die Leiden es ESXi machen natürlich auch beim Backup massive Probleme (quasi nicht oder nur eingeschränkt möglich).
... ABER
nun glaube ich, die Ursache gefunden zu haben. Kurz zum Hintergrund: Vor einigen Monaten wurde uns ein Klasse-C Netz zu knapp, daher haben wir auf ein Klasse-B Netz mit der Subnetzmaske 255.255.0.0 umgestellt (jeden Client, jeden Server, jeden sonstigen Host).
Dabei wurde der erwähnte problematische ESXi vergessen - nachdem ich die Subnetzmaske am Gerät von /24 auf /16 (so wie es ein soll) geändert habe, habe ich keine Probleme mehr.
Nun meine Frage: Kann dies tatsächlich die Ursache gewesen sein oder liegt hier ein Zufall vor?
PS: Die Symptome waren immer die selben, unabhängig ob ich mich im selben /24 Subnetz des erwähnten ESXi-Hosts befand oder "außerhalb" (im regulären /16er Netz).
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: 313574
Url: https://administrator.de/forum/esxi-massive-pingabrisse-vms-jedoch-konstant-online-313574.html
Ausgedruckt am: 22.12.2024 um 22:12 Uhr
22 Kommentare
Neuester Kommentar
Hallo Phil,
warum baut man ein 24er Netz auf ein 16er um, weil die Adressen knapp werden? Ist doch der beste Grund die Netze neu zu strukturieren
Client
Server
sonst. Devices
Oder eben auch
Abt 1
Abt 2
usw
VG,
Christian
warum baut man ein 24er Netz auf ein 16er um, weil die Adressen knapp werden? Ist doch der beste Grund die Netze neu zu strukturieren
Client
Server
sonst. Devices
Oder eben auch
Abt 1
Abt 2
usw
VG,
Christian
Ich verstehe deine Frage nicht? In einem 24 Netz haben 255 Hosts Platz, in einem 16er Netz ca. 65.000 
Spielt aber auch keine Rolle zu meinem Problem...
Spielt aber auch keine Rolle zu meinem Problem...
Hallo,
Häte der Client von dem gepingt wurde eine zum /24 Netz passende IP?
Häte der Client von dem gepingt wurde eine zum /24 Netz passende IP?
Hi St-Andreas,
teils ja, teils nein, beides gestetet. Selbes Fehlerbild.
teils ja, teils nein, beides gestetet. Selbes Fehlerbild.
Guten Abend...
ich habe das Problem, dass ein ESXi Host (aktueller Patchstand und keine bekannten Hardwareprobleme), wenn man einen Dauerping auf ihn macht, nur jeden 7. Ping zurück gibt. Dieses Muster bleibt über Stunden/Tage bestehen. 6 Verluste, 1 erfolgreich.
Die VMs, die auf dem Host liegen, laufen alle ordnungsgemäß und zeigen keine Ping-Abrisse. Das ist "die Gute Nachricht".
aha..
Die Leiden es ESXi machen natürlich auch beim Backup massive Probleme (quasi nicht oder nur eingeschränkt möglich).
hm...
... ABER
nun glaube ich, die Ursache gefunden zu haben. Kurz zum Hintergrund: Vor einigen Monaten wurde uns ein Klasse-C Netz zu knapp, daher haben wir auf ein Klasse-B Netz mit der Subnetzmaske 255.255.0.0 umgestellt (jeden Client, jeden Server, jeden sonstigen Host).
echt jetzt... für sowas hat man VLan´s
Dabei wurde der erwähnte problematische ESXi vergessen - nachdem ich die Subnetzmaske am Gerät von /24 auf /16 (so wie es ein soll) geändert habe, habe ich keine Probleme mehr.
wie jetzt.. keine Probleme mehr ? und warum dein Post ?
Nun meine Frage: Kann dies tatsächlich die Ursache gewesen sein oder liegt hier ein Zufall vor?
PS: Die Symptome waren immer die selben, unabhängig ob ich mich im selben /24 Subnetz des erwähnten ESXi-Hosts befand oder "außerhalb" (im regulären /16er Netz).
nun.. dein /16er Netz bedeutet aber auch mehr verwaltungsaufand...
hast du schon mal Testweise eine andere Nic getestet ?
Frank
ich habe das Problem, dass ein ESXi Host (aktueller Patchstand und keine bekannten Hardwareprobleme), wenn man einen Dauerping auf ihn macht, nur jeden 7. Ping zurück gibt. Dieses Muster bleibt über Stunden/Tage bestehen. 6 Verluste, 1 erfolgreich.
Die VMs, die auf dem Host liegen, laufen alle ordnungsgemäß und zeigen keine Ping-Abrisse. Das ist "die Gute Nachricht".
Die Leiden es ESXi machen natürlich auch beim Backup massive Probleme (quasi nicht oder nur eingeschränkt möglich).
... ABER
nun glaube ich, die Ursache gefunden zu haben. Kurz zum Hintergrund: Vor einigen Monaten wurde uns ein Klasse-C Netz zu knapp, daher haben wir auf ein Klasse-B Netz mit der Subnetzmaske 255.255.0.0 umgestellt (jeden Client, jeden Server, jeden sonstigen Host).
Dabei wurde der erwähnte problematische ESXi vergessen - nachdem ich die Subnetzmaske am Gerät von /24 auf /16 (so wie es ein soll) geändert habe, habe ich keine Probleme mehr.
Nun meine Frage: Kann dies tatsächlich die Ursache gewesen sein oder liegt hier ein Zufall vor?
PS: Die Symptome waren immer die selben, unabhängig ob ich mich im selben /24 Subnetz des erwähnten ESXi-Hosts befand oder "außerhalb" (im regulären /16er Netz).
hast du schon mal Testweise eine andere Nic getestet ?
Frank
Zitat von @Philzip:
Ich verstehe deine Frage nicht? In einem 24 Netz haben 255 Hosts Platz, in einem 16er Netz ca. 65.000
Spielt aber auch keine Rolle zu meinem Problem...
sach das mal nicht... LAN-Broadcasts können schon zum Problem werden...Ich verstehe deine Frage nicht? In einem 24 Netz haben 255 Hosts Platz, in einem 16er Netz ca. 65.000
Spielt aber auch keine Rolle zu meinem Problem...
Frank
Das kann man sehen wie man will, mit VLANs hätte man imho mehr Verwaltungsaufwand. vom C zum B ist vielleicht die Quick-and-dirty-Lösung, aber es funktioniert. Aber sei's drum, das stammt noch von einem Kollegen vor meiner Zeit, ich habe da nicht mitgemischt.
Andere NIC hab ich natürlich schon getestet, selber Fehler.
1. ZURZEIT keine Probleme
2. Mein Post war keine Info, unten hängt eine Frage dran. Wo liegt das Problem?
Andere NIC hab ich natürlich schon getestet, selber Fehler.
wie jetzt.. keine Probleme mehr ? und warum dein Post ?
1. ZURZEIT keine Probleme
2. Mein Post war keine Info, unten hängt eine Frage dran. Wo liegt das Problem?
Ich tippe auf Zufall.
Und ich sage dir voraus, dass du noch ganz viele solcher "skurrilen" Probleme bekommen wirst wenn deine Hostanzahl weiter wächst im /16 Netz
Und ich sage dir voraus, dass du noch ganz viele solcher "skurrilen" Probleme bekommen wirst wenn deine Hostanzahl weiter wächst im /16 Netz
Mit Vermutungen komme ich auch nicht weiter, ich kann nicht einfach spontan das komplette Netz umschmeißen. Ich brauch etwas, das Sinn ergibt ^^ "Kann schon mal im 16er Netz passieren" ist jetzt nicht besonders hilfreich :/
Naja du bist ja auch etwas knausrig mit Infos.
Was für eine NIC hat der Host verbaut?
Treiber vom Hersteller oder embedded?
Mal andersrum versucht?
Treiber aktuell?
Von wo pingst du den Host an?
Was für Komponenten hängen zwischen dem Absender des Pings und dem Host?
Firmware auf den Netzwek Komponenten aktuell?
Ich könnte noch 100 Fragen aufschreiben aber es läuft grad Fußball
Was für eine NIC hat der Host verbaut?
Treiber vom Hersteller oder embedded?
Mal andersrum versucht?
Treiber aktuell?
Von wo pingst du den Host an?
Was für Komponenten hängen zwischen dem Absender des Pings und dem Host?
Firmware auf den Netzwek Komponenten aktuell?
Ich könnte noch 100 Fragen aufschreiben aber es läuft grad Fußball
Hui, das sind viele Fragen. Folgende kann ich auf die schnelle Beantworten:
PS: Nun ist das Problem wieder da. Während es vorhin einwandfrei lief und jetzt wieder gar nicht (jeder fünfte Ping [exakt!!] kommt durch, der Rest geht verloren) habe ich nur eine Sache gemacht: Das vCenter aktualisiert. Ich vermute, das Problem ist irgendwo - wo auch immer - auf VMware Ebene zu suchen. Ich konnte schon öfter beobachten, wie z.B. das Trennen des Hostes vom vCenter das Problem (temporär) behoben hat. Diesmal klappt das leider auch nicht mehr.
Was bis jetzt immer funktioniert hat (leider aber auch nur temporär) war ein Neustart des Management Networks vom betroffenen ESXi-Host.
Langsam bin ich verzweifelt ^^
Treiber vom Hersteller oder embedded?
vom HerstellerMal andersrum versucht?
noch nichtTreiber aktuell?
JawohlVon wo pingst du den Host an?
Von verschiedenen Servern und Clients innerhalb des NetzesWas für Komponenten hängen zwischen dem Absender des Pings und dem Host?
physisch hängen, wenn ich jetzt mal von vCenter zu ESXi ausgehe, bloß ein Switch dazwischenFirmware auf den Netzwek Komponenten aktuell?
Sollte, müsste ich nochmal prüfenPS: Nun ist das Problem wieder da. Während es vorhin einwandfrei lief und jetzt wieder gar nicht (jeder fünfte Ping [exakt!!] kommt durch, der Rest geht verloren) habe ich nur eine Sache gemacht: Das vCenter aktualisiert. Ich vermute, das Problem ist irgendwo - wo auch immer - auf VMware Ebene zu suchen. Ich konnte schon öfter beobachten, wie z.B. das Trennen des Hostes vom vCenter das Problem (temporär) behoben hat. Diesmal klappt das leider auch nicht mehr.
Was bis jetzt immer funktioniert hat (leider aber auch nur temporär) war ein Neustart des Management Networks vom betroffenen ESXi-Host.
Langsam bin ich verzweifelt ^^
Update: Jetzt ist gerade wieder alles i.O. - ohne, dass ich etwas gemacht habe.
mal ganz davon ab, dass es seit '96 kein Class A / b / C Netze mehr sondern alles CDIR beschrieben wird....
ein /16er Netz ist immer eine schlechte Wahl, Netze sollten immer nach dem Prinzip "so klein wie möglich - so groß wie nötig" designed werden und den Broadcast klein zu halten. Dann gibt es noch ein paar weitere Punkte die zu bedenken sind sind:
Ahjo, das sind alles so Dinge die wie hatten bei einer Umstellung auf ein /22 Netz, aus dem Grund haben wir (mittlerweile) fast wieder komplett aufgelöst und nur noch max. /24er Netze am laufen.
Gruß
@clSchak
ein /16er Netz ist immer eine schlechte Wahl, Netze sollten immer nach dem Prinzip "so klein wie möglich - so groß wie nötig" designed werden und den Broadcast klein zu halten. Dann gibt es noch ein paar weitere Punkte die zu bedenken sind sind:
- diverse VPN Clients kommen mit Netzen >/24 nicht zurecht
- Site2Site VPNs haben, je nach Firewall auch Probleme mit großen Netzen diese sauber zu routen
- keine Priorisierung sauber möglich, dadurch kann es bei VoIP zu Problemen kommen
- Höhere Grundlast bei den Switchen (vor allem aus dem Bereich unter 1.000 EUR z.B. HP2510G usw.)
- keine saubere Trennung der Netze, Server, WLAN usw. sollte (nicht muss) man in separaten Netzen 'halten'
- Management Netze sollte ohnehin getrennt vom restlichen Netz sein
Ahjo, das sind alles so Dinge die wie hatten bei einer Umstellung auf ein /22 Netz, aus dem Grund haben wir (mittlerweile) fast wieder komplett aufgelöst und nur noch max. /24er Netze am laufen.
Gruß
@clSchak
moin...
und ich sach noch:
sach das mal nicht... LAN-Broadcasts können schon zum Problem werden...
Frank
und ich sach noch:
sach das mal nicht... LAN-Broadcasts können schon zum Problem werden...
Frank
Ich vermute jetzt mal, das einfach irgendein Switch auf dem Weg einfach zuviele Pakete im Puffer hat und nun welche löschen muss.
Natürlich könnte auch die NIC einen Schuss haben.
Teste das Ganze mal in ruhigen Stunden, wenn das Netz nicht zu voll ist.
Wie auch alle anderen sagen, ist es nicht die beste Idee gewesen das Netz so zu erweitern, die Broadcastdomäne wird zu groß.
Allerdings ist das von deinen Geräten und dem Traffic abhängig.
Natürlich könnte auch die NIC einen Schuss haben.
Teste das Ganze mal in ruhigen Stunden, wenn das Netz nicht zu voll ist.
Wie auch alle anderen sagen, ist es nicht die beste Idee gewesen das Netz so zu erweitern, die Broadcastdomäne wird zu groß.
Allerdings ist das von deinen Geräten und dem Traffic abhängig.
Moin,
Meine Kristallkugel sagt: Solange Du Deien Infrastruktur nicht üerbdenkst, wirst Du öfter mit solchen Situationen konfrontiert werden. daher rate ich Dir, Dein Netzwerk so zu strukturieren, daß Du mit mehreren /16ern auskommst und durch einen ordentlichn layer-3-Switch die latenzen niedrig hältst.
lks
- Pings reißen nicht ab, das würde nämlich heiten, daß die Pakete unvollständig gesendet werden und die NICs würden oder switche würden Fehler melden. Bei Pings heit das Paketverluste und Verlustrate, um das zu beziffern. (Ich stelle mir mal vor, wie man ein ICMP-Paket solange mirt einem Seitenschneider bearbeitet, bis es reißt.
- Ein /24 auf /16 aufzuziehen, weil die IP-Adressen knapp werden, ist die falsche Methode sein Netzwerk in den Griff zu bekommen. Stell Dir vor, Du hast 30 Mitarbeiter die sich durch Zurufe verständigen. Wenn nun der Platz knapp wird und Du reißt einfach die Wand zum Nachbarbüro ein, damit im neuen Großraumbüro 100 Leute platz haben, bekommst die Du die Leute zwar rein, aber dann wird der Geräuschpegel in dem Großraumbüro deutlich höher und manche "Zurufe" werden verlorengehen. Also: So eine Konstruktion macht man, um nicht mehr Knoten in ein subnet zu bekommen, sondern ggf die Organisation zu vereinfachen. Alles was über 50 Knoten pro broadcast-domain hinausgeht soltle man überdenken, udn bei 100 Knoten sollte man langsam anfangen sich um die Umstrukturierung gedanken zu machen.
- Paketverluste weisen generell auf Hardwarefehler oder Überlastsituationen hin. Daher wäre als erstes zu prüfen, on irgendwo Fehler gemeldet werden (gute switche haben Anzeigen, die rot blinken und interne Zähler, die man auslesen kann). Dann sieht man, ob es segmente gibt, auf denen fehler gemeldet werden. Bei Deinem Fall vermute ich aber eher eine Überlastsituation. Durch die erhöhte Knotenzahl wird es öfter zu Kollisionen kommen und die Switche werden in den store-and-forward-Modus schalten. Dabei meine ich mit Kollision auf dem Koaxkabel, sondern daß mehrere geräte gleichzeitig zu einem Ziel senden wollen und daher ein Teil der Pakete gepuffert oder entsorgt werden muß. Bei Deiner Situation habe ich eher den verdacht, daß die Überlastsituation am ESXi auftritt udn der eher die icmp-echo-Pakete wegwirft als die IP-pakete seiner Guests. genaueres könnte man feststellen, indem man mal einen Netzwerkmonitor vor dem ESXi mitlaufen läßt und schaut, wie der netzwerktraffic ist, wenn es zu diesen paketverlusten kommt.
Meine Kristallkugel sagt: Solange Du Deien Infrastruktur nicht üerbdenkst, wirst Du öfter mit solchen Situationen konfrontiert werden. daher rate ich Dir, Dein Netzwerk so zu strukturieren, daß Du mit mehreren /16ern auskommst und durch einen ordentlichn layer-3-Switch die latenzen niedrig hältst.
lks
Zitat von @Lochkartenstanzer:
Bei Deiner Situation habe ich eher den verdacht, daß die Überlastsituation am ESXi auftritt udn der eher die icmp-echo-Pakete wegwirft als die IP-pakete seiner Guests.
Bei Deiner Situation habe ich eher den verdacht, daß die Überlastsituation am ESXi auftritt udn der eher die icmp-echo-Pakete wegwirft als die IP-pakete seiner Guests.
Jo, das macht mehr Sinn als der Switch die verwirft; obwohl ... es wäre ja der vSwitch
Danke lks,
da das Problem nur äußerst sporadisch und auch immer nur auf einem Host (von 3 ESXi-Servern und diversen anderen Servern), würde es mich wundern, wenn die Last das Problem ist.
Und auch das Muster macht mich stutzig. Es sieht immer gleich aus. Jedes Mal, wenn die "Problemphase" wieder auftritt, sind die Pingverluste und Erfolg immer im selben Verhältnis. Meistens 5-7 Verluste und dann ein erfolgreicher Ping.
Mit euren Argumenten zum /16er Netz habt ihr sicherlich Recht - aber wie schon erwähnt: Das stammt nicht von mir und ich kann das auch nicht auf die schnelle Ändern. Und vor Allem zahlt der Kunde keine was weiß ich wie viele Stunden für eine Vermutung.
Wir bewegen uns hier doch eher in der Mathematik als in der Religion - hier muss sich doch was handfestes finden lassen.
Ich prüfe später mal den Backbone-Switch, an dem der betroffene ESXi hängt.
da das Problem nur äußerst sporadisch und auch immer nur auf einem Host (von 3 ESXi-Servern und diversen anderen Servern), würde es mich wundern, wenn die Last das Problem ist.
Und auch das Muster macht mich stutzig. Es sieht immer gleich aus. Jedes Mal, wenn die "Problemphase" wieder auftritt, sind die Pingverluste und Erfolg immer im selben Verhältnis. Meistens 5-7 Verluste und dann ein erfolgreicher Ping.
Mit euren Argumenten zum /16er Netz habt ihr sicherlich Recht - aber wie schon erwähnt: Das stammt nicht von mir und ich kann das auch nicht auf die schnelle Ändern. Und vor Allem zahlt der Kunde keine was weiß ich wie viele Stunden für eine Vermutung.
Wir bewegen uns hier doch eher in der Mathematik als in der Religion - hier muss sich doch was handfestes finden lassen.
Ich prüfe später mal den Backbone-Switch, an dem der betroffene ESXi hängt.
Zitat von @Philzip:
Wir bewegen uns hier doch eher in der Mathematik als in der Religion - hier muss sich doch was handfestes finden lassen.
Hmm, du machst noch nicht lange IT, oder?Wir bewegen uns hier doch eher in der Mathematik als in der Religion - hier muss sich doch was handfestes finden lassen.
Manchmal ist Weihwasser die einzige Lösung
Wenn die anderen Server keine Problem machen (was du uns hättest ruhig früher sagen dürfen) dann versuche doch mal den Server an einem anderem Switchport.
Die VMs kannst du ja verschieben.
So frisch bin ich nicht in der IT, jedoch hatte ich auch noch nie solche Probleme :D
Das werde ich mal testen. Danke dir!
Das werde ich mal testen. Danke dir!
Zitat von @Deepsys:
Manchmal ist Weihwasser die einzige Lösung
Zitat von @Philzip:
Wir bewegen uns hier doch eher in der Mathematik als in der Religion - hier muss sich doch was handfestes finden lassen.
Hmm, du machst noch nicht lange IT, oder?Wir bewegen uns hier doch eher in der Mathematik als in der Religion - hier muss sich doch was handfestes finden lassen.
Manchmal ist Weihwasser die einzige Lösung
Aber nur in 10L-Eimern, die man dann über die Gerätschaften kippt.
lks
daher haben wir auf ein Klasse-B Netz mit der Subnetzmaske 255.255.0.0 umgestellt
Tödlich und laienhafter Unsinn in so einem Fall.Damit vergrößerst du die Layer 2 Broadcast Domain und erzeugst dir noch weit größere Probleme. Die goldenen Designregel besagt nicht mehr als ca. 150-200 Endgeräte wenn man performate Switchhardware einsetzt. Bei schwachbrüstigen Billigswitches in der Infrastruktur eher noch weniger !
Das Zauberwort heisst hier VLAN Segmentierung oder Segmentierung allgemein.
Alles in einem großen, dummen flachen Netz zu machen ist mehr als gefährlich und zeugt eher von wenig Netzwerk Design Know How...aber egal.
Von dem Unsinn bei IP Netzen von "Klassen" zu reden mal ganz zu schweigen. Das gibt es schon seit über 20 Jahren nicht mehr und ist sowas von tot !!
https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Vermutlich stirbt das aber wohl niemals aus....
Zum Rest ist aj oben schon alles gesagt.
Was deinen Host und die NIC probleme anbedrifft hört sich das eher nach einem Autonegotiation Mismatch an. Sprich die NIC kann Speed oder Duplex Mode nicht richtig negotiaten mit dem Switch.
Da solltest du mal forschen. Zusätzlich aber auch eine sinnvolle Segmentierung in Angriff nehmen !!
