5
Switch vervielfacht Ethernet-Frames von und an ESX-Server
Hallo Forum,
ich habe folgendes Problem:
Nach einem Upgrade auf ESX3.5 wird jedes Ethernet-Frame so oft wie Interfaces im Etherchannel vorhanden sind weitergeleitet. Es sind mehrere Etherchannel mit je 4 Ports an einem Cisco 37xx Switch angelegt. An diesen 4 Ports hängen je 4 Ports eines ESX-Servers an 2 Netzwerkkarten. Die beiden Onboard Interfaces sind wieder in einem eigenem Etherchannel an den Switch angebunden. Der switch selbst hat 4 4-Port und 4 2-Port Channel für die ESX-Server, diese sind als Trunk ohne Pruning aktiviert. Kapselung ist dot1q, channeling erfolgt ohne Protokoll (etherchannel xx mode on). Das Loadbalancing ist src-dst-ip, am ESX ip-hash. Wie vorher auch. Es sind ca. 15 VLANS angelegt, diese werden über die 4-Port Etherchannel an den ESX für die VM's durchgereicht. Pingt man nun eine VM, die Serviceconsole oder das VMKernelinterface an, bekommt man 1 Reply und 3 duplications, in einem 2-port channel 1 reply und 1 duplication. Startet man Wireshark oder tcpdump, kann man sehr gut sehen das JEDES Ethernet-Frame so oft wie Interfaces im Channel sind ankommt. Mit ESX3.02 hat alles normal funktioniert. VMWare selbst schiebt das Problem auf Cisco, Cisco auf VMWare. Quelle der Packetdups ist immer der Switch. Seltsam.
Hat jemand das selbe Verhalten schon einmal beobachtet und evt. sogar gelöst? Ich konfiguriere nun die Uplinks ohne Etherchannel um das Problem zu umgehen. Normalerweise müsste es aber mit funktionieren.
Für leute die nicht gerne lesen:
Die Portgruppen sind im Trunking-Mode mit 802.1q.
Es werden alle VLANs übermittelt, kein Pruning.
Der Switch verwendet src-dst ip basierendes loadbalancing.
Die ESX Hosts verwenden ebenfalls IP Basierendes Loadbalancing.
Es wird kein Link-Aggregation Protokoll im Etherchannel gesprochen.
Die ESX-Server verwenden je 2 zusätzliche 2Port Netzwerkkarten.
Die beiden OnBoard Netzwerkkarten bilden einen weiteren Etherchannel mit der selben Konfiguration für Servicekonsole und vmkernel.
Pingt man eine VM oder die Servicekonsole ODER snifft etwas Traffic auf einer VM merkt man das alle Pakete so oft wie Netzwerkkarten im Etherchannel sind ankommen.
Mit ESX 3.02 hat alles wunderbar funktioniert.
ich habe folgendes Problem:
Nach einem Upgrade auf ESX3.5 wird jedes Ethernet-Frame so oft wie Interfaces im Etherchannel vorhanden sind weitergeleitet. Es sind mehrere Etherchannel mit je 4 Ports an einem Cisco 37xx Switch angelegt. An diesen 4 Ports hängen je 4 Ports eines ESX-Servers an 2 Netzwerkkarten. Die beiden Onboard Interfaces sind wieder in einem eigenem Etherchannel an den Switch angebunden. Der switch selbst hat 4 4-Port und 4 2-Port Channel für die ESX-Server, diese sind als Trunk ohne Pruning aktiviert. Kapselung ist dot1q, channeling erfolgt ohne Protokoll (etherchannel xx mode on). Das Loadbalancing ist src-dst-ip, am ESX ip-hash. Wie vorher auch. Es sind ca. 15 VLANS angelegt, diese werden über die 4-Port Etherchannel an den ESX für die VM's durchgereicht. Pingt man nun eine VM, die Serviceconsole oder das VMKernelinterface an, bekommt man 1 Reply und 3 duplications, in einem 2-port channel 1 reply und 1 duplication. Startet man Wireshark oder tcpdump, kann man sehr gut sehen das JEDES Ethernet-Frame so oft wie Interfaces im Channel sind ankommt. Mit ESX3.02 hat alles normal funktioniert. VMWare selbst schiebt das Problem auf Cisco, Cisco auf VMWare. Quelle der Packetdups ist immer der Switch. Seltsam.
Hat jemand das selbe Verhalten schon einmal beobachtet und evt. sogar gelöst? Ich konfiguriere nun die Uplinks ohne Etherchannel um das Problem zu umgehen. Normalerweise müsste es aber mit funktionieren.
Für leute die nicht gerne lesen:
Anbindung der ESX-Server an den Switch
2x 2Port NIC
[ ] [ ] [ ] [ ] ESX1
| | | |
ETHERCHANNEL1
| | | |
[ ] [ ] [ ] [ ] SWITCH
[ ] [ ] [ ] [ ]
| | | |
ETHERCHANNEL2
| | | |
[ ] [ ] [ ] [ ] ESX2
2x 2Port NICDie Portgruppen sind im Trunking-Mode mit 802.1q.
Es werden alle VLANs übermittelt, kein Pruning.
Der Switch verwendet src-dst ip basierendes loadbalancing.
Die ESX Hosts verwenden ebenfalls IP Basierendes Loadbalancing.
Es wird kein Link-Aggregation Protokoll im Etherchannel gesprochen.
Die ESX-Server verwenden je 2 zusätzliche 2Port Netzwerkkarten.
Die beiden OnBoard Netzwerkkarten bilden einen weiteren Etherchannel mit der selben Konfiguration für Servicekonsole und vmkernel.
Pingt man eine VM oder die Servicekonsole ODER snifft etwas Traffic auf einer VM merkt man das alle Pakete so oft wie Netzwerkkarten im Etherchannel sind ankommen.
Mit ESX 3.02 hat alles wunderbar funktioniert.
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: 82209
Url: https://administrator.de/contentid/82209
Ausgedruckt am: 25.11.2024 um 05:11 Uhr
5 Kommentare
Neuester Kommentar
Nur so als kleiner Tipp: Vielleicht änderst du die Formatierung mal dahin gehend, dass man auch sinnvolle Abschnitte erkennt... :D
Besser? 
hast du nun ähnliches in deinem ESX Cluster bemerkt oder wolltest du mich nur auf die nicht perfekte Bereitstellung von Informationen zu dem Verhalten hinweisen?
hast du nun ähnliches in deinem ESX Cluster bemerkt oder wolltest du mich nur auf die nicht perfekte Bereitstellung von Informationen zu dem Verhalten hinweisen?
Also, ich habe die Etherchannel aufgelöst und die Interfaces laufen nun eigenständig als Trunk. Der ESX scheint die vorhandenen Netzwerkkarten intern irgendwie zu bündeln und trotzdem als einzelnes an den vSwitch zu übergeben. Die konfiguration eines etherchannel auf dem switch scheint bei 3.5 trotz das es so Dokumentiert ist, nicht mehr nötig zu sein. Ich werde das verhalten in den nächsten Tagen einmal unter Vollast beobachten und berichten ob es funktioniert.
Zusammenfassung:
Alle mit ESX-Servern verbundenen Ports am Switch sind eigenständig als Trunk-Port konfiguriert und verwendet dot1q als trunkingprotokoll. Eine aggregierung der Links findet auf seiten des Physischen Switches nicht mehr statt.
Zusammenfassung:
Alle mit ESX-Servern verbundenen Ports am Switch sind eigenständig als Trunk-Port konfiguriert und verwendet dot1q als trunkingprotokoll. Eine aggregierung der Links findet auf seiten des Physischen Switches nicht mehr statt.
Hi,
sorry, mein Beitrag war nicht böse gemeint, ich weiß nur, dass es selten erfolgreiche Kommentare gibt, wenn ein Beitrag nur aus Fließtext besteht, ohne irgendwelche Abschnitte, die Zusammenhänge kennzeichnen.
Zu deinem Problem konkret kann bzw. konnte ich dir leider nichts sagen, soweit bin ich, was ESX und Konsorten angeht, leider noch nicht.
Grüße, kingkong
EDIT: Achja, das Problem scheint ja gelöst zu sein - dann bitte das Topic auf gelöst setzen.
sorry, mein Beitrag war nicht böse gemeint, ich weiß nur, dass es selten erfolgreiche Kommentare gibt, wenn ein Beitrag nur aus Fließtext besteht, ohne irgendwelche Abschnitte, die Zusammenhänge kennzeichnen.
Zu deinem Problem konkret kann bzw. konnte ich dir leider nichts sagen, soweit bin ich, was ESX und Konsorten angeht, leider noch nicht.
Grüße, kingkong
EDIT: Achja, das Problem scheint ja gelöst zu sein - dann bitte das Topic auf gelöst setzen.
Kein Problem. nein, ich wußte schon bevor ich den Beitrag gepostet habe das ich durch auflösen des Channels das "phänomen" wegbekomme. Nur, was mich mehr wundert und warum ich auf Antworten hoffte, in der Doku steht auch bei VI3.5 das ein Channel eingerichtet werden muss. LOL. Entweder ein Fehler in der Doku oder ich habe irgendwas vergessen. Ich lasse des Beitrag noch auf offen, falls jemand das selbe Verhalten hatte/hat. Ich würde schon gern wissen ob ich mal wieder der einzige bin der solche "würmer" baut.
