PING Gast <-> Host nicht möglich

[Willi]

Also an der Verkabelung kann ich Nichts problematisches feststellen. Das Ganze ist ein DELL FX2s Chassis mit aktuell 3 Einschüben. Deshalb ja auch 3 ESXi. Das Chassis hat 2 eingebaute kleine Switche die im sogenannten VLT-Mode arbeiten und der automatisch konfiguriert wurde. irix kann sich vielleicht noch daran erinnern

Die beiden Module haben jeweils 4 externe Ports die folgendermassen gesteckt sind:

der erste des oberen Moduls steckt im ersten des unteren Moduls. Beide Ports sind im Portchannel 127
die nächsten beiden jewils (also ingesamt 4) sind am großen externen Switch verbunden. Diese 4 Ports sind sowohl bei den kleinen Modulen als auch am großen Switch auf Portchannel 128 konfiguriert. Sonst ist kein Port in diesem Channel. die letzen Ports jeweils sind leer der Module.

Für mich sieht die Verkabelung okay aus.

[JustMe]

Sorry, aber dann muss ich mich aus der Geschichte zurueckziehen...

Auf jeden Fall ist sicher, dass, wenn die erwaehnten Portchannel in Richtung der ESXi-Server gehen und nicht zur Verbindung von Switch-Modulen genutzt werden sollten, eine passende Konfiguration auf seiten der ESXi-Hosts zwingend vorzunehmen ist. Das (Default-)Load-Balancing der vSwitch-Uplinks folgt gaenzlich anderen Regeln.

[~thc]

PortChannel/Link Aggregation: https://kb.vmware.com/s/article/1001938

[Willi]

Danke, aber meines Verständnisses nach müsste das passen, oder?

[Willi]

Einen Unterschied habe ich jetzt gefunden. Ich habe als Lastenausgleich "Anhand des ursprünglichen virtuellen Ports routen" stehen und nicht das mit dem IP-Hash. Ich bin mir jetzt aber unsicher ob ich das einfach mal umstellen kann.

[Willi]

… wenn die erwaehnten Portchannel in Richtung der ESXi-Server gehen und nicht zur Verbindung von Switch-Modulen genutzt werden sollten,....

Das verstehe ich leider nicht

[JustMe]

Ich kenne halt leider diese Dell Hyper-Converged Appliance nicht.
Du erwaehntest weiter oben "kleine Switche", "Module", "Portchannel an Modulen" usw., und da hast Du dann mich verloren

Auf jeden Fall ist das Umstellen bzgl. IP-Hash nicht "automatisch" richtig bei Link Aggregation (OK, meistens schon...), sondern haengt eben von der Konfiguration des physischen Switches ab.

Was ich aber vorher ansprach war: Wenn die erwaehnten Portchannel nur der Verbindung der "kleinen Switche" dienen wuerden, und nicht auf Ports konfiguriert sind, mit denen die physischen NICs der Host-Einschuebe verbunden sind, dann waere das ja in Bezug auf die Konfiguration der ESXi voellig egal. Im umgekehrten Fall (also Portchannel auf Ports, an denen ESXi-Hosts haengen) muss der ESXi eben entsprechend konfiguriert sein. Ich hoffe, so wird's verstaendlicher...

[Willi]

Ah, jetzt verstehe ich. Danke.

Diese kleinen Switche sind die IO-Module im Chassis mit "internen" Ports an denen automatisch die Einschübe angeschlossen sind und "externe" Ports die dann an die weitere Infrastruktur (meistens ja auch Switche) gehen. Insofern trifft es wohl zu das diese Ports von der Konfiguration her egal sind.

Die internen Ports sind im VLT-Modus automatisch konfiguriert und laut Beschreibung auch zum Teaming eingerichtet. Das weiß irix sicher sehr gut. Vielleicht meldet er sich ja nochmal

[~thc]

Damit

"Anhand des ursprünglichen virtuellen Ports routen"

und einer möglichen Link Aggregation auf dem pSwitch liegt schon mal eine mögliche Fehlerquelle vor, die dazu führen kann, dass eine VM beim einfachen herunterfahren und wieder starten eine neue Port-ID und eine neuen physischen Uplink zugewiesen bekommt und genau zu dem Phänomen führt.

[Willi]

Okay, danke. Dann werde ich mal schauen ob ich morgen dazu komme das mal zu testen. Ich werde definitiv berichten. Danke.

[Willi]

Also ich habe auf dem einen ESXi jetzt mal die beiden beteiligten vSwitche umgestellt auf die IP-Hash Methode und eine VM aus der PG am vSwitch 1 rebootet. Das hat die Lage leider noch verschlimmert. Ich hatte zu keiner der VMs auf dem vSwitch0 mehr Verbindung und zum ESXi auch nur sehr lückenhafte PINGs. Oder hätte ich alle VMs und den ESXi neustarten müssen?

[~thc]

Ich hatte deswegen weiter oben den Link zum Knowledge Base Artikel gepostet, damit du genau überprüfen kannst, ob alle Voraussetzungen gegeben sind und wie man das genau machen muss.

Port Aggregation ist IMHO nichts, was man mal "eben so" umstellt und ausprobiert.

[Willi]

Ja, den habe ich auch gesehen Und ich denke auch das das alles passt. Zumindest von der Theorie her.

Ich weiß jetzt nicht ob Du die DELL-Hardware kennst. Deshalb kurz: In dem Chassis sind 2 kleine Switch-Module verbaut die interne Ports (Server-Side) und externe Ports haben. Die internen Ports sind in dem VLT-Modus in einem Autolag-Modus und soweit ich das verstanden habe sorgt der selber dafür das hier der Portchannel korrekt erkannt wird. Dann wäre alle Punkte erfüllt da der VLT-Modus hier auch wie ein Stack fungiert in der Frage.

Aber je mehr ich darüber nachdenke beschleicht mich das Gefühl das wir an anderer Stelle ein Problem haben. Nehmen wir als Beispiel einen der Einschübe. Dieser Einschub hat 2 Netzwerkkarten die partitioniert sind. Und zwar ist jede in in 4 Partitionen geteilt:

- nic0
- nic1
- nic2
- nic3

Dabei sind dann die beiden nic0 zum vSwitch0 zusammengefasst und die beiden nic1 zu vSwitch1. Aber aus den restlichen 4 nics (nic2.1, nic2.2, nic3.1, nic3.2) werden jeweils ein vSwitch für iSCSI gebildet. Die bilden also kein Teaming (iSCSI hat ja eigenes Failover und Loadbalancing) und werden also deshalb auch nicht in einem LAG zusammen gefasst. Stört das eventuell das Teaming da es ja dieselbe Hardware-NIC ist?

Ich hoffe das war verständlich erklärt.

[~thc]

Sorry, aber da kann ich dir nicht weiterhelfen . mit diesen DELL-Spezialitäten (VLT, Autolag) kenne ich mich überhaupt nicht aus.

[Willi]

Ich hab's befürchtet. Aber vielen Dank für den Versuch Hat mich ja schon auf andere Spuren gebracht!

[Willi]

So, habe jetzt erstmal einen Case bei DELL aufgemacht. Ich befürchte aber das wird ein Ping-Pong zwischen Dell und VMWare. Mal sehen. Der erste Rat war die Firmware auf den Switch-Modulen upzudaten. Das werde ich mal für Freitag einplanen mit einem kompletten Shutdown da ich aufgrund der PING-Problematik unsicher bin ob der Reboot eines der Module vom anderen korrekt aufgefangen wird.

[Willi]

So, das Update der Firmware der Switches ist erledigt. Ist auch insofern gut gelaufen das der Failover bei den beiden IO-Modulen des Chassis klappt. Ich habe alle VMs und ESXi komplett runter gefahren bei den Updates und dann wieder hoch. Hat gut geklappt.

Aber die Verbindungen zwischen den VMs klappt immer noch nicht.

Ich zeige hier nochmal aufgeklappt die Netzwerk-Konfig der ESXi:

Es geht um die VMs bzw. ESXi in LAN, VM Network und Management Network. Alle Maschinen sind im selben Subnetz 192.168.154.*. Aus LAN auf vSwitch1 kann nur entweder VM Network oder Management Network angepingt werden. Nicht Beide. Und andersrum.

Nach der ganzen Update-Aktion gab es genau eine VM in LAN von der ich in beide anderen Portgruppen pingen konnte. Nachdem ich diese auf einen anderen ESXi verschoben hatte war auch hier das Verhalten wie bei den Anderen.

Um zu sehen ob hier das Teaming Probleme macht habe ich eins der IO-Module runter gefahren. Das andere hat sauber alles übernommen aber das PING-Verhalten innerhalb eines Hosts blieb gleich.

Ich bin jetzt weder auf der Spur das es ein VM-Problem ist. Aufgefallen ist es mir auch erst nach dem Update auf 6.7U1 von 6.5U1. Aber 100%ig wissen das es vorher nicht da war tue ich nicht.

Nachtrag: vMotion ist ein anderes Subnetz

[~thc]

Nimm dir eine physische Maschine außerhalb des ESXi und pinge nacheinander alle VMs und die Management-IP an. Lass dir dann die ARP-Tabelle als Referenz anzeigen (Linux: "arp -n"; Windows : "arp -a").

Prüfe dann auf allen VMs nach einem Ping, ob die ARP-Tabelle der VM die richtigen Ziel-Hardware-Adressen enthält.

[Dayworker]

Mann mann mann, du machst uns die Sache aber auch echt schwer oder hattest du vorher schon irgendwann mal erwähnt, daß der Host von 6.5u1 auf 6.7irgendwas gebracht wurde ???
Hast du noch einen Host mit 6.5u1 zum Gegentesten? Mich würde es nicht sonderlich erstaunen, wenn der 6.7er das Problem ist. Falls sich deine Probleme damit erledigt haben, würde ich nur noch die VCSA-6.7 zusammen mit 6.5er Hosts einsetzen. Der 6.7er scheint etwas vorschnell und ohne ausreichende SW-Test rausgehauen worden zu sein. Letzteres lassen einige haarsträubende Bugs vermuten. Es kann ja wohl nur ein schlechter Scherz sein, daß man von 6.0 auf 6.5 und 6.7 aber nicht von einem durchgepatchten 6.5er auf 6.7 upgraden konnte.

[Willi]

Nimm dir eine physische Maschine außerhalb des ESXi und pinge nacheinander alle VMs und die Management-IP an. Lass dir dann die ARP-Tabelle als Referenz anzeigen (Linux: "arp -n"; Windows : "arp -a").

Prüfe dann auf allen VMs nach einem Ping, ob die ARP-Tabelle der VM die richtigen Ziel-Hardware-Adressen enthält.

Mache ich wenn ich im Büro bin. Danke.

Mann mann mann, du machst uns die Sache aber auch echt schwer oder hattest du vorher schon irgendwann mal erwähnt, daß der Host von 6.5u1 auf 6.7irgendwas gebracht wurde ???

Sorry, das ist mir echt durchgerutscht Ich gelobe Besserung.

Hast du noch einen Host mit 6.5u1 zum Gegentesten? Mich würde es nicht sonderlich erstaunen, wenn der 6.7er das Problem ist. Falls sich deine Probleme damit erledigt haben, würde ich nur noch die VCSA-6.7 zusammen mit 6.5er Hosts einsetzen. Der 6.7er scheint etwas vorschnell und ohne ausreichende SW-Test rausgehauen worden zu sein. Letzteres lassen einige haarsträubende Bugs vermuten. Es kann ja wohl nur ein schlechter Scherz sein, daß man von 6.0 auf 6.5 und 6.7 aber nicht von einem durchgepatchten 6.5er auf 6.7 upgraden konnte.

Also der Upgrade hat gut geklappt. Aber einen 6.5U1 habe ich leider nicht mehr.

Ich will auch bei VM einen Case aufmachen aber das muss ich wohl über unseren Provider machen da ich mit meiner ID für ESXi keinen Case öffnen kann.

[Willi]

Also die Arp-Tabelle hat meiner Meinung nach keine Auffälligkeiten. Das passt soweit.

[~thc]

Auch in den VMs, bei denen ein Ping fehlschlägt?

[Willi]

Also "von aussen" funktioniert er ja überall hin . Wenn ich intern einen PING mache der nicht geht ist der Eintrag in der Arp-Tabelle gar nicht da.

[~thc]

Aber das ist ja das Interessante.

Wenn z.B. Linux einen anderen Host erreichen und einen nicht erreichen kann, sollte das in der ARP-Tabelle so aussehen:

Code: Alles auswählen

192.168.xx.5            ether   00:xx:yy:aa:bb:cc   C                     eno1
192.168.xx.3                    (incomplete)                              eno1

[Willi]

Linux habe ich hier leider nicht zur Hand. Aber sowohl auf dem ESXi-Host als auch auf der Windows-Maschine sind die ARP-Einträge eines nicht funktionierenden Pings einfach nicht da.