De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.
Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.
Dit document beschrijft stappen om ACI Virtual Machine Manager Integration (VMM) te begrijpen en problemen op te lossen.
Het materiaal van dit document is afgeleid uit het boek Cisco Application Centric Infrastructure, Second Edition, met name de VMM Integration - Overview, VMM Integration - vCenter Connectivity, VMM Integration - Host Dynamic Discovery en VMM Integration - Hypervisor Uplink Taakverdeling hoofdstukken.
ACI-controllers kunnen integreren met virtuele-machinemanagers (VMM's) van derden.
Dit is een van de belangrijkste functies van ACI omdat het de bewerkingen voor end-to-end netwerkconfiguratie van de stof en de werkbelastingen die er verbinding mee maken, vereenvoudigt en automatiseert. ACI biedt één beleidsmodel voor overlay dat kan worden uitgebreid naar meerdere werklasttypen, dat wil zeggen virtuele machines, bare metal servers en containers.
In dit hoofdstuk wordt specifiek aandacht besteed aan een aantal typische probleemoplossingsscenario's met betrekking tot de VMware vCenter VMM-integratie.
De lezer zal er doorheen lopen:
De mechanismen waarmee APIC kan communiceren met de vCenter-controller zijn afhankelijk van de gebruikersaccount die aan een bepaald VMM-domein is gekoppeld. Er worden specifieke vereisten geschetst voor de vCenter-gebruiker die bij het VMM-domein is aangesloten om ervoor te zorgen dat de APIC met succes bewerkingen op het vCenter kan uitvoeren, of het nu gaat om het doorsturen en ophalen van inventarislijsten en configuraties of het controleren en luisteren naar gebeurtenissen die verband houden met beheerde inventarissen.
De gemakkelijkste manier om zorg over dergelijke vereisten te verwijderen is het gebruik van de administrateur vCenter-account die volledige toegang heeft; dit soort vrijheid is echter niet altijd beschikbaar voor de ACI-beheerder.
De minimumrechten voor een aangepaste gebruikersaccount, vanaf ACI versie 4.2, zijn als volgt:
RBAC-problemen worden het meest aangetroffen tijdens de eerste configuratie van een VMM-domein, maar kunnen worden ondervonden als een vCenter-beheerder de rechten van de gebruikersaccount die aan het VMM-domein is gekoppeld, zou moeten wijzigen nadat de eerste configuratie al heeft plaatsgevonden.
Het symptoom kan zich op deze manieren presenteren:
Controleer of alle rechten zijn verleend aan de vCenter-gebruiker die in het VMM-domein is geconfigureerd.
Een andere methode is om rechtstreeks aan te melden bij vCenter met dezelfde aanmeldingsgegevens als gedefinieerd in de VMM Domain-configuratie en soortgelijke bewerkingen te proberen (inclusief poortgroepcreatie). Als de gebruiker niet in staat is dezelfde bewerkingen uit te voeren terwijl hij rechtstreeks is aangemeld bij het vCenter, is het duidelijk dat de juiste rechten niet aan de gebruiker worden verleend.
Bij het oplossen van problemen met een probleem dat te maken heeft met VMM-connectiviteit, is het belangrijk rekening te houden met een aantal van de fundamentele gedragingen van de manier waarop ACI met vCenter communiceert.
Het eerste en meest relevante gedrag is dat slechts één APIC in het cluster configuratie en inventarisatie op elk gegeven punt verzendt. Dit APIC wordt de gedeelde leider genoemd voor dit VMM-domein. Echter, meerdere APIC's luisteren naar vCenter Events om rekening te houden met een scenario waarbij de gedeelde leider een gebeurtenis om welke reden dan ook miste. Volgens dezelfde gedistribueerde architectuur van APIC's zal een bepaald VMM-domein één APIC hebben dat primaire gegevens en functionaliteit verwerkt (in dit geval de gedeelde leider), en twee replica's (in het geval van VMM worden ze aangeduid als volgers). Om de verwerking van VMM communicatie en functionaliteit over APICs te verdelen, kunnen om het even welke twee VMM Domeinen of het zelfde of een verschillende gedeelde leiders hebben.
De staat van de vCenter-connectiviteit kan worden gevonden door te navigeren naar de VMM-controller van belang in de GUI of door gebruik te maken van de CLI-opdracht die hier wordt vermeld:
VMWare VMM Domain - status van vCenter-connectiviteit
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
Als een VMM-controller offline is, wordt een fout op deze manier geworpen:
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.
Deze stappen kunnen worden gebruikt om problemen met de connectiviteit tussen VC en APIC's op te lossen.
1. Identificatie van de gedeelde leider
De eerste stap in het oplossen van een connectiviteitsprobleem tussen APIC en vCenter is het begrijpen van welke APIC de gedeelde leider is voor het gegeven VMM-domein. De gemakkelijkste manier om deze informatie te bepalen is het bevel uit te voeren toon vmware domeinnaam <domain> op een APIC.
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. Connectiviteit met vCenter verifiëren
Na het identificeren van de APIC die actief communiceert met vCenter, verifieert IP-verbinding met tools zoals 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
Als vCenter is geconfigureerd met FQDN in plaats van IP-adres, kan de opdracht nslookup worden gebruikt om de naamresolutie te verifiëren.
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. Controleer of OOB of INB wordt gebruikt
Controleer de APIC-routeringstabel om te controleren of out-of-band of in-band de voorkeur heeft voor connectiviteit en welke gateway wordt gebruikt:
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. Zorg ervoor dat poort 443 is toegestaan tussen alle APIC's en het vCenter, inclusief firewalls op het communicatiepad.
vCenter <-> APIC - HTTPS (TCP-poort 443) - communicatie
De algemene bereikbaarheid van HTTPS van APICs aan vCenter kan met een krul worden getest:
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)
...
Controleer dat de gedeelde leider een gevestigde TCP-verbinding heeft op poort 443 met behulp van de netstat opdracht.
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. Voer een pakketvastlegging uit
Indien mogelijk moet u een pakketopname langs het pad uitvoeren tussen de gedeelde leider en vCenter om na te gaan of er verkeer wordt verzonden en ontvangen door een van beide apparaten.
Deze tabel toont een lijst van VMWare VDS-parameters en specificeert of deze door de APIC kunnen worden geconfigureerd.
VMware VDS |
Standaardwaarde |
Configureerbaar met Cisco APIC-beleid? |
Naam |
VMM Domain Name |
Ja (afgeleid van domein) |
Beschrijving |
APIC virtuele Switch |
Nee |
Mapnaam |
VMM Domain Name |
Ja (afgeleid van domein) |
Versie |
Hoogst ondersteund door vCenter |
Ja |
Detectieprotocol |
LLDP |
Ja |
Uplink-poorten en uplinknamen |
8 |
Ja (van Cisco APIC release 4.2(1)) |
Naamprefix voor uplink |
opstraalverbinding |
Ja (van Cisco APIC release 4.2(1)) |
Maximaal MTU |
9000 |
Ja |
LACS-beleid |
uitgeschakeld |
Ja |
Poortmirroring |
0 sessies |
Ja |
Alarmen |
2 alarmen toegevoegd op mapniveau |
Nee |
Deze tabel toont een lijst van VMWare VDS-poortgroepparameters en specificeert of deze door de APIC kunnen worden geconfigureerd.
VMware VDS-poortgroep |
Standaardwaarde |
Configureerbaar met APIC-beleid |
Naam |
Naam huurder | Naam van toepassingsprofiel | EPG-naam |
Ja (afgeleid van EPG) |
Poortbinding |
Statische binding |
Nee |
VLAN |
Geselecteerd uit VLAN-pool |
Ja |
Algoritme voor taakverdeling |
Afgeleid op basis van poortkanaalbeleid inzake APIC |
Ja |
Beloftevolle modus |
Uitgeschakeld |
Ja |
Vervalste verzending |
Uitgeschakeld |
Ja |
MAC-wijziging |
Uitgeschakeld |
Ja |
Alle poorten blokkeren |
ONJUIST |
Nee |
Er vinden inventarissynchronisatiegebeurtenissen plaats om ervoor te zorgen dat de APIC zich bewust is van vCenter-gebeurtenissen die vereisen dat de APIC het beleid dynamisch bijwerkt. Er zijn twee typen inventarissynchronisatiegebeurtenissen die kunnen optreden tussen vCenter en APIC; een volledige inventarissynchronisatie en een gebeurtenisgebaseerde inventarissynchronisatie. Het standaardschema van een volledige inventarissynchronisatie tussen de APIC en vCenter is om de 24 uur, maar deze kunnen ook handmatig worden geactiveerd. Op gebeurtenissen gebaseerde inventarissyncs zijn doorgaans gekoppeld aan geactiveerde taken, zoals een vMotion. In dit geval, als een virtuele machine van de ene host naar de andere verplaatst en die hosts zijn verbonden met twee verschillende switches, zal de APIC luisteren naar de VM-migratiegebeurtenis en, in het geval van on-demand implementatiedemping, de EPG op het bronblad deprogrammeren en de EPG op het doelblad programmeren.
Afhankelijk van de implementatiedruk van EPG's die gekoppeld zijn aan een VMM-domein, kan het niet ophalen van inventaris uit het vCenter ongewenste gevolgen hebben. In het scenario dat de inventarisatie niet is voltooid of gedeeltelijk is, zal er altijd een fout worden gemaakt die het object of de objecten die de storing hebben veroorzaakt, aangeeft.
Scenario 1 - Virtuele machine met ongeldige ondersteuning:
Als een virtuele machine van het ene vCenter naar het andere wordt verplaatst, of als wordt vastgesteld dat de virtuele machine een ongeldige back-up heeft (bijvoorbeeld een poortgroepbijlage bij een oude/verwijderde DVS), wordt de vNIC weergegeven met operationele problemen.
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.
Scenario 2 — vCenter-beheerder heeft een VMM-beheerd object op vCenter gewijzigd:
Het wijzigen van objecten die worden beheerd met APIC vanuit vCenter is geen ondersteunde bewerking. Deze fout wordt opgemerkt als een niet-ondersteunde bewerking op vCenter wordt uitgevoerd.
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 Domain - vCenter-controller - inventarissynchronisatie activeren
Wanneer u een nieuwe vCenter-controller maakt als onderdeel van een VMM-domein, wordt de standaardinstelling voor de DVS-versie bepaald door het "vCenter Default" te gebruiken. Bij het selecteren van dit, zal de versie DVS worden gemaakt met de versie van vCenter.
VMWare VMM Domain - vCenter-controller maken
Dit betekent dat in het voorbeeld van een vCenter met 6.5 en ESXi-servers met 6.0, de APIC een DVS met versie 6.5 zal maken en dat de vCenter-beheerder de ESXi-servers met 6.0 niet kan toevoegen aan de ACI DVS.
APIC beheerde DVS - vCenter-hosttoevoeging - lege lijst
APIC beheerde DVS - vCenter-hosttoevoeging - incompatibele hosts
Zorg er dus bij het maken van een VMM-domein voor dat u de juiste "DVS-versie" selecteert, zodat de benodigde ESXi-servers aan de DVS kunnen worden toegevoegd.
De integratie van VMM in ACI onderscheidt zich van handmatige levering in die zin dat de stof dynamisch kan ontdekken waar de gastheren en de toepasselijke virtuele machines worden verbonden om beleid efficiënt te implementeren. Dankzij dit dynamisch proces kan ACI het gebruik van hardwareresources op de switches optimaliseren, aangezien VLAN’s, SVI’s, zoningregels en meer alleen op knooppunten worden ingezet wanneer er een verbonden eindpunt is dat het beleid vereist. Vanuit het oogpunt van gebruiksgemak is het voordeel voor de netwerkbeheerder dat ACI VLAN/beleid zal provisioneren waar VM's op geautomatiseerde wijze verbinding maken. Om te bepalen waar het beleid moet worden ingezet, zal de APIC informatie uit meerdere bronnen gebruiken. In dit diagram worden de basisstappen van het hostdetectieproces beschreven bij gebruik van een op DVS gebaseerd VMM-domein.
VMWare VMM-domein — implementatieworkflow
Kortom, deze belangrijke stappen worden gezet wanneer:
Zoals kan worden gezien, speelt CDP/LLDP een belangrijke rol in het ontdekkingsproces en het is belangrijk om ervoor te zorgen dat dit goed is geconfigureerd en beide kanten hetzelfde protocol gebruiken.
In een inzet met een bladechassis met een tussenliggende switch tussen de switches en de hypervisor, moet de APIC de nabijheid 'naaien'. In dit scenario zouden meerdere detectieprotocollen kunnen worden gebruikt omdat de intermediaire switch andere protocolvereisten heeft dan de host.
Bij een installatie met een bladeserver en een tussenliggende switch (een bladechassis-switch) kan ACI de tussenliggende switch detecteren en de hypervisors erachter in kaart brengen. De intermediaire switch wordt in ACI een Losse Knooppunt of een "Onbeheerd Fabricknooppunt" genoemd. De gedetecteerde losse knooppunten kunnen worden bekeken onder Fabric > Inventaris > Fabric Membership > Unmanaged Fabric Nodes. Door naar een van deze typen servers in de GUI te navigeren, kan de gebruiker het pad van blad naar intermediaire switch naar host bekijken.
APIC UI — onbeheerde fabricknooppunten (losse knooppunten)
Met LLDP- of CDP-detectie kan ACI de topologie voor dergelijke losse knooppunten bepalen, omdat de hypervisor downstream van de tussenliggende switch wordt beheerd via VMM-integratie en het blad zelf een nabijheid heeft van de tussenliggende switch downstream.
Dit concept wordt geïllustreerd door deze afbeelding:
APIC UI — pad voor onbeheerd fabric-knooppunt
In scenario's waarin kritische services gebruik maken van de VMM-geïntegreerde DVS, zoals beheerconnectiviteit met vCenter/ESXi, is het verstandig om de Pre-Provision Resolution Immediacy te gebruiken. Met deze instelling wordt het mechanisme van dynamische hostdetectie verwijderd en worden in plaats daarvan beleid/VLAN’s statisch geprogrammeerd op de host-omliggende interfaces. In deze configuratie zullen de VMM VLAN’s altijd worden geïmplementeerd op alle interfaces die zijn gekoppeld aan de AEP waarnaar door het VMM-domein wordt verwezen. Dit verwijdert de mogelijkheid dat een kritisch VLAN (zoals beheer) wordt verwijderd uit een poort vanwege een gebeurtenis die te maken heeft met het detectieprotocol.
Raadpleeg dit diagram:
Voorbeeld van implementatie vóór de provisioning
Als Pre-provisioning was ingesteld voor een EPG in het ACI_VDS1 VMM Domain, dan zouden VLAN’s worden geïmplementeerd op koppelingen voor Server1 maar niet op Server2, omdat de AEP van Server2 het ACI_VDS1 VMM Domain niet bevat.
U kunt de instellingen voor de resolutie als volgt samenvatten:
In dit scenario is VMM-integratie geconfigureerd en is de DVS toegevoegd aan de hypervisor maar de VM kan ARP niet oplossen voor zijn gateway in ACI. Controleer of de nabijheid tot stand is gebracht en VLAN’s worden geïmplementeerd om de VM netwerkconnectiviteit te bieden.
Eerst, kan de gebruiker controleren het blad de gastheer door te gebruiken toont lldp buren of cdp buren op het blad afhankelijk van het geselecteerde protocol heeft ontdekt.
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
Indien nodig vanuit het perspectief van probleemoplossing kan dit worden gevalideerd vanuit de ESXi-kant, zowel op de CLI als op de GUI:
[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-nabijheidsgegevens
Als de LLDP-nabijheid van het blad niet vanaf de ESXi-host kan worden gezien, wordt dit vaak veroorzaakt door het gebruik van een netwerkadapter die is geconfigureerd om LLDPDU's te genereren in plaats van het ESXi-besturingssysteem. Controleer of de netwerkadapter LLDP heeft ingeschakeld en dus alle LLDP-informatie verbruikt. Als dit probleem zich voordoet, moet u LLDP uitschakelen op de adapter zelf, zodat deze wordt bestuurd via het vSwitch-beleid.
Een andere oorzaak kan zijn dat er een verkeerde uitlijning is tussen de ontdekkingsprotocollen die tussen blad en ESXi Hypervisor worden gebruikt. Zorg ervoor dat u aan beide uiteinden hetzelfde detectieprotocol gebruikt.
Om te controleren of de CDP/LLDP-instellingen zijn uitgelijnd tussen ACI en DVS in de APIC UI, navigeer je naar Virtual Networking > VMM Domains > VMWare > Policy > vSwitch Policy. Zorg ervoor dat u alleen LLDP- of CDP-beleid inschakelt, aangezien deze elkaar uitsluiten.
APIC UI - VMWare VMM-domein - vSwitch-beleid
Ga in vCenter naar: Netwerken > VDS > Configureren.
vCenter Web Client UI - VDS-eigenschappen
Corrigeer de LLDP/CDP-instellingen indien nodig.
Vervolgens valideren van de APIC observeert de LLDP/CDP-buurt van de ESXi-host tegen de switch in de UI onder Virtual Networking > VMM Domains > VMWare > Policy > Controller > Hypervisor > General.
APIC UI - VMWare VMM-domein - Hypervisor details
Als dit verwachte waarden toont, dan kan de gebruiker bevestigen dat VLAN op de haven naar de gastheer aanwezig is.
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 een scenario waarin vCenter- of ESXi-beheerverkeer gebruik moet maken van de geïntegreerde VMM-DVS, is het belangrijk om wat extra zorg te besteden aan het voorkomen van een patstelling in het activeren van de dynamische nabijheid en het activeren van de vereiste VLAN’s.
Voor vCenter, dat doorgaans wordt gebouwd voordat VMM-integratie is geconfigureerd, is het belangrijk om een fysiek domein en statisch pad te gebruiken om er zeker van te zijn dat de vCenter VM encap VLAN altijd op de switches van het blad is geprogrammeerd, zodat het kan worden gebruikt voordat de VMM-integratie volledig is ingesteld. Zelfs na het opzetten van de VMM integratie, is het raadzaam om dit statische pad te laten om altijd de beschikbaarheid van deze EPG te verzekeren.
Voor de ESXi-hypervisors is het volgens de Cisco ACI Virtualization Guide op Cisco.com belangrijk dat u er bij de migratie naar de vDS voor zorgt dat de EPG waar de VMK-interface zal worden aangesloten, wordt geïmplementeerd met de resolutie directheid ingesteld op Pre-provisioning. Dit zorgt ervoor dat het VLAN altijd op de switches van het blad geprogrammeerd is zonder te vertrouwen op LLDP/CDP-detectie van de ESXi-hosts.
De typische oorzaken van LosseNode ontdekkingskwesties zijn:
Bij het zien van deze fout:
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)
Gelieve de workflow in sectie VM kan ARP niet oplossen voor zijn standaardgateway omdat dit betekent dat er ontbrekende CDP/LLDP-nabijheid zijn. Deze nabijheid kan van begin tot eind worden geverifieerd.
Wanneer u hypervisors zoals ESXi aansluit op een ACI-fabric, zullen deze hypervisors meestal worden aangesloten met meerdere uplinks. Sterker nog, het is aan te raden om een ESXi-host aan te sluiten op ten minste twee switches. Dit zal de impact van storingsscenario's of upgrades minimaliseren.
Om te optimaliseren hoe uplinks worden gebruikt door de werkbelastingen die op een hypervisor worden uitgevoerd, kunnen met VMware vCenter-configuraties meerdere taakverdelingsalgoritmen voor VM-gegenereerd verkeer naar de hypervisor-uplinks worden geconfigureerd.
Het is van cruciaal belang dat alle hypervisors en de ACI-fabric zijn uitgelijnd met dezelfde configuratie van taakverdelingsalgoritme om ervoor te zorgen dat de juiste connectiviteit beschikbaar is. Wanneer u dit niet doet, kan dit resulteren in onderbroken verkeersstroomdalingen en eindpuntbewegingen in het ACI-weefsel.
Dit kan worden gezien in een ACI-structuur door overmatige waarschuwingen zoals:
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
Dit hoofdstuk zal VMWare ESXi-hostconnectiviteit naar ACI dekken, maar is van toepassing voor de meeste hypervisors.
Als we kijken naar de verschillende manieren waarop een ESXi-host verbinding kan maken met een ACI-fabric, dan zijn deze verdeeld in 2 groepen, switch-afhankelijke en switch-onafhankelijke taakverdelingsalgoritmen.
Switch-onafhankelijke load balancing algoritmen zijn manieren om verbinding te maken waar geen specifieke switch configuratie nodig is. Voor switch-afhankelijke taakverdeling zijn switch-specifieke configuraties vereist.
Controleer of vSwitch-beleid voldoet aan de vereisten van de ACI Access Policy Group in deze tabel:
VMware-teams en failover-modus |
ACI vSwitch-beleid |
Beschrijving |
ACI Access Policy Group - poortkanaal vereist |
Route op basis van de oorspronkelijke virtuele poort |
MAC Pinning |
Selecteer een uplink op basis van de virtuele poort-ID's op de switch. Nadat de virtuele switch een uplink voor een virtuele machine of een VMKernel adapter selecteert, wordt het verkeer altijd door dezelfde uplink voor deze virtuele machine of VMKernel adapter doorgestuurd. |
Nee |
Route op basis van MAC-hash |
NA |
Selecteer een uplink op basis van een hash van het bron MAC-adres |
NA |
Expliciete failover-volgorde |
Expliciete failover-modus gebruiken |
Gebruik in de lijst met actieve adapters altijd de hoogste ordeuplink die voldoet aan de criteria voor failover-detectie. Bij deze optie wordt geen werkelijke taakverdeling uitgevoerd. |
Nee |
Link Aggregation (LAG) - op basis van IP-hash |
Statisch kanaal - Modus aan |
Selecteer een uplink op basis van een hash van de bron- en doelIP-adressen van elk pakket. Voor niet-IP-pakketten gebruikt de switch de gegevens in die velden om de hash te berekenen. IP-gebaseerde teaming vereist dat aan de ACI-kant een poortkanaal / VPC is geconfigureerd met 'mode on'. |
Ja (kanaalmodus ingesteld op 'aan') |
Link Aggregation (LAG) - LACP |
LACP actief/passief |
Selecteer een uplink op basis van een geselecteerde hash (20 verschillende hashopties beschikbaar). LACP-gebaseerde teaming vereist dat aan de ACI-kant een poortkanaal / VPC is geconfigureerd met LACP ingeschakeld. Zorg ervoor dat u een uitgebreid logbeleid in ACI maakt en dit op het VS-switchbeleid toepast. |
Ja (kanaalmodus ingesteld op 'LACP Active/Passive') |
Route op basis van fysieke NIC-lading (LBT) |
MAC Pinning - Physical-NIC-load |
Beschikbaar voor gedistribueerde poortgroepen of gedistribueerde poorten. Selecteer een uplink op basis van de huidige lading van de fysieke netwerkadapters die zijn aangesloten op de poortgroep of poort. Als een uplink 30 seconden lang 75% of hoger bezet blijft, verplaatst de host vSwitch een deel van het verkeer van de virtuele machine naar een fysieke adapter met vrije capaciteit. |
Nee |
Zie deze schermafbeelding over het valideren van het poortkanaalbeleid als onderdeel van het vSwitch-beleid.
ACI vSwitch-beleid — Beleid voor poortkanaal
N.B.: Raadpleeg vSphere Networking op https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-D34B1ADD-B8A7-43CD-AA7E-2832A0F7EE76.html voor een diepgaande beschrijving van de VMware-netwerkfuncties
Wanneer u Cisco UCS B-Series servers gebruikt, is het belangrijk om te onthouden dat deze binnen hun chassis verbinding maken met UCS Fabric Interconnects (FI’s) die geen uniform dataplane hebben. Dit gebruiksgeval is ook van toepassing op andere leveranciers die een vergelijkbare topologie gebruiken. Hierdoor kan er een verschil zijn tussen de werklastverdelingsmethode die wordt gebruikt aan de kant van een ACI-switch en de kant van de vSwitch.
Dit is een UCS FI-topologie met ACI:
Cisco UCS FI met ACI-switches - topologie
Belangrijkste dingen om op te merken:
Zo configureert u dit op de juiste manier:
Wanneer MAC Pinning is ingesteld op het poortkanaalbeleid als onderdeel van het vSwitch-beleid in ACI, wordt dit weergegeven als "Route gebaseerd op de oorspronkelijke virtuele poort" teamconfiguratie van de poortgroepen op de VDS.
ACI — Poortkanaalbeleid als onderdeel van vSwitch-beleid
Het poortkanaalbeleid dat in het voorbeeld wordt gebruikt, heeft de automatische naam van de wizard. Daarom wordt het "CDS_lacpLagPol" genoemd, hoewel we gebruik maken van Mode "MAC Pinning".
VMWare vCenter — ACI VDS — poortgroep — instelling voor taakverdeling
Revisie | Publicatiedatum | Opmerkingen |
---|---|---|
2.0 |
16-Aug-2024 |
Opmaak, stijlproblemen, DEI-tekst, kopregels |
1.0 |
05-Aug-2022 |
Eerste vrijgave |