Fehlerbehebung bei ACI VMM-Integration

Einleitung

In diesem Dokument werden die Schritte zum Verständnis und zur Fehlerbehebung bei der ACI Virtual Machine Manager Integration (VMM) beschrieben.

Hintergrundinformationen

Das Material aus diesem Dokument wurde aus dem Buch Troubleshooting Cisco Application Centric Infrastructure, Second Edition, extrahiert. Dies betrifft insbesondere die Kapitel VMM Integration - Overview, VMM Integration - vCenter Connectivity, VMM Integration - Host Dynamic Discovery und VMM Integration - Hypervisor Uplink Load Balancing.

Virtual Machine Manager - Überblick

ACI-Controller können in Virtual Machine Manager (VMMs) von Drittanbietern integriert werden.

Dies ist eine der Hauptfunktionen der ACI, da sie die Vorgänge für die End-to-End-Netzwerkkonfiguration der Fabric und der damit verbundenen Workloads vereinfacht und automatisiert. Die ACI bietet ein Modell mit einer einzigen Overlay-Richtlinie, die auf verschiedene Workload-Typen erweitert werden kann, z. B. virtuelle Systeme, Bare-Metal-Server und Container.

In diesem Kapitel werden einige typische Fehlerbehebungsszenarien im Zusammenhang mit der VMware vCenter VMM-Integration behandelt.

Der Leser wird Folgendes erläutern:

• Untersuchung von vCenter-Kommunikationsfehlern.
• Dynamische Erkennungsprozesse und Fehlerszenarien für Host und VM.
• Hypervisor-Lastenausgleichsalgorithmen.

vCenter-Konnektivität

Rollenbasierte Zugriffskontrolle (RBAC)

Die Mechanismen, über die der APIC mit dem vCenter-Controller kommunizieren kann, hängen von dem Benutzerkonto ab, das einer VMM-Domäne zugeordnet ist. Spezifische Anforderungen sind für den vCenter-Benutzer in Verbindung mit der VMM-Domäne festgelegt, um sicherzustellen, dass der APIC Vorgänge in vCenter erfolgreich durchführen kann, unabhängig davon, ob er Bestände und Konfigurationen weiterleitet und abruft oder ob er Ereignisse überwacht, die mit dem verwalteten Bestand zusammenhängen.

Die einfachste Möglichkeit, Bedenken hinsichtlich dieser Anforderungen auszuräumen, besteht darin, das Administrator-vCenter-Konto mit vollem Zugriff zu verwenden. Diese Freiheit steht dem ACI-Administrator jedoch nicht immer zur Verfügung.

Die Mindestberechtigungen für ein benutzerdefiniertes Benutzerkonto sind ab ACI Version 4.2 wie folgt:

• Alarme
  • Der APIC erstellt zwei Alarme für den Ordner. Einer für DVS und einer für die Portgruppe. Wenn die EPG- oder VMM-Domänenrichtlinie auf dem APIC gelöscht wird, wird ein Alarm ausgelöst. vCenter kann jedoch die entsprechende Port-Gruppe oder den DVS nicht löschen, da VMs daran angeschlossen sind.
• Verteilter Switch
• dvPort-Gruppe
• Ordner
• Netzwerk
  • Der APIC verwaltet die Netzwerkeinstellungen wie Hinzufügen oder Löschen von Portgruppen, Festlegen von Host-/DVS-MTU, LLDP/CDP, LACP usw.
• Host
  • Wenn AVS zusätzlich zu den oben genannten verwendet wird, benötigt der Benutzer die Host-Berechtigung für das Rechenzentrum, in dem der APIC DVS erstellt.
  • Host.Configuration.Advanced-Einstellungen
  • Host.Lokale Vorgänge.Virtuelle Maschine neu konfigurieren
  • Host.Configuration.Network-Konfiguration
  • Dies ist für AVS und die Funktion zur automatischen Platzierung für virtuelle Layer-4- bis Layer-7-Service-VMs erforderlich. Für AVS erstellt der APIC eine VMK-Schnittstelle und platziert diese in einer VTEP-Portgruppe, die für OpFlex verwendet wird.
• Virtuelles System
  • Wenn Servicediagramme verwendet werden, ist auch die Berechtigung für virtuelle Systeme für die virtuellen Appliances erforderlich.
  • Virtuelle Maschine.Konfiguration.Geräteeinstellungen ändern
  • Virtuelle Maschine.Konfiguration.Einstellungen

Fehlerbehebung bei RBAC-Problemen

RBAC-Probleme treten meist während der Ersteinrichtung einer VMM-Domäne auf, können aber auftreten, wenn ein vCenter-Administrator die Berechtigungen des Benutzerkontos, das mit der VMM-Domäne verknüpft ist, ändert, nachdem die Ersteinrichtung bereits erfolgt ist.

Das Symptom kann sich wie folgt präsentieren:

• Teilweise oder vollständige Unfähigkeit, neue Dienste bereitzustellen (DVS-Erstellung, Port-Gruppenerstellung, einige Objekte wurden erfolgreich bereitgestellt, aber nicht alle).
• Der betriebliche Bestand ist unvollständig oder fehlt in den ACI-Administratoransichten.
• Fehler, die bei einem nicht unterstützten vCenter-Betrieb oder in einem der oben genannten Szenarien auftreten (z. B. Fehler bei der Port-Gruppen-Bereitstellung).
• Der vCenter-Controller wird als offline gemeldet, und Fehler weisen auf Verbindungs- oder Anmeldeprobleme hin.

Lösung für Probleme im Zusammenhang mit RBAC

Vergewissern Sie sich, dass alle oben genannten Berechtigungen dem vCenter-Benutzer gewährt wurden, der in der VMM-Domäne konfiguriert ist.

Eine weitere Methode besteht darin, sich mit denselben Anmeldeinformationen wie in der VMM-Domänenkonfiguration direkt beim vCenter anzumelden und ähnliche Vorgänge (Erstellung von Portgruppen usw.) auszuführen. Wenn der Benutzer nicht in der Lage ist, diese Vorgänge auszuführen, während er direkt beim vCenter angemeldet ist, werden dem Benutzer eindeutig nicht die richtigen Berechtigungen erteilt.

Verbindungsproblembehebung

Bei der Behebung eines Problems im Zusammenhang mit der VMM-Konnektivität müssen einige der grundlegenden Verhaltensweisen der ACI bei der Kommunikation mit vCenter beachtet werden.

Das erste und relevanteste Verhalten besteht darin, dass nur ein APIC im Cluster die Konfiguration sendet und den Bestand an einem bestimmten Punkt erfasst. Dieser APIC wird als gemeinsamer Marktführer für diese VMM-Domäne bezeichnet. Allerdings überwachen mehrere APICs vCenter-Ereignisse, um ein Szenario zu berücksichtigen, in dem der Leiter der Shared Switches ein Ereignis aus irgendeinem Grund verpasst hat. Entsprechend derselben verteilten Architektur von APICs verfügt eine bestimmte VMM-Domäne über einen APIC, der primäre Daten und Funktionen (in diesem Fall den Shared Leader) verarbeitet, sowie über zwei Replikate (im Fall von VMM werden sie als Follower bezeichnet). Um die Handhabung der VMM-Kommunikation und -Funktionen auf die APICs zu verteilen, können zwei beliebige VMM-Domänen entweder die gleichen oder unterschiedliche gemeinsame Führungskräfte haben.

Der vCenter-Verbindungsstatus kann durch Navigieren zum gewünschten VMM-Controller in der GUI oder durch Verwenden des CLI-Befehls unten ermittelt werden.

VMWare VMM-Domäne - vCenter-Verbindungsstatus

apic2# show vmware domain name VDS_Site1 vcenter 10.48.176.69
Name                         : bdsol-aci37-vc
Type                         : vCenter
Hostname or IP               : 10.48.176.69
Datacenter                   : Site1
DVS Version                  : 6.0
Status                       : online
Last Inventory Sync          : 2019-10-02 09:27:23
Last Event Seen              : 1970-01-01 00:00:00
Username                     : administrator@vsphere.local
Number of ESX Servers        : 2
Number of VMs                : 2
Faults by Severity           : 0, 0, 0, 0
Leader                       : bdsol-aci37-apic1

Managed Hosts:
ESX              VMs       Adjacency   Interfaces
---------------  --------  ----------  ------------------------------------------------
10.48.176.66     1         Direct      leaf-101 eth1/11, leaf-102 eth1/11
10.48.176.67     1         Direct      leaf-301 eth1/11, leaf-302 eth1/11

Wenn ein VMM-Controller als offline angezeigt wird, wird ein Fehler ausgelöst, ähnlich wie im Folgenden:

Fault fltCompCtrlrConnectFailed
Rule ID:130
Explanation:
This fault is raised when the VMM Controller is marked offline. Recovery is in process.
Code: F0130
Message: Connection to VMM controller: hostOrIp with name name in datacenter rootContName in domain: domName is failing repeatedly with error: [remoteErrMsg]. Please verify network connectivity of VMM controller hostOrIp and check VMM controller user credentials are valid.

Mit den folgenden Schritten können Sie Verbindungsprobleme zwischen VC und den APICs beheben.

1. Identifizierung des Anführers

Der erste Schritt bei der Behebung eines Verbindungsproblems zwischen dem APIC und vCenter besteht darin, zu ermitteln, welcher APIC für die jeweilige VMM-Domäne der gemeinsame Marktführer ist. Der einfachste Weg, diese Informationen zu ermitteln, besteht darin, den Befehl "show vmware domain name <domain>" auf einem beliebigen APIC auszuführen.

apic1# show vmware domain name VDS_Site1
Domain Name                        : VDS_Site1
Virtual Switch Mode                : VMware Distributed Switch
Vlan Domain                        : VDS_Site1 (1001-1100)
Physical Interfaces                : leaf-102 eth1/11, leaf-301 eth1/11, leaf-302 eth1/11,
                                   leaf-101 eth1/11
Number of EPGs                     : 2
Faults by Severity                 : 0, 0, 0, 0
LLDP override                      : RX: enabled, TX: enabled
CDP override                       : no
Channel Mode override              : mac-pinning
NetFlow Exporter Policy            : no
Health Monitoring                  : no

vCenters:
Faults: Grouped by severity (Critical, Major, Minor, Warning)
vCenter               Type      Datacenter            Status    ESXs   VMs    Faults
--------------------  --------  --------------------  --------  -----  -----  ---------------
10.48.176.69          vCenter   Site1                 online    2      2      0,0,0,0

APIC Owner:
Controller    APIC      Ownership
------------  --------  ---------------
bdsol-        apic1     Leader
aci37-vc 
bdsol-        apic2     NonLeader
aci37-vc 
bdsol-        apic3     NonLeader
aci37-vc   

2. Überprüfen der Verbindung mit vCenter

Nachdem der APIC identifiziert wurde, der aktiv mit dem vCenter kommuniziert, überprüfen Sie die IP-Verbindung mit Tools wie Ping.

apic1# ping 10.48.176.69
PING 10.48.176.69 (10.48.176.69) 56(84) bytes of data.
64 bytes from 10.48.176.69: icmp_seq=1 ttl=64 time=0.217 ms
64 bytes from 10.48.176.69: icmp_seq=2 ttl=64 time=0.274 ms
64 bytes from 10.48.176.69: icmp_seq=3 ttl=64 time=0.346 ms
64 bytes from 10.48.176.69: icmp_seq=4 ttl=64 time=0.264 ms
64 bytes from 10.48.176.69: icmp_seq=5 ttl=64 time=0.350 ms
^C
--- 10.48.176.69 ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4084ms
rtt min/avg/max/mdev = 0.217/0.290/0.350/0.052 ms

Wenn vCenter mit FQDN anstelle von IP-Adresse konfiguriert wurde, kann der Befehl nslookup verwendet werden, um die Namensauflösung zu überprüfen.

apic1:~> nslookup bdsol-aci37-vc
Server: 10.48.37.150
Address: 10.48.37.150#53
Non-authoritative answer:
Name: bdsol-aci37-vc.cisco.com
Address: 10.48.176.69

3. Überprüfen Sie, ob OOB oder INB verwendet wird

Prüfen Sie in der APIC-Routing-Tabelle, ob Out-of-Band oder In-Band für die Verbindung bevorzugt wird und welches Gateway verwendet wird:

apic1# bash
admin@apic1:~> route
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         10.48.176.1     0.0.0.0         UG    16     0        0 oobmgmt

4. Stellen Sie sicher, dass Port 443 zwischen allen APICs und vCenter zulässig ist, einschließlich aller Firewalls im Kommunikationspfad.

vCenter <-> APIC - HTTPS (TCP-Port 443) - Kommunikation

Die allgemeine HTTPS-Erreichbarkeit von den APICs bis hin zu vCenter kann mit einer Kurve getestet werden:

apic2# curl -v -k https://10.48.176.69
* Rebuilt URL to: https://10.48.176.69/*   Trying 10.48.176.69...
* TCP_NODELAY set
* Connected to 10.48.176.69 (10.48.176.69) port 443 (#0)
...

Überprüfen Sie mithilfe des Befehls netstat, ob die gemeinsame Leitung über eine hergestellte TCP-Verbindung an Port 443 verfügt.

apic1:~> netstat -tulaen | grep 10.48.176.69
tcp 0 0 10.48.176.57:40806 10.48.176.69:443 ESTABLISHED 600 13062800

5. Paketerfassung durchführen

Führen Sie nach Möglichkeit eine Paketerfassung entlang des Pfades zwischen dem gemeinsam genutzten Leader und vCenter durch, um festzustellen, ob Datenverkehr von einem der Geräte gesendet und empfangen wird.

VMware-Bestand

Die nachfolgende Tabelle enthält eine Liste der VMWare VDS-Parameter und gibt an, ob diese vom APIC konfiguriert werden können.

Von APIC verwaltete VMware VDS-Parameter

VMware VDS	Standardwert	Über die Cisco APIC-Richtlinie konfigurierbar?
Name	VMM-Domänenname	Ja (von Domäne abgeleitet)
Beschreibung	Virtueller APIC-Switch	Nein
Ordnername	VMM-Domänenname	Ja (von Domäne abgeleitet)
Version	Höchste Unterstützung durch vCenter	Ja
Discovery-Protokoll	LLDP	Ja
Uplink-Ports und Uplink-Namen	8	Ja (von Cisco APIC Version 4.2(1))
Uplink-Namenspräfix	Aufwärtsstrecke	Ja (von Cisco APIC Version 4.2(1))
Maximale MTU	9000	Ja
LACP-Richtlinie	disabled	Ja
Port-Spiegelung	0 Sitzungen	Ja
Alarme	2 Alarme auf Ordnerebene hinzugefügt	Nein

Die nachfolgende Tabelle enthält eine Liste der VMWare VDS-Portgruppenparameter und gibt an, ob diese vom APIC konfiguriert werden können.

Von APIC verwaltete VMWare VDS-Portgruppenparameter

VMware VDS-Portgruppe	Standardwert	Konfigurierbar mit APIC-Richtlinie
Name	Tenant-Name | Anwendungsprofilname | EPG-Name	Ja (von EPG abgeleitet)
Portbindung	Statische Bindung	Nein
VLAN	Aus VLAN-Pool ausgewählt	Ja
Lastenausgleichsalgorithmus	Abgeleitet von Port-Channel-Richtlinie auf dem APIC	Ja
Promiscuous-Modus	Deaktiviert	Ja
Gefälschte Übertragung	Deaktiviert	Ja
MAC-Änderung	Deaktiviert	Ja
Alle Ports sperren	FALSCH	Nein

VMware-Bestands-Fehlerbehebung

Synchronisierungsereignisse im Bestand stellen sicher, dass der APIC vCenter-Ereignisse erkennt, die eine dynamische Aktualisierung der Richtlinie durch den APIC erforderlich machen. Es gibt zwei Arten von Bestandssynchronisierungen, die zwischen vCenter und dem APIC stattfinden können: eine vollständige Bestandssynchronisierung und eine ereignisbasierte Bestandssynchronisierung. Der Standardzeitplan für eine vollständige Bestandssynchronisierung zwischen dem APIC und vCenter beträgt 24 Stunden, kann jedoch auch manuell ausgelöst werden. Ereignisbasierte Bestandssynchronisierungen sind in der Regel mit ausgelösten Aufgaben wie vMotion verknüpft. Wenn in diesem Szenario ein virtuelles System von einem Host zu einem anderen verschoben wird und diese Hosts mit zwei verschiedenen Leaf-Switches verbunden sind, sucht der APIC nach dem VM-Migrationsereignis und entprogrammiert die EPG im Szenario einer sofortigen On-Demand-Bereitstellung auf dem Quell-Leaf und programmiert die EPG auf dem Ziel-Leaf.

Je nachdem, wie schnell EPGs bereitgestellt werden, die einer VMM-Domäne zugeordnet sind, kann ein fehlendes Abrufen des Bestands aus vCenter unerwünschte Folgen haben. Bei einem fehlgeschlagenen oder teilweisen Bestand wird immer ein Fehler ausgelöst, der auf das Objekt oder die Objekte hinweist, die den Fehler verursacht haben.

Szenario 1 - Virtuelles System mit ungültiger Sicherung:

Wenn ein virtuelles System von einem vCenter in ein anderes verschoben wird oder festgestellt wird, dass das virtuelle System eine ungültige Sicherung aufweist (z. B. eine Portgruppenanbindung an einen alten/gelöschten DVS), wird gemeldet, dass bei der vNIC ein Betriebsproblem vorliegt.

Fault fltCompVNicOperationalIssues
Rule ID:2842
Explanation:
This fault is raised when ACI controller failed to update the properties of a VNIC (e.g., it can not find the EPG that the VNIC attached to).
Code: F2842
Message: Operational issues detected for VNic name on VM name in VMM controller: hostOrIp with name name in datacenter rootContName in domain: domName due to error: issues.
Resolution:
Remediate the virtual machines indicated in the fault by assigning a valid port group on the affected vNIC of the VM.

Szenario 2 - vCenter-Administrator hat ein verwaltetes VMM-Objekt in vCenter geändert:

Das Ändern von Objekten, die vom APIC über vCenter verwaltet werden, wird nicht unterstützt. Der folgende Fehler tritt auf, wenn ein nicht unterstützter Vorgang in vCenter ausgeführt wird.

Fault fltCompCtrlrUnsupportedOperation
Rule ID:133
Explanation:
This fault is raised when deployment of given configuration fails for a Controller.
Code: F0133
Message: Unsupported remote operation on controller: hostOrIp with name name in datacenter rootContName in domain domName detected, error: [deployIssues]
Resolution:
If this scenario is encountered, try to undo the unsupported change in vCenter and then trigger an 'inventory sync' manually.

VMWare VMM-Domäne - vCenter-Controller - Auslösung der Bestandssynchronisierung

VMware DVS-Version

Wenn Sie einen neuen vCenter-Controller als Teil einer VMM-Domäne erstellen, lautet die Standardeinstellung für die DVS-Version "vCenter Default" (vCenter-Standard). Wenn Sie diese Option auswählen, wird die DVS-Version mit der Version von vCenter erstellt.

VMWare VMM-Domäne - Erstellung des vCenter-Controllers

Im Beispiel eines vCenter mit 6.5 und eines ESXi-Servers mit 6.0 erstellt der APIC einen DVS mit Version 6.5. Daher kann der vCenter-Administrator die ESXi-Server mit 6.0 nicht zum ACI-DVS hinzufügen.

Vom APIC verwalteter DVS - Hinzufügen von vCenter-Hosts - leere Liste

APIC-verwalteter DVS - Hinzufügen von vCenter-Hosts - inkompatible Hosts

Wenn Sie also eine VMM-Domäne erstellen, stellen Sie sicher, dass Sie die richtige DVS-Version auswählen, sodass die erforderlichen ESXi-Server zum DVS hinzugefügt werden können.

Dynamische Host-Erkennung

Host-/VM-Erkennungsprozess

Die VMM-Integration in der ACI unterscheidet sich insofern von der manuellen Bereitstellung, als die Fabric dynamisch ermitteln kann, wo Hosts und die entsprechenden virtuellen Systeme verbunden sind, um Richtlinien effizient bereitzustellen. Durch diesen dynamischen Prozess kann die ACI die Auslastung der Hardwareressourcen auf den Leaf-Switches optimieren, da VLANs, SVIs, Zoning-Regeln usw. nur auf Knoten bereitgestellt werden, wenn ein Endpunkt angeschlossen ist, der die Richtlinie erfordert. Der Vorteil für den Netzwerkadministrator in Bezug auf die Benutzerfreundlichkeit besteht darin, dass die ACI VLAN/Richtlinien bereitstellt, über die VMs automatisch eine Verbindung herstellen. Um zu bestimmen, wo Richtlinien bereitgestellt werden müssen, verwendet der APIC Informationen aus mehreren Quellen. Im folgenden Diagramm werden die grundlegenden Schritte des Host-Erkennungsprozesses bei Verwendung einer DVS-basierten VMM-Domäne beschrieben.

VMWare VMM-Domäne - Bereitstellungs-Workflow

Kurz gesagt, die folgenden wichtigen Schritte werden ausgeführt, wenn:

• LLDP oder CDP wird zwischen Hypervisor- und Leaf-Switches ausgetauscht.
• Hosts melden Adjacency-Informationen an vCenter.
• vCenter informiert den APIC über Adjacency-Informationen:
  • Der APIC erkennt den Host über eine Bestandssynchronisierung.
• Der APIC überträgt die Richtlinie an den Leaf-Port:
  • Lesen Sie den Unterabschnitt "Behebungssofortigkeit" in diesem Abschnitt, um diese Bedingungen besser zu verstehen.
• Wenn die vCenter-Adjacency-Informationen verloren gehen, kann der APIC die Richtlinie entfernen.

Wie Sie sehen, spielt CDP/LLDP eine Schlüsselrolle beim Erkennungsprozess, und es ist wichtig, sicherzustellen, dass dies ordnungsgemäß konfiguriert ist und beide Seiten dasselbe Protokoll verwenden.

Fabric LooseNode/Intermediate Switch - Anwendungsfall

Bei einer Bereitstellung mit einem Blade-Chassis und einem dazwischen liegenden Switch zwischen den Leaf-Switches und dem Hypervisor muss der APIC die Adjacency zusammenfügen. In diesem Szenario können mehrere Discovery-Protokolle verwendet werden, da der zwischengeschaltete Switch möglicherweise andere Protokollanforderungen als der Host hat.

In einer Konfiguration mit einem Blade-Server und einem Zwischen-Switch (d. h. Blade-Chassis-Switch) sollte die ACI den Zwischen-Switch erkennen und die dahinter liegenden Hypervisoren zuordnen. Der Zwischen-Switch wird in der ACI als LooseNode oder als "Unmanaged Fabric Node" bezeichnet. Die erkannten LooseNodes können unter "Fabric > Inventory > Fabric Membership > Unmanaged Fabric Nodes" (Fabric > Bestand > Fabric-Mitgliedschaft > Unmanaged Fabric Nodes) angezeigt werden. Wenn der Benutzer in der GUI zu einem dieser Servertypen navigiert, kann er den Pfad vom Leaf zu einem Zwischenswitch zum Host anzeigen.

APIC-Benutzeroberfläche - Unmanaged Fabric Nodes (LooseNodes)

Mit der LLDP- oder CDP-Erkennung kann die ACI die Topologie für solche LooseNodes ermitteln, da der dem Zwischen-Switch nachgeschaltete Hypervisor durch VMM-Integration verwaltet wird und das Leaf selbst über eine Adjacency zum Zwischen-Switch vom Downstream verfügt.

Dieses Konzept wird in der folgenden Abbildung veranschaulicht.

APIC-Benutzeroberfläche - nicht verwalteter Fabric-Knotenpfad

Behebungssofortigkeit

In Szenarien, in denen kritische Services den in VMM integrierten DVS nutzen, z. B. für die Managementverbindung zu vCenter/ESXi, ist es ratsam, die Vorabentscheidungs-Lösungsinstanz zu verwenden. Bei dieser Einstellung wird der Mechanismus der dynamischen Hosterkennung entfernt, und stattdessen werden Richtlinien/VLANs statisch auf den Schnittstellen zum Host programmiert. In dieser Konfiguration werden die VMM-VLANs immer an allen Schnittstellen bereitgestellt, die mit dem AEP verbunden sind, auf den von der VMM-Domäne verwiesen wird. Dadurch wird die Möglichkeit ausgeschlossen, dass ein kritisches VLAN (z. B. die Verwaltung) aufgrund eines Adjacency-Ereignisses, das sich auf das Erkennungsprotokoll bezieht, von einem Port entfernt wird.

Siehe nachfolgendes Diagramm:

Bereitstellungsbeispiel vor der Bereitstellung

Wenn die Vorabbereitstellung für eine EPG in der ACI_VDS1 VMM-Domäne festgelegt wurde, würden VLANs auf den Verbindungen für Server1, aber nicht für Server2 bereitgestellt, da der AEP von Server2 die ACI_VDS1 VMM-Domäne nicht enthält.

So fassen Sie die Einstellungen für die Unmittelbarkeit der Auflösung zusammen:

• On-Demand - Die Richtlinie wird bereitgestellt, wenn eine Adjacency zwischen Leaf und Host und einem mit der Portgruppe verbundenen virtuellen System eingerichtet wird.
• Immediate (Sofort) - Die Richtlinie wird bereitgestellt, wenn eine Adjacency zwischen Leaf und Host hergestellt wird.
• Vorab-Bereitstellung - Die Richtlinie wird auf allen Ports bereitgestellt, die einen AEP mit enthaltener VMM-Domäne verwenden. Eine Adjacency ist nicht erforderlich.

Fehlerbehebungsszenarien

VM kann ARP für das Standard-Gateway nicht auflösen

In diesem Szenario wurde die VMM-Integration konfiguriert, und der DVS wurde dem Hypervisor hinzugefügt, aber das virtuelle System kann ARP für sein Gateway in der ACI nicht auflösen. Damit das virtuelle System über Netzwerkverbindungen verfügt, müssen Sie sicherstellen, dass sich die Adjacency eingerichtet hat und VLANs bereitgestellt sind.

Zunächst kann der Benutzer überprüfen, ob das Leaf den Host erkannt hat, indem er je nach gewähltem Protokoll 'show lldp neighbors' oder 'show cdp neighbors' auf dem Leaf verwendet.

Leaf101# show lldp neighbors
Capability codes:
  (R) Router, (B) Bridge, (T) Telephone, (C) DOCSIS Cable Device
  (W) WLAN Access Point, (P) Repeater, (S) Station, (O) Other
Device ID            Local Intf      Hold-time  Capability  Port ID
bdsol-aci37-apic1     Eth1/1          120                    eth2-1
bdsol-aci37-apic2     Eth1/2          120                    eth2-1
bdsol-aci37-os1       Eth1/11         180        B           0050.565a.55a7
S1P1-Spine201         Eth1/49         120        BR          Eth1/1
S1P1-Spine202         Eth1/50         120        BR          Eth1/1
Total entries displayed: 5

Falls dies aus Gründen der Fehlerbehebung erforderlich ist, kann dies von ESXi-Seite sowohl in der CLI als auch in der GUI validiert werden:

[root@host:~] esxcli network vswitch dvs vmware list
VDS_Site1
   Name: VDS_Site1
 ...
   Uplinks: vmnic7, vmnic6
   VMware Branded: true
   DVPort:
         Client: vmnic6
         DVPortgroup ID: dvportgroup-122
         In Use: true
         Port ID: 0

         Client: vmnic7
         DVPortgroup ID: dvportgroup-122
         In Use: true
         Port ID: 1

[root@host:~] esxcfg-nics  -l
Name    PCI          Driver      Link Speed     Duplex MAC Address       MTU    Description
vmnic6  0000:09:00.0 enic        Up   10000Mbps Full   4c:77:6d:49:cf:30 9000   Cisco Systems Inc Cisco VIC Ethernet NIC
vmnic7  0000:0a:00.0 enic        Up   10000Mbps Full   4c:77:6d:49:cf:31 9000   Cisco Systems Inc Cisco VIC Ethernet NIC

[root@host:~] vim-cmd hostsvc/net/query_networkhint --pnic-name=vmnic6 | grep -A2 "System Name"
               key = "System Name",
               value = "Leaf101"
            }

vCenter-Web-Client - Host - vmnic LLDP/CDP-Adjacency-Details

Wenn die Leaf-LLDP-Adjacency vom ESXi-Host nicht erkannt werden kann, wird dies häufig durch die Verwendung eines Netzwerkadapters verursacht, der so konfiguriert ist, dass er statt des ESXi-Betriebssystems LLDPDUs generiert. Überprüfen Sie, ob auf dem Netzwerkadapter LLDP aktiviert ist und daher alle LLDP-Informationen verwendet werden. Wenn dies der Fall ist, deaktivieren Sie LLDP auf dem Adapter selbst, sodass die Steuerung über die vSwitch-Richtlinie erfolgt.

Ein weiterer Grund kann darin bestehen, dass die Erkennungsprotokolle zwischen Leaf und ESXi-Hypervisor falsch ausgerichtet sind. Vergewissern Sie sich, dass Sie auf beiden Seiten dasselbe Erkennungsprotokoll verwenden.

Um zu überprüfen, ob die CDP-/LLDP-Einstellungen zwischen der ACI und dem DVS in der APIC-Benutzeroberfläche übereinstimmen, navigieren Sie zu Virtual Networking > VMM Domains > VMWare > Policy > vSwitch Policy. Aktivieren Sie nur die LLDP- oder CDP-Richtlinien, da diese sich gegenseitig ausschließen.

APIC-Benutzeroberfläche - VMWare VMM-Domäne - vSwitch-Richtlinie

Gehen Sie in vCenter zu "Networking > VDS > Configure" (Netzwerke > VDS > Konfigurieren).

vCenter-Webclient-Benutzeroberfläche - VDS-Eigenschaften

Korrigieren Sie ggf. die LLDP-/CDP-Einstellungen.

Validieren Sie anschließend, ob der APIC die LLDP/CDP-Nachbarschaft des ESXi-Hosts in der UI unter "Virtual Networking > VMM Domains > VMWare > Policy > Controller > Hypervisor > General" (Virtuelles Netzwerk > VMM-Domänen > Richtlinie > Hypervisor > Allgemein) mit dem Leaf-Switch vergleicht.

APIC-Benutzeroberfläche - VMWare VMM-Domäne - Hypervisor-Details

Wenn hier die erwarteten Werte angezeigt werden, kann der Benutzer überprüfen, ob das VLAN am Port zum Host vorhanden ist.

S1P1-Leaf101# show vlan encap-id 1035

 VLAN Name                             Status    Ports
 ---- -------------------------------- --------- -------------------------------
 12   Ecommerce:Electronics:APP        active    Eth1/11

 VLAN Type  Vlan-mode
 ---- ----- ----------
 12   enet  CE

vCenter/ESXi-Management VMK verbunden mit APIC-gestütztem DVS

In einem Szenario, in dem der vCenter- oder ESXi-Verwaltungsdatenverkehr den integrierten VMM-DVS nutzen muss, muss besonders darauf geachtet werden, dass die Aktivierung der dynamischen Adjacencies und die Aktivierung der erforderlichen VLANs nicht in die Sackgasse führt.

Für vCenter, das normalerweise vor der Konfiguration der VMM-Integration erstellt wird, ist es wichtig, eine physische Domäne und einen statischen Pfad zu verwenden, um sicherzustellen, dass das Encap-VLAN des vCenter-virtuellen Systems immer auf den Leaf-Switches programmiert ist, damit es verwendet werden kann, bevor die VMM-Integration vollständig eingerichtet ist. Es wird empfohlen, diesen statischen Pfad auch nach der Einrichtung der VMM-Integration beizubehalten, um die Verfügbarkeit dieser EPG stets sicherzustellen.

Bei ESXi-Hypervisoren muss gemäß dem "Cisco ACI Virtualization Guide" unter Cisco.com bei der Migration auf den vDS sichergestellt werden, dass die EPG, mit der die VMK-Schnittstelle verbunden wird, mit der Auflösungs-Unmittelbarkeit bereitgestellt wird, die auf "Pre-provision" festgelegt ist. Dadurch wird sichergestellt, dass das VLAN immer auf den Leaf-Switches programmiert ist, ohne dass die ESXi-Hosts mithilfe von LLDP/CDP erkannt werden müssen.

Unbekannte Host-Adjacencies hinter LooseNode

Typische Ursachen für Probleme bei der LooseNode-Erkennung sind:

• CDP/LLDP ist nicht aktiviert.
  • CDP/LLDP muss zwischen dem zwischengeschalteten Switch, den Leaf-Switches und den ESXi-Hosts ausgetauscht werden.
  • Für das Cisco UCS erfolgt dies über eine Netzwerksteuerungsrichtlinie auf der vNIC.
• Eine Änderung der Management-IP des LLDP-/CDP-Nachbarn unterbricht die Verbindung.
  • Das vCenter erkennt die neue Management-IP in der LLDP/CDP-Adjacency, aktualisiert den APIC jedoch nicht.
  • Manuelle Bestandssynchronisierung auslösen, um Probleme zu beheben
• VMM-VLANs werden dem zwischengeschalteten Switch nicht hinzugefügt
  • Der APIC programmiert keine Blade-/Intermediate-Switches von Drittanbietern.
  • Die Cisco UCSM-Integrations-App (ExternalSwitch) ist in Version 4.1(1) verfügbar.
  • VLANs müssen konfiguriert und mit Uplinks, die mit ACI-Leaf-Knoten verbunden sind, sowie Downlinks, die mit Hosts verbunden sind, verbunden werden.

F606391 - Fehlende Adjacencies für den physischen Adapter auf dem Host

Wenn Sie den Fehler unten sehen:

Affected Object: comp/prov-VMware/ctrlr-[DVS-DC1-ACI-LAB]-DVS1/hv-host-104
Fault delegate: [FSM:FAILED]: Get LLDP/CDP adjacency information for the physical adapters on the host: bdsol-aci20-os3 (TASK:ifc:vmmmgr:CompHvGetHpNicAdj)

Überprüfen Sie den Workflow im Abschnitt "Das virtuelle System kann ARP nicht für sein Standard-Gateway auflösen", da CDP/LLDP-Nachbarschaften fehlen. Diese Adjacencies müssen durchgängig überprüft werden.

Hypervisor-Uplink-Lastenausgleich

Wenn Hypervisoren wie ESXi mit einer ACI-Fabric verbunden werden, werden sie in der Regel über mehrere Uplinks verbunden. Es wird empfohlen, einen ESXi-Host mit mindestens zwei Leaf-Switches zu verbinden. Dadurch werden die Auswirkungen von Fehlerszenarien oder Upgrades minimiert.

Um die Nutzung von Uplinks durch die auf einem Hypervisor ausgeführten Workloads zu optimieren, können mit VMware vCenter-Konfigurationen mehrere Load Balancing-Algorithmen für den von VM generierten Datenverkehr zu den Uplinks des Hypervisors konfiguriert werden.

Alle Hypervisoren und die ACI-Fabric müssen mit demselben Load Balancing-Algorithmus konfiguriert sein, um die korrekte Anbindung sicherzustellen. Andernfalls kann es zu unregelmäßigen Datenverkehrsverlusten und Verschiebungen von Endpunkten in der ACI-Fabric kommen.

Dies kann in einer ACI-Fabric durch übermäßige Warnungen wie die folgenden erkannt werden:

F3083 fault
ACI has detected multiple MACs using the same IP address 172.16.202.237.
MACs: Context: 2981888. fvCEps:
uni/tn-BSE_PROD/ap-202_Voice/epg-VLAN202_Voice/cep-00:50:56:9D:55:B2;
uni/tn-BSE_PROD/ap-202_Voice/epg-VLAN202_Voice/cep-00:50:56:9D:B7:01;
or
[F1197][raised][bd-limits-exceeded][major][sys/ctx-[vxlan-2818048]/bd-[vxlan-16252885]/fault-F1197] 
Learning is disabled on BD Ecommerce:BD01

In diesem Kapitel wird die VMware ESXi-Host-Konnektivität mit der ACI behandelt. Dies gilt jedoch für die meisten Hypervisoren.

Rack-Server

Die verschiedenen Verbindungsmöglichkeiten zwischen einem ESXi-Host und einer ACI-Fabric sind in zwei Gruppen unterteilt, die Switch-abhängig und Switch-unabhängig Lastenausgleichsalgorithmen sind.

Switch-unabhängige Lastenausgleichsalgorithmen sind Verbindungsmöglichkeiten, für die keine spezielle Switch-Konfiguration erforderlich ist. Für den Switch-abhängigen Lastenausgleich sind Switch-spezifische Konfigurationen erforderlich.

Überprüfen Sie, ob die vSwitch-Richtlinie mit den Anforderungen der ACI-Zugriffsrichtlinien-Gruppe übereinstimmt (siehe Tabelle unten).

Teaming- und ACI vSwitch-Richtlinie

VMware Teaming- und Failover-Modus	ACI vSwitch-Richtlinie	Beschreibung	ACI-Zugriffsrichtliniengruppe - Port-Channel erforderlich
Routenbasiert auf dem virtuellen Ausgangs-Port	MAC Pinning	Wählen Sie einen Uplink basierend auf den virtuellen Port-IDs auf dem Switch aus. Nachdem der virtuelle Switch einen Uplink für eine virtuelle Maschine oder einen VMKernel-Adapter ausgewählt hat, leitet er Datenverkehr immer über denselben Uplink für diese virtuelle Maschine oder diesen VMKernel-Adapter weiter.	Nein
Routenbasiert auf Quell-MAC-Hash	NA	Wählen Sie einen Uplink basierend auf einem Hash der Quell-MAC-Adresse aus.	NA
Explizite Failover-Reihenfolge	Expliziten Failover-Modus verwenden	Verwenden Sie aus der Liste der aktiven Adapter immer den Uplink höchster Ordnung, der die Failover-Erkennungskriterien erfüllt. Mit dieser Option wird kein tatsächlicher Lastenausgleich durchgeführt.	Nein
Link-Aggregation (LAG) - IP-Hash-basiert	Statischer Kanal - Modus Ein	Wählen Sie einen Uplink basierend auf einem Hash der Quell- und Ziel-IP-Adressen jedes Pakets aus. Bei Nicht-IP-Paketen verwendet der Switch die Daten in diesen Feldern, um den Hash zu berechnen. Für IP-basiertes Teaming muss auf Seiten der ACI ein Port-Channel/VPC mit dem Modus "on" (Ein) konfiguriert werden.	Ja (Kanalmodus auf 'on' eingestellt)
Link-Aggregation (LAG) - LACP	LACP aktiv/passiv	Wählen Sie einen Uplink basierend auf einem ausgewählten Hash aus (20 verschiedene Hash-Optionen sind verfügbar). Für LACP-basiertes Teaming muss auf Seiten der ACI ein Port-Channel/VPC mit aktiviertem LACP konfiguriert werden. Stellen Sie sicher, dass Sie in der ACI eine erweiterte Richtlinie für Verzögerungen erstellen und auf die VSwitch-Richtlinie anwenden.	Ja (Kanalmodus auf 'LACP Active/Passive' eingestellt)
Routenbasiert auf physischer NIC-Last (LBT)	MAC Pinning - Laden physischer NICs	Verfügbar für verteilte Portgruppen oder verteilte Ports. Wählen Sie einen Uplink basierend auf der aktuellen Last der physischen Netzwerkadapter aus, die mit der Portgruppe oder dem Port verbunden sind. Wenn ein Uplink mit 75 Prozent oder mehr 30 Sekunden lang belegt bleibt, verlagert der vSwitch des Hosts einen Teil des Datenverkehrs des virtuellen Systems auf einen physischen Adapter, der über freie Kapazität verfügt.	Nein

Im Screenshot unten wird gezeigt, wie die Port-Channel-Richtlinie im Rahmen der vorhandenen vSwitch-Richtlinie validiert wird.

ACI vSwitch-Richtlinie - Port-Channel-Richtlinie

Hinweis: Eine ausführliche Beschreibung der VMware-Netzwerkfunktionen finden Sie unter vSphere Networking unter https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-D34B1ADD-B8A7-43CD-AA7E-2832A0F7EE76.html

Anwendungsfall der Cisco UCS B-Serie

Bei der Verwendung von Cisco UCS Servern der B-Serie müssen Sie darauf achten, dass diese innerhalb ihres Chassis mit UCS Fabric Interconnects (FIs) verbunden sind, die über kein einheitliches Datenflugzeug verfügen. Dieser Anwendungsfall gilt auch für andere Anbieter mit einer ähnlichen Topologie. Aus diesem Grund kann es einen Unterschied zwischen der Lastverteilungsmethode auf Seiten der ACI-Leaf-Switches und der vSwitch-Seite geben.

Nachfolgend finden Sie eine UCS FI-Topologie mit ACI:

Cisco UCS FI mit ACI-Leaf-Switches - Topologie

Wichtige Punkte:

• Jede Cisco UCS FI verfügt über einen Port-Channel zu den ACI-Leaf-Switches.
• Die UCS FIs sind nur für Heartbeat-Zwecke direkt miteinander verbunden (nicht für Datenflugzeuge verwendet).
• Die vNIC jedes Blade-Servers ist an eine bestimmte UCS-FI gebunden oder verwendet einen Pfad zu einer FI mithilfe von UCS Fabric Failover (Aktiv/Standby).
• Die Verwendung von IP-Hash-Algorithmen auf dem vSwitch des ESXi-Hosts verursacht MAC-Flaps auf den UCS-FIs.

Gehen Sie folgendermaßen vor, um die Konfiguration korrekt durchzuführen:

Wenn MAC Pinning in der Port-Channel-Richtlinie als Teil der vSwitch-Richtlinie in der ACI konfiguriert ist, wird dies als Teaming-Konfiguration der Port-Gruppen auf dem VDS für "Route based on the original virtual port" angezeigt.

ACI - Port-Channel-Richtlinie als Teil der vSwitch-Richtlinie

Die im obigen Beispiel verwendete Port-Channel-Richtlinie wird vom Assistenten automatisch benannt. Daher heißt sie "CDS_lacpLagPol", obwohl der Modus "MAC Pinning" verwendet wird.

VMware vCenter - ACI VDS - Portgruppe - Lastenausgleichseinstellung