vSwitch teaming policy bei Blade Switches im transparent mod

[pirx]

Hallo,

seit ich auf den distributed vSwitches in unserem neuen Cluster des Health Check aktiviert habe, erhalte ich regelmäßig Warungen, dass etwas mit dem teaming nicht stimmt. Der Alarm verschwindet aber immer nach einer Minute wieder.

Code: Alles auswählen

2013-08-08T23:40:33.853Z [2EC54B90 info 'Vimsvc.ha-eventmgr'] Event 19258 : Teaming configuration in the vSphere Distributed Switch  on host xxxx does not match the physical switch configuration in ha-datacenter. Detail: No loadbalance_ip teaming policy matches
...
2013-08-08T23:41:28.853Z [2EC10B90 info 'Vimsvc.ha-eventmgr'] Event 19261 : Teaming configuration in the vSphere Distributed Switch  on host xxxx matches the physical switch configuration in ha-datacenter. Detail: No loadbalance_ip teaming policy matches


Der neue Cluster nutzt als Hardware IBM Flex Systeme, diese haben 2x LAN und 2x SAN Switches + einige Nodes/Blades. Angebunden sind die LAN SW an die Datacenter Cisco Nexus Switch über einen statischen Portchannel. Die integrierten IBM LAN Switches werden bei uns im transparent mode betrieben, sie leiten also alles mehr oder weniger 1:1 vom Nexus Uplink an die Blades weiter.

Siehe auch die Skizze:



Nun meint der VMware Support die Health Check Fehler kommen von einer falschen Einstellung der teaming policy. Ich nutze auf den vSwitches „Route based on physical NIC load" und VMware hätte gerne das ich auf "Route based on IP hash" umstelle.


Nun habe ich folgendes gefunden:

http://kb.vmware.com/selfservice/micros ... Id=1004048

Code: Alles auswählen

ESX/ESXi running on a blade system does not require IP Hash load balancing if an EtherChannel exists between the blade chassis and upstream switch. This is only required if an EtherChannel exists between the blade and the internal chassis switch, or if the blade is operating in a network pass-through mode with an etherchannel to the upstream switch. For more information on these various scenarios, please contact your blade hardware vendor.


Eigentlich war ich mir sicher das die Einstellung auf dem vSwitch bei uns nicht das Problem sein kann und der erste Abschnitt des Artikel passt auch dazu. Der zweite Abschnitt macht mich aber wieder stutzig mit dem Hinweis auf den "pass-through" mode.

Kann mich jemand erleuchten?

[pirx]

Da ich die letzten 2 Wochen nicht da war und es immer noch unklar ist, möchte ich das Thema noch mal aufwärmen.

Laut VMware KB muss auf den distributed vSwitches die teaming policy auf ip hash eingestellt werden, wenn ein ESXi Host an einem Switch mit portchannel / etherchannel angeschlossen ist (http://kb.vmware.com/kb/1001938).

Bisher konnte ich nicht sicher herausbekommen, ob dies auch gilt, wenn ein ESXi Host als Blade in einem Chassis steckt, in dem z.B.zwei IBM Balde Switches verbaut sind die in einem "transparenten mode" zwischen den Cisco Nexus Datacenter Switches und dem ESXI Host stecken. Ein IBM Switch ist dabei immer mit einem Cisco Switch verbunden und hat 3 Uplinks die als static portchannel konfiguriert sind.

Laut unseren Netzwerkern endet der static portchannel des Cisco Switch am IBM Switch, der ESXi Host sollte davon also nichts mitbekommen. Da es unterschiedliche Switches in den Blade Chassis der Hersteller gibt, bin ich auch nicht sicher ob man das für jeden Typ gleich beantworten kann.

Auf distributed vSwitches verwendet ich immer „Route based on physical NIC load" als policy, wenn das im Fall der Blade Switches falsch wäre, dann müsste der health check doch permanent einen ip hash missmatch melden und nicht immer mal wieder quer über alle ESXi Hosts. Der Fehler wird auch immer innerhalb 60-70 wieder zurückgesetzt und verschwindet.

Ich konnte bisher leider keine eindeutige Doku von IBM zu den Einstellungen auf VMware Seite finden, wenn die IBM Blade Switches im transparenten Mode konfiguriert sind.

[~thc]

Ich finde das Statement von VMWare (Cause) sehr genau:

http://kb.vmware.com/KB/2057667

Daraus würde ich schließen, dass die vmnics in den ESXi-Knoten die Etherchannel-Konfiguration der Nexus-Switches "zu Gesicht bekommen" und sich dann zu Recht beschweren.

[pirx]

Der KB Artikel entstand nach dem ich den CASE bei VMware eröffnet hatte. Davor gab es einen anderen Artikel, der exakt die Fehlermeldung beschrieben hat und dort stand das sie ignoriert werden kann und es zu false positives kommen kann.

Warum der Alarm immer innerhalb von 70 Sekunden wieder verschwindet und es sonst auch keine Auswirkungen gibt (performance, paket drops) ist auch noch ungeklärt.

[~thc]

Der KB Artikel entstand nach dem ich den CASE bei VMware eröffnet hatte. Davor gab es einen anderen Artikel, der exakt die Fehlermeldung beschrieben hat und dort stand das sie ignoriert werden kann und es zu false positives kommen kann.

Warum der Alarm immer innerhalb von 70 Sekunden wieder verschwindet und es sonst auch keine Auswirkungen gibt (performance, paket drops) ist auch noch ungeklärt.

Mit anderen Worten: Keiner weiß irgendwas genaues...

[pirx]

So in etwa.

Würde der Channel zwischen Cisco Nexus und dem ESXi Host existieren, wäre ja alles klar. So habe ich das bei meinem alten Arbeitgeber auch gemacht und die teaming policy musste passen.

Nun sind aber diese Switch in den Blade Chassis zwischen den Nexus SW und den vmnics, und die Blade Switches werden bei uns im easy-connect / transparent mode betrieben. Die Blade SW wurden im dummy mode nach Angaben von IBM konfiguriert. Alles VLANs kommen als trunk am vSwitch an, mehr wollten wir eigentlich auch nicht.

Code: Alles auswählen

EN/CN4093 Easy-Connect (Transparent) Mode
* Allows EN/CN4093 to act as a Fabric Extension Module off a Cisco Network
* Looks like a “dumb” device to Nexus 5K
* No Spanning Tree Protocol (STP) – eliminates Network admin loop concerns
* Provides traffic consolidation in the chassis to minimize ToR port utilization
* Provides intra chassis switching, even in Transparent Mode


Blade Switch Konfig für trans. mode:

Code: Alles auswählen

spanning-tree mode disable
portchannel 1 port ext1-ext10 enable
vnic enable                   # vnic Funktion generell  einschalten
vnic vnicgroup 1           # hier wird  eine Gruppe  1  angelegt
        vlan 4091              # das outer  VLAN tag  für die vnicgroup 
        port inta1-inta14    # die internen Ports zu der  vnicgroup zuordnen
        trunk 1                   # den  trunk  1  =  portchannel  1          zuordnen
        enable                   # aktivieren
        failover                  # failover innerhalb der vnicgroup aktivieren
        exit
write memory


Ich sehe noch nicht, warum der channel bis zum ESXi Host gehen sollte und die hash policy falsch sein sollte, bzw. zwingend ip hash notwendig ist.

So mal kurz umstellen auf dem dvSwitch ist auch nicht möglich, das ändert die policy für alle Hosts. Wenn das nicht passt, dann rumpelts.

[~thc]

Also wenn die Blade switches (wie im IBM-Redbook erläutert) wirklich als voll transparente "Fabric extension" der Nexus-Switches dienen, dann müssen sie auch die Trunking (Etherchannel 802.3ad) Informationen an die vmnics weiterreichen, oder?

Sind denn alle vmnics des dvSwitches physisch so angebunden?

[pirx]

Also wenn die Blade switches (wie im IBM-Redbook erläutert) wirklich als voll transparente "Fabric extension" der Nexus-Switches dienen, dann müssen sie auch die Trunking (Etherchannel 802.3ad) Informationen an die vmnics weiterreichen, oder?

Sind denn alle vmnics des dvSwitches physisch so angebunden?

802.3ad ist ja LACP, das verwenden wir aber nicht. Nur statischen portchannel. Ich blicke da momentan nicht mehr durch. Ich würde aber erwarten, dass es deutlich mehr Probleme geben würde, wenn der hash Algorithmus so falsch auf dem dvSwitch konfiguriert ist. In der Praxis merke ich bis auf den health check alarm nichts. Ich habe am Anfang Durchsatz und failover Tests gemacht, vmnic deaktiviert, die Blade SW deaktiviert. Das hat alles sauber funktioniert.

Gibt es eine Möglichkeit auf dem ESXi Host fest zu stellen, ob ab den vmnics portchannel anliegen? Kann man das mit tcpdump sehen?

[pirx]

Jetzt gibt es endlich ein Information von IBM, die Blades sehen nix vom Channel und es muss nicht die ip hash policy verwendet werden. Mal sehen was VMware als nächstes zu den Health Check errors sag.

[pirx]

Nach Monaten in denen es von VMware immer hieß, ich verwende die falsche teaming policy, bekam ich nun die Info, dass es sich um ein bekanntes Problem handelt. Es soll in einem Update behoben werden, bis dahin soll ich die teaming Option im vSwitch Health Check deaktivieren.