Mit einer Reihe von CLI-Befehlen kann ein Operator den Ausführungsstatus verschiedener Elemente des NSX-Routing-Subsystems überprüfen.

Aufgrund des verteilten Charakters des NSX-Routing-Subsystems steht eine Vielzahl von CLIs zur Verfügung, auf die von verschiedenen NSX-Komponenten aus zugegriffen werden kann. Seit der Version NSX 6.2 verfügt NSX auch über eine zentrale CLI, mit der sich die erforderliche Zeitspanne für den Zugriff auf verschiedene verteilte Komponenten und für die Anmeldung bei diesen reduzieren lässt. Die CLI bietet einen Zugriff auf die meisten Informationen von einer einzigen Stelle aus: der NSX Manager-Shell.

Überprüfen der Voraussetzungen

Für jeden ESXi-Host müssen zwei grundlegenden Voraussetzungen erfüllt sein:
  • Jeder logische Switch, der mit dem DLR verbunden ist, befindet sich in einem fehlerfreien Zustand.
  • Der ESXi-Host wurde erfolgreich für VXLAN vorbereitet.

Prüfen des Systemstatus für logische Switches

Das NSX-Routing wird in Verbindung mit logischen NSX-Switches durchgeführt. So überprüfen Sie, ob sich die mit einem DLR verbundenen logischen Switches in einem fehlerfreien Zustand befinden:
  • Ermitteln Sie die Segment-ID (VXLAN VNI) für jeden logischen Switch, der mit dem betreffenden DLR verbunden ist (z. B. 5004..5007).

Status der logischen Switches A, B, C und D mit den Segment-IDs 5004, 5005, 5006 und 5007 in dieser Reihenfolge ist Normal (Grün).

  • Auf den ESXi-Hosts, auf denen die VMs, die von diesem DLR bedient werden, ausgeführt werden, überprüfen Sie den Status der VXLAN-Steuerungskomponente für die logischen Switches, die mit diesem DLR verbunden sind.
# esxcli network vswitch dvs vmware vxlan network list --vds-name=Compute_VDS
VXLAN ID  Multicast IP               Control Plane                        Controller Connection  Port Count  MAC Entry Count  ARP Entry Count
--------  -------------------------  -----------------------------------  ---------------------  ----------  ---------------  ---------------
    5004  N/A (headend replication)  Enabled (multicast proxy,ARP proxy)  192.168.110.201 (up)            2                2                0
    5005  N/A (headend replication)  Enabled (multicast proxy,ARP proxy)  192.168.110.202 (up)            1                0                0
    5006  N/A (headend replication)  Enabled (multicast proxy,ARP proxy)  192.168.110.203 (up)            1                1                0
    5007  N/A (headend replication)  Enabled (multicast proxy,ARP proxy)  192.168.110.202 (up)            1                0                0

Überprüfen Sie die folgenden Elemente für jedes infrage kommende VXLAN:

  • Für logische Switches im Hybrid- oder Unicast-Modus:
    • Die Steuerungskomponente ist aktiviert (Option „Enabled“).
    • Es sind „multicast proxy“ und „ARP proxy“ aufgelistet. „ARP proxy“ wird auch nach der Deaktivierung von IP Discovery aufgeführt.
    • Eine gültige Controller-IP-Adresse ist unter „Controller“ aufgeführt und die Verbindung ist aktiv (Option „up“ unter „Connection“).
  • Die Einstellung für „Port Count“ (Portanzahl) ist korrekt. Sie muss mindestens 1 betragen, auch wenn keine VMs auf diesem Host mit dem betreffenden logischen Switch verbunden sind. Dieser eine Port ist der vdrPort, ein spezieller dvPort, der mit dem Kernelmodul des DLR auf dem ESXi-Host verbunden ist.
  • Mit dem im Folgenden aufgeführten Befehl stellen Sie sicher, dass der vdrPort mit jedem infrage kommenden VXLAN verbunden ist.
~ # esxcli network vswitch dvs vmware vxlan network port list --vds-name=Compute_VDS --vxlan-id=5004
Switch Port ID  VDS Port ID  VMKNIC ID
--------------  -----------  ---------
      50331656  53                   0
      50331650  vdrPort              0


~ # esxcli network vswitch dvs vmware vxlan network port list --vds-name=Compute_VDS --vxlan-id=5005
Switch Port ID  VDS Port ID  VMKNIC ID
--------------  -----------  ---------
      50331650  vdrPort              0
  • Im obigen Beispiel verfügt VXLAN 5004 über eine VM und eine DLR-Verbindung, während VXLAN 5005 nur eine DLR-Verbindung zur Verfügung steht.
  • Überprüfen Sie, ob die erforderlichen VMs korrekt mit ihren entsprechenden VXLANs verbunden sind, z. B. web-sv-01a mit VXLAN 5004
~ # esxcfg-vswitch -l
DVS Name         Num Ports   Used Ports  Configured Ports  MTU     Uplinks
Compute_VDS      1536        10          512               1600    vmnic0

  DVPort ID           In Use      Client
[..skipped..]
  53                  1           web-sv-01a.eth0

Überprüfen der VXLAN-Vorbereitung

Das DLR-Kernelmodul wird als Bestandteil einer VXLAN-Konfiguration auf einem ESXi-Host ebenfalls installiert, konfiguriert und mit einem dvPort auf einem DVS verbunden, der für VXLAN vorbereitet wurde.

  1. Führen Sie show cluster all zum Abrufen der Cluster-ID aus.
  2. Führen Sie show cluster cluster-id zum Abrufen der Host-ID aus.
  3. Führen Sie show logical-router host hostID connection zum Abrufen der Statusinformationen aus.
nsxmgr-01a# show logical-router host <hostID> connection

Connection Information:
-----------------------

DvsName           VdrPort           NumLifs  VdrVmac
-------           -------           -------  -------
Compute_VDS       vdrPort           4        02:50:56:56:44:52
    Teaming Policy: Default Teaming
    Uplink   : dvUplink1(50331650): 00:50:56:eb:41:d7(Team member)


   Stats : Pkt Dropped      Pkt Replaced     Pkt Skipped
   Input : 0                0                1968734458
  Output : 303              7799             31891126
  • Ein mit VXLAN aktivierter DVS verfügt über einen erstellten vdrPort, der von allen DLR-Instanzen auf diesem ESXi-Host gemeinsam genutzt wird.
  • „NumLifs“ (Anzahl der LIFs) bezieht sich auf die Summe der LIFs aller DLR-Instanzen, die auf diesem Host vorhanden sind.
  • Bei „VdrVmac“ handelt es sich um den vMAC, den der DLR an allen LIFs für alle Instanzen verwendet. Dieser MAC ist auf allen Hosts identisch. Dieser wird nicht in Frames, die über das physische Netzwerk außerhalb von ESXi-Hosts geleitet werden, dargestellt.
  • Für jeden dvUplink eines mit VXLAN aktivierten DVS ist ein entsprechender VTEP vorhanden. Ausgenommen sind Fälle, in denen der LACP/Etherchannel-Teammodus verwendet wird, wenn unabhängig von der Anzahl der dvUplinks nur ein VTEP erstellt wird.
    • Der vom DLR weitergeleitete Datenverkehr (SRC MAC = vMAC) ändert nach dem Verlassen des Hosts den SRC MAC in den pMAC des entsprechenden dvUplink.
    • Beachten Sie, dass der Quellport oder Quell-MAC der ursprünglichen VM zur Bestimmung des dvUplink verwendet wird (dieser wird für jedes Paket in den Metadaten seines DVS beibehalten).
    • Sind mehrere VTEPs auf dem Host vorhanden und ein dvUplink schlägt fehl, wird der dem fehlgeschlagenen dvUplink zugeordnete VTEP zu einem der verbleibenden dvUplinks mit allen VMs verschoben, die mit diesem VTEP verbunden sind. Dadurch werden umfangreiche Änderungen der Steuerungskomponente vermieden, die mit dem Verschieben von VMs zu einem anderen VTEP verbunden wären.
  • Die Zahl in „()“ neben jedem „dvUplinkX“ ist die dvPort-Nummer. Dies dient der Paketerfassung auf dem einzelnen Uplink.
  • Die für jeden „dvUplinkX“ angezeigte MAC-Adresse ist ein „pMAC“, der diesem dvUplink zugeordnet ist. Diese MAC-Adresse wird für den Datenverkehr vom DLR aus verwendet, wie z. B. für vom DLR generierte ARP-Abfragen sowie für alle Pakete, die vom DLR nach dem Verlassen des ESXi-Hosts weitergeleitet werden. Diese MAC-Adresse wird auf allen physischen Netzwerken dargestellt (direkt, wenn die LIF des DLR vom Typ „VLAN“ ist, oder innerhalb der VXLAN-Pakete für VXLAN-LIFs).
  • Pkt Dropped/Replaced/Skipped (Paket verworfen/ersetzt/übersprungen) verweist auf Indikatoren, die sich auf interne Implementierungsdetails des DLR beziehen und in der Regel nicht für die Fehlerbehebung oder die Überwachung verwendet werden.