Risoluzione dei problemi di integrazione ACI VMM

Introduzione

In questo documento viene descritto come comprendere e risolvere i problemi relativi all'integrazione di ACI Virtual Machine Manager (VMM).

Premesse

Il materiale di questo documento è stato estratto dai capitoli Risoluzione dei problemi relativi a Cisco Application Centric Infrastructure, Second Edition, in particolare Integrazione VMM - Panoramica, Integrazione VMM - Connettività vCenter, Integrazione VMM - Individuazione dinamica host e Integrazione VMM - Bilanciamento del carico uplink di Hypervisor.

Panoramica di Virtual Machine Manager

I controller ACI sono in grado di integrarsi con VMM (Virtual Machine Manager) di terze parti.

Questa è una delle caratteristiche principali di ACI in quanto semplifica e automatizza le operazioni per la configurazione di rete end-to-end del fabric e per i carichi di lavoro che vi si connettono. ACI offre un unico modello di criteri di sovrapposizione che può essere esteso a più tipi di carico di lavoro, ad esempio macchine virtuali, server bare metal e contenitori.

In questo capitolo verranno trattati in modo specifico alcuni scenari tipici di risoluzione dei problemi relativi all'integrazione di VMware vCenter VMM.

Il lettore procederà attraverso:

• Indagine sugli errori di comunicazione di vCenter.
• Processo di individuazione dinamica host e VM e scenari di errore.
• Algoritmi di bilanciamento del carico dell'hypervisor.

Connettività vCenter

Controllo degli accessi basato sui ruoli (RBAC)

I meccanismi tramite i quali APIC è in grado di interfacciarsi con il controller vCenter dipendono dall'account utente associato a un determinato dominio VMM. L'utente vCenter associato al dominio VMM deve soddisfare requisiti specifici per garantire che l'APIC possa eseguire correttamente le operazioni su vCenter, sia che esegua il push e il recupero dell'inventario e delle configurazioni, sia che esegua il monitoraggio e l'ascolto degli eventi correlati all'inventario gestito.

Il modo più semplice per eliminare il problema relativo a tali requisiti consiste nell'utilizzare l'account vCenter dell'amministratore con accesso completo; tuttavia, questo tipo di libertà non è sempre disponibile per l'amministratore ACI.

I privilegi minimi per un account utente personalizzato, a partire dalla versione ACI 4.2, sono i seguenti:

• Allarmi
  • APIC crea due avvisi sulla cartella. Una per DVS e un'altra per il gruppo di porte. Viene generato un allarme quando il criterio di dominio EPG o VMM viene eliminato nell'APIC, ma vCenter non è in grado di eliminare il gruppo porte o il DVS corrispondente a causa del collegamento di macchine virtuali.
• Switch distribuito
• Gruppo dvPort
• Cartella
• Rete
  • APIC gestisce le impostazioni di rete come l'aggiunta o l'eliminazione di gruppi di porte, l'impostazione di MTU host/DVS, LLDP/CDP, LACP e così via.
• Host
  • Se si utilizza AVS oltre a quanto descritto sopra, l'utente deve disporre del privilegio Host sul data center in cui APIC creerà i servizi DVS.
  • Host.Configuration.Advanced, impostazioni
  • Operazioni Host.Local.Riconfigura macchina virtuale
  • Configurazione di Host.Configuration.Network
  • Ciò è necessario per AVS e la funzione di posizionamento automatico per le VM di servizio dal layer 4 al layer 7 virtuali. Per AVS, APIC crea un'interfaccia VMK e la inserisce nel gruppo di porte VTEP utilizzato per OpFlex.
• Macchina virtuale
  • Se i grafici dei servizi sono in uso, è necessario disporre anche del privilegio di macchina virtuale per le appliance virtuali.
  • Virtual Machine.Configuration.Modify impostazioni dispositivo
  • Macchina virtuale.Configuration.Settings

Risoluzione dei problemi relativi a RBAC

I problemi RBAC si verificano più spesso durante la configurazione iniziale di un dominio VMM, ma potrebbero verificarsi se un amministratore di vCenter modificasse le autorizzazioni dell'account utente associato al dominio VMM dopo l'installazione iniziale.

Il sintomo può presentarsi nei modi seguenti:

• Impossibilità parziale o totale di distribuire nuovi servizi (creazione di DVS, creazione di gruppi di porte, alcuni oggetti sono stati distribuiti correttamente, ma non tutti).
• L'inventario operativo è incompleto o mancante nelle visualizzazioni dell'amministratore ACI.
• Errori generati per un'operazione vCenter non supportata o per uno degli scenari indicati (ad esempio, errore di distribuzione del gruppo di porte).
• Il controller vCenter viene segnalato come offline e un errore indica la presenza di problemi di connettività o di credenziali.

Soluzione per i problemi correlati ai RBAC

Verificare che tutte le autorizzazioni precedenti siano concesse all'utente vCenter configurato nel dominio VMM.

In alternativa, è possibile accedere direttamente a vCenter con le stesse credenziali definite nella configurazione del dominio VMM e tentare operazioni simili (creazione di gruppi di porte e così via). Se l'utente non è in grado di eseguire queste stesse operazioni mentre è connesso direttamente a vCenter, è evidente che all'utente non vengono concesse le autorizzazioni corrette.

Risoluzione dei problemi di connettività

Quando si risolve un problema relativo alla connettività VMM, è importante notare alcuni dei comportamenti fondamentali della comunicazione di ACI con vCenter.

Il primo e più pertinente comportamento è che solo un APIC nel cluster invia la configurazione e raccoglie l'inventario in un determinato punto. L'APIC è indicato come coordinatore della condivisione per questo dominio VMM. Tuttavia, più APIC sono in ascolto di eventi vCenter al fine di tenere conto di uno scenario in cui il coordinatore della condivisione ha perso un evento per qualsiasi motivo. In base alla stessa architettura distribuita degli APIC, un determinato dominio VMM disporrà di un APIC che gestisce i dati primari e le funzionalità (in questo caso, la linea guida della condivisione) e di due repliche (nel caso di VMM sono denominate follower). Per distribuire la gestione delle comunicazioni e delle funzionalità VMM tra gli APIC, due domini VMM possono avere lo stesso o un diverso coordinatore di condivisione.

Per individuare lo stato della connettività di vCenter, passare al controller VMM di interesse nella GUI o utilizzare il comando CLI riportato di seguito.

Dominio VMM VMWare - stato connettività vCenter

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

Se un controller VMM è indicato come non in linea, verrà generato un errore simile al seguente:

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.

La procedura seguente può essere utilizzata per risolvere i problemi di connettività tra VC e APIC.

1. Identificazione della linea guida condivisa

Il primo passaggio per la risoluzione di un problema di connettività tra APIC e vCenter consiste nel capire quale APIC è il leader condiviso per il dominio VMM specificato. Il modo più semplice per determinare queste informazioni è eseguire il comando 'show vmware domain name <dominio>' su qualsiasi 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. Verifica della connettività a vCenter

Dopo aver identificato l'APIC che comunica attivamente con vCenter, verificare la connettività IP con strumenti quali il 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

Se vCenter è stato configurato utilizzando l'FQDN anziché l'indirizzo IP, è possibile utilizzare il comando nslookup per verificare la risoluzione dei nomi.

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. Verificare se viene utilizzato OOB o INB

Controllare la tabella di routing APIC per verificare se per la connettività si preferisce usare il protocollo fuori banda o in banda e quale gateway viene usato:

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. Verificare che la porta 443 sia consentita tra tutti gli APIC e vCenter, inclusi eventuali firewall nel percorso di comunicazione.

vCenter <-> APIC - HTTPS (porta TCP 443) - comunicazione

La raggiungibilità HTTPS generale dagli APIC a vCenter può essere verificata con un URL:

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)
...

Verificare che il coordinatore della condivisione disponga di una connessione TCP stabilita sulla porta 443 utilizzando il comando netstat.

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. Acquisire un pacchetto

Se possibile, eseguire un'acquisizione dei pacchetti lungo il percorso tra il dispositivo master e vCenter per identificare se il traffico viene inviato e ricevuto da entrambi i dispositivi.

Inventario VMware

Nella tabella seguente viene illustrato un elenco di parametri VMWare VDS e viene specificato se possono essere configurati dall'APIC.

Parametri VDS VMware gestiti da APIC

VMware VDS	Valore predefinito	Configurabile con i criteri APIC di Cisco?
Nome	Nome dominio VMM	Sì (derivato da dominio)
Descrizione	'Switch virtuale APIC'	No
Nome cartella	Nome dominio VMM	Sì (derivato da dominio)
Version	Massima supportata da vCenter	Sì
Discovery Protocol	LLDP	Sì
Porte uplink e nomi uplink	8	Sì (da Cisco APIC release 4.2(1))
Prefisso nome uplink	uplink	Sì (da Cisco APIC release 4.2(1))
MTU massima	9000	Sì
Criteri LACP	disabled	Sì
Mirroring delle porte	0 sessioni	Sì
Allarmi	2 allarmi aggiunti a livello di cartella	No

Nella tabella seguente viene illustrato un elenco di parametri del gruppo di porte VMWare VDS e viene specificato se tali parametri possono essere configurati dall'APIC.

Parametri gruppo porte VDS VMWare gestiti da APIC

Gruppo porte VDS VMware	Valore predefinito	Configurabile tramite criteri APIC
Nome	Nome tenant | Nome profilo applicazione | Nome EPG	Sì (derivato da EPG)
Binding porta	Associazione statica	No
VLAN	Selezionato dal pool di VLAN	Sì
Algoritmo di bilanciamento del carico	Derivato in base alla policy del canale della porta su APIC	Sì
Modalità promiscua	Disabled	Sì
Trasmissione falsificata	Disabled	Sì
Cambia MAC	Disabled	Sì
Blocca tutte le porte	FALSO	No

Risoluzione dei problemi di inventario VMware

Gli eventi di sincronizzazione dell'inventario vengono generati per garantire che l'APIC sia a conoscenza degli eventi vCenter che potrebbero richiedere l'aggiornamento dinamico dei criteri. Esistono due tipi di eventi di sincronizzazione dell'inventario che possono verificarsi tra vCenter e APIC: una sincronizzazione dell'inventario completa e una sincronizzazione dell'inventario basata sugli eventi. La pianificazione predefinita di una sincronizzazione dell'inventario completa tra APIC e vCenter è ogni 24 ore, ma anche queste possono essere attivate manualmente. Le sincronizzazioni dell'inventario basate su eventi sono in genere legate ad attività attivate, ad esempio vMotion. In questo scenario, se una macchina virtuale si sposta da un host all'altro e tali host sono collegati a due switch foglia diversi, l'APIC ascolterà l'evento di migrazione della VM e, nello scenario di immediatezza dell'installazione su richiesta, annullerà la programmazione dell'EPG sulla foglia di origine e programmerà l'EPG sulla foglia di destinazione.

A seconda dell'immediatezza dell'installazione degli EPG associati a un dominio VMM, la mancata estrazione dell'inventario da vCenter potrebbe avere conseguenze indesiderate. Nello scenario in cui l'inventario non è stato completato o è parziale, verrà sempre generato un errore che indica l'oggetto o gli oggetti che hanno causato il problema.

Scenario 1 - Macchina virtuale con supporto non valido:

Se una macchina virtuale viene spostata da un vCenter a un altro o se la macchina virtuale presenta un supporto non valido (ad esempio, un collegamento di un gruppo di porte a un DVS precedente/eliminato), la vNIC presenta problemi operativi.

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.

Scenario 2: l'amministratore di vCenter ha modificato un oggetto gestito da VMM in vCenter:

La modifica degli oggetti gestiti da APIC da vCenter non è un'operazione supportata. Se viene eseguita un'operazione non supportata su vCenter, si verificherà il seguente errore.

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.

Dominio VMM VMWare - controller vCenter - attiva sincronizzazione inventario

Versione DVS VMware

Quando si crea un nuovo controller vCenter come parte di un dominio VMM, l'impostazione predefinita per la versione DVS sarà l'utilizzo di 'vCenter Default'. Se si seleziona questa opzione, la versione DVS verrà creata con la versione di vCenter.

Dominio VMM VMWare - Creazione controller vCenter

Ciò significa che nell'esempio di un vCenter con server 6.5 ed ESXi con server 6.0, l'APIC creerà un DVS con versione 6.5 e quindi l'amministratore di vCenter non sarà in grado di aggiungere i server ESXi con versione 6.0 ad ACI DVS.

DVS gestito APIC - aggiunta host vCenter - elenco vuoto

DVS gestito APIC - aggiunta host vCenter - host incompatibili

Pertanto, quando si crea un dominio VMM, assicurarsi di selezionare la "versione DVS" corretta in modo che i server ESXi necessari possano essere aggiunti al DVS.

Individuazione dinamica host

Processo di rilevamento di host/VM

L'integrazione di VMM in ACI si differenzia dal provisioning manuale in quanto la struttura è in grado di individuare in modo dinamico dove gli host e le macchine virtuali applicabili sono connessi per implementare in modo efficiente le regole. Grazie a questo processo dinamico, ACI è in grado di ottimizzare l'utilizzo delle risorse hardware sugli switch foglia, in quanto VLAN, SVI, regole di zoning e così via vengono implementate sui nodi solo quando è connesso un endpoint che richiede la policy. Il vantaggio per l'amministratore di rete, da un punto di vista di facilità d'uso, è che ACI fornirà la VLAN/policy quando le VM si connettono in modo automatizzato. Per determinare dove distribuire i criteri, l'APIC utilizzerà le informazioni provenienti da più origini. Nel diagramma seguente vengono illustrati i passaggi di base del processo di individuazione host quando si utilizza un dominio VMM basato su DVS.

Dominio VMM VMWare: flusso di lavoro di distribuzione

In breve, i seguenti passaggi fondamentali si verificano quando:

• L'LLDP o il CDP viene scambiato tra l'hypervisor e gli switch foglia.
• Gli host segnalano le informazioni sulle adiacenze a vCenter.
• vCenter notifica all'APIC le informazioni sulle adiacenze:
  • APIC conosce l'host tramite la sincronizzazione dell'inventario.
• L'APIC applica il criterio alla porta foglia:
  • per ulteriori informazioni su queste condizioni, consultate la sottosezione "Immediatezza della risoluzione" all'interno di questa sezione.
• Se le informazioni sulle adiacenze di vCenter vengono perse, APIC può rimuovere la regola.

Come si può notare, CDP/LLDP svolge un ruolo chiave nel processo di rilevamento ed è importante verificare che sia configurato correttamente ed entrambi i dispositivi utilizzino lo stesso protocollo.

Fabric LooseNode / switch intermedio - caso di utilizzo

In un'implementazione che utilizza uno chassis blade con uno switch intermedio tra gli switch foglia e l'hypervisor, l'APIC deve "unire" l'adiacenza. In questo scenario, è possibile utilizzare più protocolli di rilevamento, in quanto lo switch intermedio può avere requisiti di protocollo diversi rispetto all'host.

In una configurazione con un server blade e uno switch intermedio (ad esempio, uno switch con chassis blade), ACI dovrebbe rilevare lo switch intermedio e mappare gli hypervisor sottostanti. In ACI, lo switch intermedio è detto 'LooseNode' o 'Unmanaged Fabric Node'. I LooseNodes rilevati possono essere visualizzati in 'Fabric > Inventario > Appartenenza fabric > Nodi fabric non gestiti'. Passando a uno di questi tipi di server nella GUI, l'utente può visualizzare il percorso dallo switch foglia a quello intermedio fino all'host.

Interfaccia utente APIC - Nodi fabric non gestiti (LooseNodes)

Con il rilevamento LLDP o CDP, ACI può determinare la topologia per tali LooseNodes, dato che l'hypervisor a valle dello switch intermedio è gestito tramite l'integrazione VMM e la foglia stessa ha una adiacenza allo switch intermedio da downstream.

Questo concetto è illustrato nell'immagine seguente.

Interfaccia utente APIC - Percorso nodo fabric non gestito

Risoluzione Immediata

Negli scenari in cui i servizi critici utilizzano i DVS integrati in VMM, ad esempio la connettività di gestione a vCenter/ESXi, è prudente utilizzare l'Immediatezza della risoluzione di pre-provisioning. Con questa impostazione, il meccanismo di rilevamento dinamico dell'host viene rimosso e le policy/VLAN vengono invece programmate in modo statico sulle interfacce rivolte all'host. In questa configurazione, le VLAN VMM verranno sempre distribuite su tutte le interfacce collegate all'AEP a cui fa riferimento il dominio VMM. In questo modo si evita che una VLAN critica (ad esempio la gestione) venga rimossa da una porta a causa di un evento adiacente al protocollo di rilevamento.

Per ulteriori informazioni, fare riferimento al diagramma seguente:

Esempio di pre-provisioning della distribuzione

Se è stato impostato il pre-provisioning per un EPG nel dominio VMM ACI_VDS1, le VLAN verranno distribuite sui collegamenti per Server1 ma non per Server2, in quanto l'AEP di Server2 non include il dominio VMM ACI_VDS1.

Per riepilogare le impostazioni di immediatezza della risoluzione:

• On-Demand: i criteri vengono implementati quando viene stabilita l'adiacenza tra foglia e host e una VM collegata al gruppo di porte.
• Immediato: i criteri vengono distribuiti quando viene stabilita l'adiacenza tra foglia e host.
• Pre-provisioning: il criterio viene distribuito su tutte le porte che utilizzano un AEP con il dominio VMM contenuto. Non è richiesta alcuna adiacenza.

Risoluzione dei problemi

La VM non è in grado di risolvere ARP per il gateway predefinito

In questo scenario, l'integrazione VMM è stata configurata e il DVS è stato aggiunto all'hypervisor, ma la VM non è in grado di risolvere ARP per il gateway in ACI. Affinché la VM disponga della connettività di rete, verificare che l'adiacenza sia stata stabilita e che le VLAN siano installate.

In primo luogo, l'utente può verificare se la foglia ha rilevato l'host utilizzando 'show lldp neighbors' o 'show cdp neighbors' sulla foglia a seconda del protocollo selezionato.

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

Se necessario, dal punto di vista della risoluzione dei problemi, è possibile convalidare questa condizione dal lato ESXi sia sulla CLI che sulla 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 - dettagli adiacenze LLDP/CDP vmnic

Se l'adiacenza LLDP foglia non può essere rilevata dall'host ESXi, ciò è spesso causato dall'utilizzo di una scheda di rete configurata per generare LLDPDU anziché il sistema operativo ESXi. Assicurarsi di verificare se la scheda di rete ha il protocollo LLDP abilitato e quindi sta utilizzando tutte le informazioni LLDP. In questo caso, accertarsi di disattivare LLDP sulla scheda stessa in modo che sia controllata tramite i criteri vSwitch.

Un'altra causa potrebbe essere un disallineamento tra i protocolli di rilevamento utilizzati tra l'hypervisor leaf e l'hypervisor ESXi. Assicurarsi che su entrambe le estremità venga utilizzato lo stesso protocollo di rilevamento.

Per verificare se le impostazioni CDP/LLDP sono allineate tra ACI e DVS nell'interfaccia utente APIC, selezionare 'Networking virtuale > Domini VMM > VMWare > Criteri > Criteri vSwitch'. Assicurarsi di abilitare solo i criteri LLDP o CDP in quanto si escludono a vicenda.

Interfaccia utente APIC - Dominio VMM VMWare - Criteri vSwitch

In vCenter andare su: 'Networking > VDS > Configure' (Rete > VDS > Configura).

Interfaccia utente di vCenter Web Client - Proprietà VDS

Se necessario, correggere le impostazioni LLDP/CDP.

Convalidare quindi che l'APIC osservi il vicinato LLDP/CDP dell'host ESXi rispetto allo switch foglia nell'interfaccia utente in 'Networking virtuale > Domini VMM > VMWare > Criteri > Controller > Hypervisor > Generale'.

Interfaccia utente APIC - Dominio VMWare VMM - Dettagli hypervisor

Se vengono visualizzati i valori previsti, l'utente può verificare che la VLAN sia presente sulla porta verso l'host.

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

VMK di gestione vCenter/ESXi collegato a DVS con APIC

In uno scenario in cui il traffico di gestione di vCenter o ESXi deve utilizzare il DVS integrato VMM, è importante prestare particolare attenzione ad evitare una situazione di stallo nell'attivazione delle adiacenze dinamiche e nell'attivazione delle VLAN richieste.

Per vCenter, che in genere viene generato prima della configurazione dell'integrazione VMM, è importante utilizzare un dominio fisico e un percorso statico per garantire che la VLAN di accesso della VM di vCenter sia sempre programmata sugli switch foglia in modo da poter essere utilizzata prima della completa configurazione dell'integrazione VMM. Anche dopo aver impostato l'integrazione VMM, si consiglia di lasciare questo percorso statico in posizione per garantire sempre la disponibilità di questo EPG.

Per gli hypervisor ESXi, come indicato nella "Cisco ACI Virtualization Guide" su Cisco.com, quando si esegue la migrazione al vDS è importante assicurarsi che l'EPG a cui verrà collegata l'interfaccia VMK sia installato con l'immediatezza della risoluzione impostata su Pre-provisioning. Ciò garantirà che la VLAN sia sempre programmata sugli switch foglia senza fare affidamento sul rilevamento LLDP/CDP degli host ESXi.

Adiacenze host non individuate dietro LooseNode

Le cause tipiche dei problemi di individuazione LooseNode sono:

• CDP/LLDP non abilitato
  • È necessario scambiare CDP/LLDP tra lo switch intermedio, gli switch foglia e gli host ESXi
  • Per Cisco UCS, questa operazione viene eseguita tramite una policy di controllo di rete sulla vNIC
• Una modifica nell'IP di gestione del router adiacente LLDP/CDP interrompe la connettività
  • vCenter vedrà il nuovo IP di gestione nelle adiacenze LLDP/CDP, ma non aggiornerà APIC
  • Attiva una sincronizzazione manuale dell'inventario da correggere
• Le VLAN VMM non vengono aggiunte allo switch intermedio
  • APIC non programma switch blade/intermedi di terze parti.
  • L'app Cisco UCSM Integration (ExternalSwitch) è disponibile nella versione 4.1(1).
  • Le VLAN devono essere configurate e trunking sugli uplink connessi ai nodi foglia ACI e sui downlink connessi agli host

F606391 - Adiacenze mancanti per la scheda fisica sull'host

Quando viene visualizzato il guasto riportato di seguito:

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)

Esaminare il flusso di lavoro nella sezione "La VM non è in grado di risolvere ARP per il gateway predefinito" poiché ciò significa che mancano adiacenze CDP/LLDP. Queste adiacenze devono essere verificate da un'estremità all'altra.

Bilanciamento del carico di uplink dell'hypervisor

Quando si collegano hypervisor come ESXi a una struttura ACI, in genere sono connessi a più uplink. Infatti, si consiglia di collegare un host ESXi ad almeno due switch foglia. In questo modo si riduce al minimo l'impatto degli scenari di errore o degli aggiornamenti.

Per ottimizzare l'utilizzo degli uplink da parte dei carichi di lavoro in esecuzione su un hypervisor, le configurazioni di VMware vCenter consentono di configurare più algoritmi di bilanciamento del carico per il traffico generato da VM verso gli uplink dell'hypervisor.

Per garantire la corretta connettività, è fondamentale che tutti gli hypervisor e la struttura ACI siano allineati alla stessa configurazione dell'algoritmo di bilanciamento del carico. In caso contrario, il flusso del traffico e gli spostamenti dell'endpoint potrebbero interrompersi nell'infrastruttura ACI.

Questa condizione può essere rilevata in un fabric ACI da un numero eccessivo di avvisi, ad esempio:

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 questo capitolo verrà illustrata la connettività host VMWare ESXi in ACI, ma è applicabile alla maggior parte degli hypervisor.

Server rack

Se si esaminano i vari modi in cui un host ESXi può connettersi a un fabric ACI, questi sono suddivisi in 2 gruppi, dipendenti dallo switch e algoritmi di bilanciamento del carico indipendenti dallo switch.

Gli algoritmi di bilanciamento del carico indipendenti dallo switch consentono di stabilire connessioni in cui non è necessaria alcuna configurazione specifica dello switch. Per il bilanciamento del carico dipendente dallo switch, sono necessarie configurazioni specifiche dello switch.

Verificare che i criteri vSwitch siano in linea con i requisiti del gruppo di criteri di accesso ACI, come indicato nella tabella seguente.

Policy di Teaming e ACI vSwitch

Modalità di raggruppamento e failover di VMware	Criterio ACI vSwitch	Descrizione	Gruppo di criteri di accesso ACI - Canale porta richiesto
Route basata sulla porta virtuale di origine	Pinning MAC	Selezionare un uplink in base agli ID delle porte virtuali sullo switch. Dopo aver selezionato un uplink per una macchina virtuale o una scheda VMKernel, lo switch virtuale inoltra sempre il traffico attraverso lo stesso uplink per questa macchina virtuale o scheda VMKernel.	No
Route basata sull'hash MAC di origine	N/D	Selezionare un uplink in base a un hash dell'indirizzo MAC di origine	N/D
Ordine di failover esplicito	Usa modalità di failover esplicito	Dall'elenco delle schede attive, utilizzare sempre l'uplink di ordine più alto che soddisfa i criteri di rilevamento del failover. Con questa opzione non viene eseguito alcun bilanciamento del carico effettivo.	No
Aggregazione link (LAG) - Basata su hash IP	Canale statico - Modalità attiva	Selezionare un uplink in base a un hash degli indirizzi IP di origine e di destinazione di ciascun pacchetto. Per i pacchetti non IP, lo switch usa i dati di questi campi per calcolare l'hash. Per i raggruppamenti basati su IP, è necessario che sul lato ACI un canale porta/VPC sia configurato con la modalità 'on'.	Sì (modalità canale impostata su 'on')
Aggregazione link (LAG) - LACP	LACP attivo/passivo	Selezionare un uplink in base a un hash selezionato (sono disponibili 20 diverse opzioni di hash). Per il raggruppamento basato su LACP, sul lato ACI è necessario configurare una porta-canale/VPC con LACP abilitato. Assicurarsi di creare una regola per il ritardo avanzato in ACI e applicarla alla policy VSswitch.	Sì (modalità canale impostata su 'LACP attivo/passivo')
Route basata su carico fisico NIC (LBT)	Pinning MAC - Caricamento NIC fisico	Disponibile per gruppi di porte distribuite o porte distribuite. Selezionare un uplink in base al carico corrente delle schede di rete fisiche collegate al gruppo di porte o alla porta. Se un uplink rimane occupato al 75% o oltre per 30 secondi, il vSwitch dell'host sposta una parte del traffico della macchina virtuale in una scheda fisica con capacità libera.	No

Vedere lo screenshot seguente su come convalidare la policy port-channel come parte della policy vSwitch in uso.

Policy ACI vSwitch — Port Channel Policy

Nota: per una descrizione più dettagliata delle funzionalità di rete di VMware, vedere il documento sulla rete vSphere all'indirizzo https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.networking.doc/GUID-D34B1ADD-B8A7-43CD-AA7E-2832A0F7EE76.html

Cisco UCS serie B Use Case

Quando si utilizzano server Cisco UCS serie B, è importante notare che si connettono all'interno dello chassis a interconnessioni fabric UCS (FI) che non dispongono di una corsia dati unificata. Questo caso di utilizzo si applica anche ad altri fornitori che utilizzano una topologia simile. Per questo motivo può esserci una differenza tra il metodo di bilanciamento del carico utilizzato da un lato dello switch foglia ACI e il lato vSwitch.

Di seguito è riportata una topologia UCS FI con ACI:

Cisco UCS FI con switch foglia ACI - topologia

Aspetti principali da notare:

• Ogni Cisco UCS FI ha un canale porta verso gli switch foglia ACI.
• Gli IF UCS sono direttamente interconnessi solo per scopi di heartbeat (non utilizzati per il dataplane).
• La vNIC di ciascun server blade è associata a una scheda FI UCS specifica o utilizza un percorso verso una scheda FI utilizzando UCS Fabric Failover (Active-Standby).
• L'uso di algoritmi di hash IP sullo switch vSwitch dell'host ESXi causerà flap MAC sugli UCS FI.

Per configurare correttamente questa impostazione, eseguire le operazioni seguenti:

Quando il ping MAC è configurato nel criterio Port-Channel come parte del criterio vSwitch in ACI, viene visualizzato come 'Route basato sulla porta virtuale di origine' nella configurazione del raggruppamento dei gruppi di porte nel VDS.

ACI — Port Channel Policy (Policy del canale della porta) come parte della policy vSwitch

Il criterio del canale della porta utilizzato nell'esempio sopra riportato è denominato automaticamente dalla procedura guidata, pertanto è denominato "CDS_lacpLagPol" anche se viene utilizzata la modalità "MAC Pinning".

VMware vCenter — ACI VDS — Port Group — Load Balancing impostazione