In dem Dokumentationssatz für dieses Produkt wird die Verwendung inklusiver Sprache angestrebt. Für die Zwecke dieses Dokumentationssatzes wird Sprache als „inklusiv“ verstanden, wenn sie keine Diskriminierung aufgrund von Alter, körperlicher und/oder geistiger Behinderung, Geschlechtszugehörigkeit und -identität, ethnischer Identität, sexueller Orientierung, sozioökonomischem Status und Intersektionalität impliziert. Dennoch können in der Dokumentation stilistische Abweichungen von diesem Bemühen auftreten, wenn Text verwendet wird, der in Benutzeroberflächen der Produktsoftware fest codiert ist, auf RFP-Dokumentation basiert oder von einem genannten Drittanbieterprodukt verwendet wird. Hier erfahren Sie mehr darüber, wie Cisco inklusive Sprache verwendet.
Cisco hat dieses Dokument maschinell übersetzen und von einem menschlichen Übersetzer editieren und korrigieren lassen, um unseren Benutzern auf der ganzen Welt Support-Inhalte in ihrer eigenen Sprache zu bieten. Bitte beachten Sie, dass selbst die beste maschinelle Übersetzung nicht so genau ist wie eine von einem professionellen Übersetzer angefertigte. Cisco Systems, Inc. übernimmt keine Haftung für die Richtigkeit dieser Übersetzungen und empfiehlt, immer das englische Originaldokument (siehe bereitgestellter Link) heranzuziehen.
In diesem Dokument werden die Schritte zum Verständnis und zur Fehlerbehebung bei der ACI Virtual Machine Manager Integration (VMM) beschrieben.
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.
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, das auf verschiedene Workload-Typen erweitert werden kann, d. h. auf 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:
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:
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:
Vergewissern Sie sich, dass dem vCenter-Benutzer, der in der VMM-Domäne konfiguriert ist, alle Berechtigungen erteilt wurden.
Eine weitere Methode besteht darin, sich mit denselben Anmeldeinformationen wie in der VMM-Domänenkonfiguration direkt beim vCenter anzumelden und ähnliche Vorgänge (einschließlich der Erstellung von Portgruppen) 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.
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.
Den vCenter-Verbindungsstatus finden Sie, indem Sie zum gewünschten VMM-Controller in der GUI navigieren oder den hier aufgeführten CLI-Befehl verwenden:
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 ähnlicher Fehler ausgelöst:
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 diesen Schritten können Verbindungsprobleme zwischen VC und den APICs behoben werden.
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 die Namensauflösung mit dem Befehl nslookup überprüft werden.
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 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)
...
Stellen Sie mithilfe des Befehls netstat sicher, dass 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.
Diese Tabelle enthält eine Liste der VMWare VDS-Parameter und gibt an, ob diese vom APIC konfiguriert werden können.
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 |
Diese Tabelle enthält eine Liste der VMWare VDS-Portgruppenparameter und gibt an, ob diese vom APIC konfiguriert werden können.
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 |
Synchronisierungsereignisse im Bestand stellen sicher, dass der APIC vCenter-Ereignisse erkennt, die eine dynamische Aktualisierung der Richtlinie durch den APIC erfordern. 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 der vNIC Probleme beim Betrieb hat.
Fault fltCompVNicOperationalIssues
Rule ID:2842
Explanation:
This fault is raised when ACI controller failed to update the properties of a VNIC (for instance, 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. Dieser 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
Wenn Sie einen neuen vCenter-Controller als Teil einer VMM-Domäne erstellen, lautet die Standardeinstellung für die DVS-Version "vCenter Default". 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.
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 und mehr nur dann auf Knoten bereitgestellt werden, wenn ein Endpunkt angeschlossen ist, für den die Richtlinie erforderlich ist. 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. In diesem 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 Schritte sind möglich, wenn:
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.
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 andere Protokollanforderungen als der Host hat.
In einer Konfiguration mit einem Blade-Server und einem zwischengeschalteten Switch (d. h. einem Blade-Chassis-Switch) kann die ACI den zwischengeschalteten 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 angezeigt werden unter Fabric > Inventory > Fabric Membership > Unmanaged Fabric Nodes. 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
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 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:
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 show lldp neighbors oder show cdp neighbors auf dem Leaf je nach gewähltem Protokoll 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.
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 Benutzeroberfläche unter Virtual Networking (Virtuelles Netzwerk) > VMM Domains (VMWare) > Policy (Richtlinie) > Controller (Controller) > Hypervisor (Hypervisor) > General (Allgemein) überwacht.
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
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 vCenter VM Encap-VLAN 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 auf Cisco.com bei der Migration auf den vDS sichergestellt werden, dass die EPG, über die die VMK-Schnittstelle verbunden wird, mit der Auflösungssofortigkeit "Pre-provision" bereitgestellt wird. 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.
Typische Ursachen für Probleme bei der LooseNode-Erkennung sind:
Wenn dieser Fehler angezeigt wird:
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 "VM kann ARP nicht für das Standard-Gateway auflösen", da CDP/LLDP-Nachbarschaften fehlen. Diese Adjacencies können durchgängig verifiziert werden.
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 Hypervisor-Uplinks 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.
Die verschiedenen Verbindungsmöglichkeiten zwischen ESXi-Hosts und der ACI-Fabric sind in zwei Gruppen unterteilt, d. h. Switch-abhängige und Switch-unabhängige Lastverteilungsalgorithmen.
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, wie in dieser Tabelle dargestellt:
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, überträgt der Host-vSwitch einen Teil des Datenverkehrs des virtuellen Systems an einen physischen Adapter, der über freie Kapazität verfügt. |
Nein |
In diesem Screenshot erfahren Sie, wie Sie die Port-Channel-Richtlinie im Rahmen der vorhandenen vSwitch-Richtlinie validieren.
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
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.
Dies ist eine UCS FI-Topologie mit ACI:
Cisco UCS FI mit ACI-Leaf-Switches - Topologie
Wichtige Punkte:
So konfigurieren Sie dies richtig:
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 in diesem Beispiel verwendete Port-Channel-Richtlinie wird vom Assistenten automatisch benannt und heißt daher "CDS_lacpLagPol", obwohl der Modus "MAC Pinning" verwendet wird.
VMware vCenter - ACI VDS - Portgruppe - Lastenausgleichseinstellung
Überarbeitung | Veröffentlichungsdatum | Kommentare |
---|---|---|
2.0 |
16-Aug-2024 |
Formatierung, Stilfragen, DEI-Formulierungen, Header |
1.0 |
05-Aug-2022 |
Erstveröffentlichung |