In meinem Homelab hatte ich vor einigen Wochen Tanzu mit NSX-T aktiviert. Nach einigen Hürden in der Planungsphase funktionierte die Konfiguration und auch das Nord-Süd Routing funktionierte tadellos. Die Edge-Nodes peerten über BGP mit dem physischen Router und machten die Routen in neue Segmente dort bekannt, so dass sie ohne weitere Konfiguratiom im Router sofort verfügbar waren.
Eine Besonderheit, die mein Lab von einer Produktivumgebung unterscheidet, ist dass es nicht 24/7 durchläuft. D.h. nach getaner Arbeit wird der gesamte Cluster herunter gefahren und die Anlage abgeschaltet. Schließlich verursacht ein Cluster im Leerlauf viel Lärm und verbraucht unnötig Energie.
Kürzlich startete ich das Lab neu und musste feststellen, daß aus den NSX Segmenten kein Kontakt zum Router oder DNS Server möglich war. Ein Fall fürs Troubleshooting.
Zunächst prüfte ich die Geneve-Tunnel zwischen den Transport-Nodes. Hier war alles in Ordnung und jeder Transport-Node konnte mit jedem anderen kommunizieren. Die Ursache wurde schnell in den Edge-Nodes lokalisiert. Ein Reboot der Edges oder ein vMotion auf einen anderen Host brachten keine Verbesserung.
Die Edges waren nicht komplett offline. Über das Management-Network waren sie administrierbar. Traceroute funktionierte über T1 und T0 Servicerouter bis zum Fastpath Interface fp-eth0. Ab dort wurde kein Paket weitergeleitet.
Das Interface fp-eth0 ist mit der verteilten Portgruppe Edge-Trunk auf vSwitch VDS-NSX verbunden. Ein Kontrollblick im vSphere-Client zeigte schnell, dass die Uplink Ports der Edges blockiert waren. Nicht im Status “down”, sondern geblockt.
Einen Kunden würde ich an dieser Stelle fragen, was er verändert habe. Ich bin mir aber sehr sicher, keine Veränderung am System oder der Konfiguration gemacht zu haben. Ja, das sagen sie alle 😉
Scotty, unblock me!
Zum Glück fand ich nach einigen Suchanfragen einen VMware KB Artikel, der das Phänomen beschreibt. Die Erklärung der Ursache passte zwar nicht präzise auf mein Szenario, jedoch war die Anleitung zum entsperren zielführend. Es gibt einen zweiten KB Artikel 66796, der eher zutreffend ist, wenn auch nur für NSX-T Versionen vor 2.4.1, welche ich nicht verwende.
Zunächst verbinden wir uns per SSH mit einem Transport-Node (esx01), auf dem eine Edge-Node VM registriert ist.
[root@esx01:~] net-dvs -l | grep -E "port |port.block|volatile.vlan|volatile.status"
Die Ausgabe kann je nach Umgebung eine längere Liste sein. Der folgende Ausschnitt und Screenshot zeigt den wichtigen Abschnitt.
port 49fe0adb-2ab4-471b-9b81-12119b46f7f2:
com.vmware.common.port.volatile.status = inUse linkUp blocked portID=100663332 Port blocked by admin propType = RUNTIME
Im nächsten Schritt müssen wir die Portnummer 100663332 zuordnen. Hier ist de Benennung leider nicht durchgehend eindeutig. In der Ausgabe wird die Portnummer PortID genannt, in der nächsten Abfrage jedoch PortNum. Die PortUUID 49fe0adb-2ab4-471b-9b81-12119b46f7f2 wurde in der ersten Ausgabe genannt, aber wir werden diese später nochmals ermitteln.
[root@esx01:~] net-stats -l
Die Portnummer 100663332 passt zu dem geblockten Port eth1 der VM edge01 (interner Name: fp-eth0). Falls der VDS mit der Portgruppe nicht bekannt sein sollte kann er mit folgendem Befehl abgefragt werden. Wir ermitteln somit auch gleich die PortUUID, die hier DVPort ID genannt wird.
[root@esx01:~] esxcfg-vswitch -l
Der DVS Name lautet VDS-NSX und die PortUUID ist 49fe0adb-2ab4-471b-9b81-12119b46f7f2. Damit haben wir die notwendige Info, um die Ports zu entsperren. Der Befehl lautet allgemein:
net-dvs -s com.vmware.common.port.block=false <VDS-Name> -p <PortUUID>
net-dvs -s com.vmware.common.port.block=false VDS-NSX -p 49fe0adb-2ab4-471b-9b81-12119b46f7f2
Das Ergebnis kann sofort im vSphere-Client überprüft werden. Ggf. ist dafür ein Refresh nötig.
Auch im NSX-T Manager ist der Port fp-eth0 jetzt als “Up” markiert.
Die obige Prozedur wurde für VM edge02 wiederholt. Danach war auch dessen Port im vSphere-Client wieder online.
Im NSX-T Manager hatte sich die Situation nicht sofort erholt. Erst nach einem vMotion der Edge-VMs gingen dort alle Lampen auf grün. Möglicherweise war ich auch etwas zu ungeduldig.
Auch die vier Transport-Nodes sind wieder komplett im Status “grün”.
