Miglioramenti apportati al vPC (Virtual Port Channel)
Sommario
Introduzione
In questo documento vengono descritti i miglioramenti apportati al Virtual Port Channel (vPC) configurato sui dispositivi Cisco Nexus Switch di un dominio vPC.
Prerequisiti
Requisiti
Cisco consiglia di avere conoscenze base sugli scenari d'uso, la configurazione e l'implementazione del Virtual Port Channel (vPC). Per ulteriori informazioni sul vPC, consultare uno di questi documenti:
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 10.5(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 10.4(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 10.3(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 10.2(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 10.1(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 9.3(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 9.2(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 7.x
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 7000, versione 8.x
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 7000, versione 7.x
- Guida alla progettazione e alla configurazione: best practice per vPC (Virtual Port Channel) sugli switch Cisco Nexus serie 7000
Componenti usati
Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.
Premesse
Sin dalle prime versioni di Cisco NX-OS sugli switch per data center Cisco Nexus, la funzionalità Virtual Port Channel (vPC) è stata modificata numerose volte per migliorare l'affidabilità dei dispositivi connessi al vPC e per ottimizzare la modalità di inoltro di entrambi gli switch peer vPC. Comprendere lo scopo di ogni miglioramento, il cambiamento di comportamento introdotto dal miglioramento e gli scenari di errore risolti dal miglioramento possono aiutare a comprendere perché e quando un miglioramento può essere configurato all'interno di un dominio vPC per soddisfare al meglio le esigenze e i requisiti aziendali.
Dispositivi interessati
La procedura descritta in questo documento è valida per tutti gli switch per data center Cisco Nexus con funzionalità vPC.
vPC Peer Switch
In questa sezione viene descritta la funzionalità migliorata vPC Peer Switch abilitata con il comando di configurazione peer-switch nel dominio vPC.
Panoramica
In molti ambienti, gli switch Nexus di un dominio vPC sono una coppia di switch di aggregazione o core che delimitano il confine tra i domini Ethernet di Layer 2 e i domini di routing di Layer 3. Entrambi gli switch sono configurati con più VLAN e sono responsabili del routing del traffico est-ovest tra VLAN e del traffico nord-sud. In questi ambienti, gli switch Nexus svolgono una funzione di root bridge per il protocollo STP (Spanning Tree Protocol).
In genere, un peer vPC è configurato come root bridge dello Spanning Tree impostandone la priorità su un valore basso, ad esempio 0. L'altro peer vPC è configurato con una priorità Spanning Tree leggermente più alta, ad esempio 4096, in modo che possa assumere il ruolo di root bridge in caso l'altro peer vPC non funzionasse. In questa configurazione, il peer vPC che agisce come root bridge genera unità Spanning Tree Bridge Protocol Data Unit (BPDU) con un ID bridge contenente l'indirizzo MAC del sistema.
Tuttavia, se il peer vPC che funge da bridge radice si guasta e causa l'assunzione del controllo da parte dell'altro peer vPC come bridge radice dello Spanning Tree, l'altro peer vPC genera BPDU Spanning Tree con un ID bridge contenente il proprio indirizzo MAC di sistema, diverso dall'indirizzo MAC del sistema del bridge radice originale. L'impatto di questa modifica varia a seconda della modalità di connessione dei bridge a valle ed è descritto nelle seguenti sottosezioni.
Bridge non vPC con connessione ridondante
I bridge non vPC che sono connessi a entrambi i peer vPC con collegamenti ridondanti, ad esempio con un collegamento che il protocollo STP vede in stato di blocco, e che rilevano la modifica delle BPDU (e quindi il cambio di root bridge), osservano anche una modifica della porta root. Le altre interfacce di inoltro designato passano immediatamente allo stato di blocco, quindi attraversano la macchina a stati finiti del protocollo Spanning Tree (blocco, acquisizione e inoltro) a intervalli definiti dal timer di ritardo di inoltro configurato nell'STP, ossia per impostazione predefinita ogni 15 secondi.
La modifica della porta root e il successivo attraversamento della macchina a stati finiti dello Spanning Tree Protocol possono causare interruzioni importanti nella rete. La funzionalità vPC Peer Switch è stata migliorata principalmente per evitare interruzioni della rete causate dalla disconnessione di uno dei peer vPC. Con la funzionalità migliorata, il bridge non vPC ha ancora un unico collegamento ridondante in stato di blocco, ma l'interfaccia passa immediatamente allo stato di inoltro se la porta root esistente dovesse diventare inattiva a causa di un errore nel collegamento. Lo stesso processo si verifica quando il peer vPC disattivo torna attivo. L'interfaccia al root bridge con il costo più basso assume il ruolo di porta root e il collegamento ridondante passa immediatamente allo stato di blocco. L'unica conseguenza che si osserva sul piano dati è l'inevitabile perdita di pacchetti che attraversavano il peer vPC mentre questo si disconnetteva.
Bridge connessi al vPC
I bridge vPC del dominio Spanning Tree rilevano la modifica della BPDU, e quindi il cambiamento del root bridge, ed eliminano gli indirizzi MAC acquisiti in modo dinamico dalle relative tabelle degli indirizzi MAC locali. Questo comportamento non è efficiente né necessario nelle topologie con dispositivi connessi al vPC che non fanno affidamento sul protocollo STP per evitare la formazione di loop. I vPC sono considerati come un'unica interfaccia logica dal protocollo STP, proprio come normali port-channel, in modo che la perdita di un peer vPC sia simile alla perdita di un collegamento di un membro del port-channel. In entrambi gli scenari, lo Spanning Tree non cambia, quindi non è necessario scaricare gli indirizzi MAC appresi in modo dinamico dai bridge nel dominio Spanning Tree (lo scopo è quello di consentire al comportamento Ethernet flood-and-learn di riapprendere gli indirizzi MAC sulle nuove interfacce di inoltro dello Spanning Tree).
Inoltre, lo scaricamento degli indirizzi MAC appresi in modo dinamico può potenzialmente causare interruzioni. Supponiamo di avere due host con traffico UDP unidirezionale, ad esempio un client TFTP che invia i dati a un server TFTP. In questo flusso, i dati vengono trasferiti principalmente dal client TFTP al server TFTP; raramente il server TFTP restituisce il pacchetto al client TFTP. Di conseguenza, dopo uno scaricamento degli indirizzi MAC appresi in modo dinamico nel dominio Spanning Tree, l'indirizzo MAC del server TFTP non viene appreso per un certo periodo di tempo. Ciò significa che i dati del client TFTP inviati al server TFTP vengono trasmessi su tutta la VLAN, in quanto il traffico è unicast sconosciuto. Ciò può causare flussi di dati di grandi dimensioni che si spostano verso destinazioni indesiderate all'interno della rete e possono causare problemi di prestazioni se attraversano sezioni della rete con oversubscription.
Scopo della funzionalità vPC Peer Switch è proprio impedire questo comportamento inefficiente e superfluo in caso venga ricaricato o disattivato il peer vPC che svolge il ruolo di root bridge dello Spanning Tree per una o più VLAN.
Per attivare la funzionalità migliorata vPC Peer Switch, entrambi i peer vPC devono avere la stessa configurazione STP, compresa la stessa priorità su tutte le VLAN del vPC, e devono essere root bridge per tutte le VLAN del vPC. Una volta soddisfatti questi prerequisiti, usare il comando di configurazione peer-switch nel dominio vPC per attivare la funzionalità migliorata vPC Peer Switch.
Dopo aver attivato la funzionalità migliorata vPC Peer Switch, i due peer vPC iniziano a generare BPDU identiche con ID bridge contenente l'indirizzo MAC del sistema vPC condiviso da entrambi. Se un peer vPC viene ricaricato, la Spanning Tree BPDU originata dall'altro peer vPC non cambia, quindi gli altri bridge del dominio STP non percepiscono la modifica del root bridge e non possono rispondere in modo ottimale al cambiamento verificatosi nella rete.
Avvertenze
Il miglioramento di vPC Peer Switch presenta alcune avvertenze di cui è necessario essere a conoscenza prima di configurarlo in un ambiente di produzione.
I due peer vPC devono avere gli stessi valori di priorità nello Spanning Tree
Prima di attivare la funzionalità migliorata vPC Peer Switch, è necessario modificare la configurazione delle priorità Spanning Tree in tutte le VLAN del vPC in modo che siano identiche per entrambi i peer vPC.
Supponiamo di avere questa configurazione, dove N9K-1 è configurato come root bridge dello Spanning Tree per le VLAN 1, 10 e 20 con priorità 0. N9K-2 è il root bridge dello Spanning Tree per le VLAN 1, 10 e 20 con priorità 4096.
N9K-1# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 0 interface port-channel1 spanning-tree port type network N9K-2# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 4096 interface port-channel1 spanning-tree port type network
Prima di attivare la funzionalità migliorata vPC Peer Switch, modificare la configurazione delle priorità Spanning Tree per le VLAN 1, 10 e 20 su N9K-2 in modo che corrispondano alla configurazione delle priorità Spanning Tree delle stesse VLAN su N9K-1. Ecco un esempio della modifica.
N9K-2# configure terminal Enter configuration commands, one per line. End with CNTL/Z. N9K-2(config)# spanning-tree vlan 1,10,20 priority 0 N9K-2(config)# end N9K-2# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 0 interface port-channel1 spanning-tree port type network N9K-1# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 0 interface port-channel1 spanning-tree port type network
Conseguenze della funzionalità migliorata vPC Peer Switch sulle VLAN non vPC
Supponiamo di avere questa topologia:
In questa topologia, i due peer vPC (N9K-1 e N9K-2) sono collegati con due trunk di Layer 2, Po1 e Po2. Po1 è il collegamento vPC Peer-Link che trasporta le VLAN del vPC; Po2 è il trunk di Layer 2 che trasporta tutte le VLAN che non appartengono al vPC. Se la priorità Spanning Tree delle VLAN non vPC trasportate sul collegamento Po2 è la stessa su N9K-1 e N9K-2, ciascun peer vPC inizia a generare i frame Spanning Tree BPDU originati dall'indirizzo MAC del sistema vPC, identici su entrambi gli switch. Di conseguenza, N9K-1 sembra ricevere la propria Spanning Tree BPDU sul collegamento Po2 per ciascuna VLAN non appartenente al vPC, anche se N9K-2 è lo switch che ha originato la Spanning Tree BPDU. Dal punto di vista del protocollo STP, N9K-1 mette il collegamento Po2 in uno stato di blocco per tutte le VLAN che non appartengono al vPC.
Si tratta di un comportamento normale. Per evitare questo comportamento o aggirare il problema, entrambi i peer vPC devono essere configurati con priorità Spanning Tree diverse su tutte le VLAN non vPC. In questo modo un peer vPC diventa il root bridge della VLAN non vPC e permette il passaggio del trunk di Layer 2 tra i peer vPC allo stato di inoltro designato (Designated Forwarding). Analogamente, il peer vPC remoto permette che il trunk di layer 2 tra i peer vPC passi allo stato di root designato (Designated Root). In questo modo il traffico delle VLAN che non appartengono al vPC raggiungerà entrambi i peer vPC passando per il trunk di Layer 2.
Configurazione
Questo è un esempio di come configurare la funzionalità vPC Peer Switch.
In questo esempio, N9K-1 è configurato come root bridge dello Spanning Tree per le VLAN 1, 10 e 20 con priorità 0. N9K-2 è il root bridge dello Spanning Tree per le VLAN 1, 10 e 20 con priorità 4096.
N9K-1# show running-config vpc <snip> vpc domain 1 role priority 150 peer-keepalive destination 10.122.190.196 interface port-channel1 vpc peer-link N9K-2# show running-config vpc <snip> vpc domain 1 peer-keepalive destination 10.122.190.195 interface port-channel1 vpc peer-link N9K-1# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 0 interface port-channel1 spanning-tree port type network N9K-2# show running-config spanning-tree spanning-tree vlan 1,10,20 priority 4096 interface port-channel1 spanning-tree port type network
Innanzitutto, la configurazione delle priorità dello Spanning Tree di N9K-2 deve essere modificata per essere identica a quella di N9K-1. Questo è un requisito obbligatorio affinché la funzionalità vPC Peer Switch funzioni come previsto. Se l'indirizzo MAC di sistema di N9K-2 è più basso dell'indirizzo MAC di sistema di N9K-1, N9K-2 assume il ruolo di root bridge del dominio Spanning Tree. Di conseguenza, gli altri bridge nel dominio Spanning Tree eliminano i dati nelle tabelle degli indirizzi MAC locali di tutte le VLAN interessate. Ecco un esempio che spiega questa situazione.
N9K-1# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 689e.0baa.dea7
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address 689e.0baa.dea7
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 1 128.4096 (vPC peer-link) Network P2p
Po10 Desg FWD 1 128.4105 (vPC) P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p
N9K-2# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 689e.0baa.dea7
Cost 1
Port 4096 (port-channel1)
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 4097 (priority 4096 sys-id-ext 1)
Address 689e.0baa.de07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1 Root FWD 1 128.4096 (vPC peer-link) Network P2p
Po10 Desg FWD 1 128.4105 (vPC) P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p
N9K-2# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
N9K-2(config)# spanning-tree vlan 1,10,20 priority 0
N9K-2(config)# end
N9K-2# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 689e.0baa.de07
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address 689e.0baa.de07
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 1 128.4096 (vPC peer-link) Network P2p
Po10 Desg FWD 1 128.4105 (vPC) P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p
Successivamente, possiamo abilitare la funzionalità vPC Peer Switch tramite il comando di configurazione peer-switch nel dominio vPC. L'ID bridge delle Spanning Tree BPDU originate da entrambi i peer vPC cambia e gli altri bridge del dominio Spanning Tree eliminano i dati nelle proprie tabelle di indirizzi MAC locali per tutte le VLAN interessate.
N9K-1# configure terminal N9K-1(config)# vpc domain 1 N9K-1(config-vpc-domain)# peer-switch N9K-1(config-vpc-domain)# end N9K-1# N9K-2# configure terminal N9K-2(config)# vpc domain 1 N9K-2(config-vpc-domain)# peer-switch N9K-2(config-vpc-domain)# end N9K-2#
Per verificare che la funzionalità vPC Peer Switch funzioni come previsto, è possibile usare il comando show spanning-tree summary per confermare che entrambi i peer vPC reclamino il ruolo di root bridge. Questo output deve anche indicare che la funzione vPC Peer Switch è abilitata e operativa.
N9K-1# show spanning-tree summary Switch is in rapid-pvst mode Root bridge for: VLAN0001, VLAN0010, VLAN0020 L2 Gateway STP is disabled Port Type Default is disable Edge Port [PortFast] BPDU Guard Default is disabled Edge Port [PortFast] BPDU Filter Default is disabled Bridge Assurance is enabled Loopguard Default is disabled Pathcost method used is short vPC peer-switch is enabled (operational) STP-Lite is disabled Name Blocking Listening Learning Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------- VLAN0001 0 0 0 3 3 VLAN0010 0 0 0 3 3 VLAN0020 0 0 0 3 3 ---------------------- -------- --------- -------- ---------- ---------- 3 vlans 0 0 0 9 9 N9K-2# show spanning-tree summary Switch is in rapid-pvst mode Root bridge for: VLAN0001, VLAN0010, VLAN0020 L2 Gateway STP is disabled Port Type Default is disable Edge Port [PortFast] BPDU Guard Default is disabled Edge Port [PortFast] BPDU Filter Default is disabled Bridge Assurance is enabled Loopguard Default is disabled Pathcost method used is short vPC peer-switch is enabled (operational) STP-Lite is disabled Name Blocking Listening Learning Forwarding STP Active ---------------------- -------- --------- -------- ---------- ---------- VLAN0001 0 0 0 3 3 VLAN0010 0 0 0 3 3 VLAN0020 0 0 0 3 3 ---------------------- -------- --------- -------- ---------- ---------- 3 vlans 0 0 0 9 9
Utilizzare il comando show spanning-tree vlan {x} per visualizzare altre informazioni dettagliate su una VLAN specifica. Lo switch che ricopre il ruolo vPC principale (primary) o principale operativo (operational primary) ha tutte le interfacce nello stato di inoltro designato. Lo switch che ricopre il ruolo vPC secondario (secondary) o secondario operativo (operational secondary) ha tutte le interfacce in stato di inoltro designato ad eccezione del collegamento vPC Peer-Link, il cui stato è di inoltro root. Tenere presente che l'indirizzo MAC del sistema vPC visualizzato nell'output del comando show vpc role è identico per l'ID root bridge e l'ID bridge di ciascun peer vPC.
N9K-1# show vpc role
vPC Role status
----------------------------------------------------
vPC role : primary
Dual Active Detection Status : 0
vPC system-mac : 00:23:04:ee:be:01
vPC system-priority : 32667
vPC local system-mac : 68:9e:0b:aa:de:a7
vPC local role-priority : 150
vPC local config role-priority : 150
vPC peer system-mac : 68:9e:0b:aa:de:07
vPC peer role-priority : 32667
vPC peer config role-priority : 32667
N9K-1# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 0023.04ee.be01
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address 0023.04ee.be01
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1 Desg FWD 1 128.4096 (vPC peer-link) Network P2p
Po10 Desg FWD 1 128.4105 (vPC) P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p
N9K-2# show vpc role
vPC Role status
----------------------------------------------------
vPC role : secondary
Dual Active Detection Status : 0
vPC system-mac : 00:23:04:ee:be:01
vPC system-priority : 32667
vPC local system-mac : 68:9e:0b:aa:de:07
vPC local role-priority : 32667
vPC local config role-priority : 32667
vPC peer system-mac : 68:9e:0b:aa:de:a7
vPC peer role-priority : 150
vPC peer config role-priority : 150
N9K-2# show spanning-tree vlan 1
VLAN0001
Spanning tree enabled protocol rstp
Root ID Priority 1
Address 0023.04ee.be01
This bridge is the root
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Bridge ID Priority 1 (priority 0 sys-id-ext 1)
Address 0023.04ee.be01
Hello Time 2 sec Max Age 20 sec Forward Delay 15 sec
Interface Role Sts Cost Prio.Nbr Type
---------------- ---- --- --------- -------- --------------------------------
Po1 Root FWD 1 128.4096 (vPC peer-link) Network P2p
Po10 Desg FWD 1 128.4105 (vPC) P2p
Po20 Desg FWD 1 128.4115 (vPC) P2p
Infine, possiamo usare lo strumento di acquisizione pacchetti del piano di controllo Ethanalyzer su uno dei peer vPC per verificare che entrambi i peer vPC stiano generando le Spanning Tree BPDU con un ID bridge e un ID root bridge contenenti l'indirizzo MAC del sistema vPC condiviso da entrambi i peer vPC.
N9K-1# ethanalyzer local interface inband display-filter stp limit-captured-frames 0 <snip> Capturing on inband 2021-05-13 01:59:51.664206 68:9e:0b:aa:de:d4 -> 01:80:c2:00:00:00 STP RST. Root = 0/1/00:23:04:ee:be:01 Cost = 0 Port = 0x9000 N9K-2# ethanalyzer local interface inband display-filter stp limit-captured-frames 0 <snip> Capturing on inband 2021-05-13 01:59:51.777034 68:9e:0b:aa:de:34 -> 01:80:c2:00:00:00 STP RST. Root = 0/1/00:23:04:ee:be:01 Cost = 0 Port = 0x9000
Conseguenze
Aver abilitato la funzionalità migliorata vPC Peer Switch può avere conseguenze diverse. In particolare, gli effetti possono variare a seconda della configurazione degli altri bridge nel dominio Spanning Tree, se sono connessi a entrambi i peer vPC su un vPC o se sono connessi in modo ridondante a entrambi i peer vPC senza un vPC.
Bridge non vPC con connessione ridondante
Se un bridge non connesso a vPC con collegamenti ridondanti a entrambi i peer vPC (in modo che un collegamento sia in stato di blocco dalla prospettiva di uno Spanning Tree Protocol) rileva una modifica nel bridge radice Spanning Tree annunciato nelle BPDU Spanning Tree, la porta radice del bridge può variare tra le due interfacce ridondanti. Di conseguenza, le altre interfacce di inoltro designato passano immediatamente allo stato di blocco, quindi attraversano la macchina a stati finiti del protocollo Spanning Tree (blocco, acquisizione e inoltro) a intervalli definiti dal timer di ritardo di inoltro configurato nell'STP, ossia per impostazione predefinita ogni 15 secondi. La modifica della porta root e il successivo attraversamento della macchina a stati finiti dello Spanning Tree Protocol possono causare interruzioni importanti nella rete.
Vale la pena ricordare che tale effetto si verifica ogni volta che il peer vPC che è al momento il root bridge del dominio Spanning Tree diventa inattivo, ad esempio in caso di interruzione dell'alimentazione, guasto hardware o nuovo caricamento dei dispositivi. Questo comportamento non è esclusivo della funzionalità migliorata vPC Peer Switch, ma è semplicemente causato da tale funzionalità abilitata quando un peer vPC diventa inattivo dal punto di vista del protocollo STP.
Bridge connessi al vPC
Se un bridge vPC rileva una modifica nel root bridge dello Spanning Tree annunciata dalle BPDU dello Spanning Tree, il bridge elimina gli indirizzi MAC acquisiti in modo dinamico dalla propria tabella degli indirizzi MAC. Durante la configurazione della funzione vPC Peer Switch, è possibile osservare questo comportamento nei due scenari seguenti:
- Quando i valori di priorità dello Spanning Tree sono configurati in modo da corrispondere tra entrambi i peer vPC, il bridge radice dello Spanning Tree può passare da un peer vPC a un altro se il peer vPC che in precedenza non era il bridge radice ha un indirizzo MAC di sistema inferiore rispetto al peer vPC che in precedenza era il bridge radice. Un esempio di questo scenario è mostrato nella sottosezione Configurazione di vPC Peer Switch in questo documento.
- Quando la funzionalità vPC Peer Switch è attivata con il comando di configurazione peer-switch nel dominio vPC, entrambi i peer vPC iniziano ad agire come root bridge del dominio Spanning Tree. I due peer vPC iniziano a generare BPDU identiche nello Spanning Tree e dichiarano di essere il root bridge del dominio Spanning Tree.
Nella maggior parte dei casi e delle topologie, nessuno dei due scenari precedenti ha conseguenze significative al livello del piano dati. Tuttavia, per un breve periodo di tempo, il traffico del piano dati viene trasmesso a tutte le porte della VLAN (modalità flooding) come unknown unicast; infatti, avendo eliminato gli indirizzi MAC appresi in modo dinamico, non è possibile acquisire l'indirizzo MAC di destinazione dei frame su nessuna porta di nessuno switch. In alcune topologie, ciò può causare brevi periodi di calo di prestazioni o perdita di pacchetti se il traffico del piano dati viene inoltrato a tutti i dispositivi di rete con oversubscription presenti nella VLAN. Ciò può anche causare problemi nei flussi di traffico unidirezionale a elevato consumo di banda o negli host invisibili all'utente (host che principalmente ricevono pacchetti e raramente li inviano), poiché questo traffico viene inviato a tutti i dispositivi della VLAN in modalità flooding per un prolungato periodo di tempo anziché essere inoltrato direttamente all'host di destinazione come accade di consueto.
Ancora una volta, questo comportamento è la conseguenza dell'eliminazione degli indirizzi MAC acquisiti in modo dinamico dalla tabella degli indirizzi MAC dei bridge nella VLAN interessata. Questo comportamento non è causato solo dalla funzionalità migliorata vPC Peer Switch o dal cambiamento del root bridge, ma può dipendere anche da una notifica di modifica alla topologia, o TCN (Topology Change Notification), generata da una porta non edge che diventa attiva nella VLAN.
Esempi di scenari di errore
I bridge non vPC con connessione ridondante riavviano la macchina a stati finiti
Supponiamo di avere questa topologia:
In questa topologia, N9K-1 e N9K-2 sono i peer vPC di un dominio vPC. N9K-1 è configurato con priorità Spanning Tree pari a 0 in tutte le VLAN ed è quindi il root bridge di tutte le VLAN. N9K-2 è configurato con priorità Spanning Tree pari a 4096 in tutte le VLAN ed è quindi il root bridge secondario di tutte le VLAN. Access-1 è uno switch connesso in modo ridondante a entrambi i peer N9K-1 e N9K-2 tramite porte di Layer 2. Queste switchport non sono associate a un port-channel, quindi il protocollo STP cambia lo stato del collegamento a N9K-1 in Designated Root e lo stato del collegamento a N9K-2 in Alternate Blocking (Blocco alternativo).
Supponiamo che N9K-1 diventi inattivo a causa di un guasto hardware, un'interruzione dell'alimentazione o il ricaricamento dello switch. N9K-2 assume il ruolo di root bridge per tutte le VLAN annunciando le Spanning Tree BPDU con l'indirizzo MAC di sistema come ID bridge. In Access-1 viene rilevata una modifica nell'ID del bridge radice. Inoltre, la porta root designata passa allo stato down/down e il collegamento che prima era in stato di blocco alternato (Alternate Blocking) per N9K-2 diventa la nuova porta root designata.
Questa modifica delle porte root designate fa sì che tutte le porte Spanning Tree non edge passino attraverso la macchina a stati finiti del protocollo Spanning Tree (blocco, acquisizione e inoltro) a intervalli definiti dal timer di ritardo di inoltro configurato nell'STP, ossia per impostazione predefinita ogni 15 secondi. Questo processo può essere estremamente dannoso per la rete.
Nello stesso scenario di errore, ma con la funzionalità migliorata vPC Peer Switch abilitata, i due peer N9K-1 e N9K-2 trasmettono Spanning Tree BPDU identiche usando l'indirizzo MAC di sistema vPC condiviso come ID bridge. Se N9k-1 si disconnette, N9K-2 continua a trasmettere la stessa Spanning Tree BPDU. Di conseguenza, Access-1 cambia immediatamente il collegamento a N9K-2 dallo stato di blocco alternato allo stato di root designato e inizia a inoltrare il traffico attraverso questo collegamento. Inoltre, poiché l'ID root bridge dello Spanning Tree non cambia, non si rischia che le porte non edge passino attraverso la macchina a stati finiti dello Spanning Tree Protocol, riducendo così le possibilità di interruzioni nella rete.
I bridge connessi al vPC eliminano gli indirizzi MAC acquisiti in modo dinamico
Supponiamo di avere questa topologia:
In questa topologia, N9K-1 e N9K-2 sono peer vPC in un dominio vPC che eseguono il routing tra la VLAN 10 e la VLAN 20. N9K-1 è configurato con priorità Spanning Tree pari a 0 per la VLAN 10 e per la VLAN 20 ed è quindi il root bridge di entrambe le VLAN. N9K-2 è configurato con priorità Spanning Tree di 4096 per la VLAN 10 e la VLAN 20 ed è quindi il root bridge secondario di entrambe le VLAN. Host-1, Host-2, Host-3 e Host-4 comunicano continuamente tra loro.
Supponiamo che N9K-1 diventi inattivo a causa di un guasto hardware, un'interruzione dell'alimentazione o il ricaricamento dello switch. N9K-2 assume il ruolo di root bridge per la VLAN 10 e la VLAN 20 annunciando le Spanning Tree BPDU con l'indirizzo MAC di sistema come ID bridge. Access-1 e Access-2 rilevano una modifica nell'ID del bridge radice e, sebbene lo spanning tree resti lo stesso (ovvero, il vPC con N9K-1 e N9K-2 rimane una porta radice designata), sia Access-1 che Access-2 scaricano il proprio indirizzo MAC di tutti gli indirizzi MAC appresi in modo dinamico nella VLAN 10 e nella VLAN 20.
Nella maggior parte degli ambienti, l'eliminazione degli indirizzi MAC acquisiti in modo dinamico causa conseguenze minime. Nessun pacchetto viene perso (a parte i pacchetti persi perché trasmessi a N9K-1 mentre era disconnesso), ma il traffico viene temporaneamente inviato a tutto il dominio di broadcast come traffico unknown unicast (modalità flooding) e tutti gli switch del dominio di broadcast acquisiscono di nuovo gli indirizzi MAC in modo dinamico.
Nello stesso scenario di errore, ma con la funzionalità migliorata vPC Peer Switch abilitata, i due peer N9K-1 e N9K-2 trasmetterebbero Spanning Tree BPDU identiche usando l'indirizzo MAC di sistema vPC condiviso come ID bridge. Se N9k-1 si disconnette, N9K-2 continua a trasmettere la stessa Spanning Tree BPDU. Di conseguenza, Access-1 e Access-2 non sono a conoscenza di alcuna modifica nella topologia dello Spanning Tree: dal loro punto di vista, le BPDU dello Spanning Tree del bridge radice sono identiche, quindi non è necessario scaricare dinamicamente gli indirizzi MAC appresi dalle VLAN rilevanti. In questo scenario di errore, il traffico unknown unicast non viene inviato a tutti i domini di broadcast.
Gateway dei peer vPC
In questa sezione viene descritta la funzionalità migliorata vPC Peer Gateway (Gateway dei peer vPC), abilitata con il comando di configurazione peer-gateway nel dominio vPC.
Panoramica
Gli switch Nexus configurati in un dominio vPC eseguono un inoltro First Hop Redundancy Protocol (FHRP) a doppia azione per impostazione predefinita. Quindi, se un peer vPC riceve un pacchetto con indirizzo MAC di destinazione appartenente al gruppo Hot Standby Router Protocol (HSRP) o Virtual Router Redundancy Protocol (VRRP) configurato sullo switch, lo switch indirizza il pacchetto in base alla sua tabella di routing locale qualunque sia lo stato del piano di controllo HSRP o VRRP. In altre parole, ci si aspetta che un peer vPC in stato HSRP Standby o VRRP Backup indirizzi i pacchetti destinati all'indirizzo MAC virtuale di HSRP o VRRP.
Quando un peer vPC indirizza un pacchetto destinato a un indirizzo MAC virtuale FHRP, riscrive il pacchetto con un nuovo indirizzo MAC di origine e di destinazione. L'indirizzo MAC di origine è l'indirizzo MAC dell'interfaccia virtuale commutata peer vPC (SVI) all'interno della VLAN a cui il pacchetto è indirizzato. L'indirizzo MAC di destinazione è l'indirizzo MAC associato all'indirizzo IP dell'hop successivo per l'indirizzo IP di destinazione del pacchetto in base alla tabella di routing locale peer vPC. Negli scenari di routing tra VLAN, dopo essere stato riscritto, l'indirizzo MAC di destinazione del pacchetto diventa l'indirizzo MAC dell'host a cui il pacchetto è destinato.
In alcuni host, per ottimizzare i risultati, non si seguono le regole di inoltro standard. Con questo comportamento, quando deve rispondere a un pacchetto in arrivo, l'host non cerca nella tabella di routing e/o nella cache ARP. Al contrario, inverte gli indirizzi MAC di origine e di destinazione del pacchetto in arrivo per il pacchetto di risposta. In altre parole, l'indirizzo MAC di origine del pacchetto in arrivo diventa l'indirizzo MAC di destinazione del pacchetto di risposta e l'indirizzo MAC di destinazione del pacchetto in arrivo diventa l'indirizzo MAC di origine del pacchetto di risposta. Nel comportamento di inoltro standard invece, l'host cerca nella tabella di routing locale e/o nella cache ARP e imposta l'indirizzo MAC di destinazione del pacchetto di risposta sull'indirizzo MAC virtuale FHRP.
Il diverso comportamento dell'host può violare la regola vPC Loop Avoidance (Prevenzione dei loop vPC), in caso il pacchetto di risposta generato dall'host sia indirizzato a un peer vPC, ma venga trasmesso dal vPC all'altro peer vPC. Il peer vPC che ha ricevuto il pacchetto lo inoltra quindi sul collegamento vPC Peer-Link al peer vPC il cui indirizzo MAC è presente nel campo dell'indirizzo MAC di destinazione del pacchetto. Il peer vPC proprietario dell'indirizzo MAC tenta di indirizzare il pacchetto localmente. Se il pacchetto deve essere trasmesso sul vPC, viene eliminato dal peer vPC per violazione della regola vPC Loop Avoidance. Di conseguenza, è possibile rilevare problemi di connettività o perdita di pacchetti per alcuni flussi provenienti da o destinati a un host che utilizza questo comportamento non standard.
La funzionalità migliorata vPC Peer Gateway è stata introdotta proprio per evitare che un tale comportamento non standard causi la perdita di pacchetti. Viene quindi consentito a un peer vPC di indirizzare localmente i pacchetti destinati all'indirizzo MAC dell'altro peer vPC in modo che i pacchetti destinati al peer vPC remoto non debbano passare per il collegamento vPC Peer-Link. In altre parole, la funzionalità migliorata vPC Peer Gateway permette a un peer vPC di indirizzare i pacchetti "per conto del" peer vPC remoto. La funzionalità migliorata vPC Peer Gateway può essere abilitata con il comando di configurazione peer-gateway nel dominio vPC.
Avvertenze
Instabilità delle adiacenze del protocollo di routing unicast sui vPC o sulle VLAN del vPC
Se tra due peer vPC e un router connesso tramite vPC o un router connesso tramite una porta orfana vPC si formano adiacenze del protocollo di routing unicast dinamico, queste ultime possono iniziare a lampeggiare continuamente dopo aver abilitato il miglioramento di vPC Peer Gateway se il miglioramento di Routing/Layer 3 su vPC non è configurato immediatamente dopo. Questi scenari di errore sono descritti in dettaglio negli esempi Adiacenze del protocollo di routing unicast su un vPC con vPC Peer Gateway e Adiacenze del protocollo di routing unicast su una VLAN del vPC con vPC Peer Gateway in questo documento.
Per risolvere il problema, abilitare la funzionalità migliorata Routing/Layer 3 over vPC con il comando di configurazione layer3 peer-router nel dominio vPC subito dopo aver abilitato la funzionalità vPC Peer Gateway con il comando di configurazione peer-gateway nel dominio vPC.
Disattivazione automatica dei reindirizzamenti ICMP e ICMPv6
Quando la funzionalità migliorata vPC Peer Gateway è abilitata, la generazione di pacchetti di reindirizzamento ICMP e ICMPv6 viene disattivata automaticamente sulle SVI di tutte le VLAN del vPC, ossia su ogni SVI associata a una VLAN trasmessa in un trunk sul collegamento vPC Peer-Link. Lo switch imposta quindi i comandi no ip redirects e no ipv6 redirects sulle SVI di tutte le VLAN del vPC. In questo modo, si impedisce che uno switch generi pacchetti di reindirizzamento ICMP in risposta a pacchetti in entrata nello switch, ma che hanno un indirizzo MAC di destinazione e un indirizzo IP del peer vPC dello switch.
In caso una specifica VLAN richieda l'uso di pacchetti di reindirizzamento ICMP o ICMPv6, è necessario escluderla per sfruttare la funzionalità migliorata vPC Peer Gateway con il comando di configurazione peer-gateway exclude-vlan<vlan-id> nel dominio vPC.
Configurazione
Riportiamo qui un esempio di configurazione della funzionalità vPC Peer Gateway.
Nell'esempio, N9K-1 e N9K-2 sono i peer vPC di un dominio vPC. Entrambi i peer vPC hanno un gruppo HSRP configurato per la VLAN 10. N9K-1 è il router HSRP attivo con priorità 150, N9K-2 è il router HSRP di standby con priorità predefinita 100.
N9K-1# show running-config vpc
<snip>
vpc domain 1
role priority 150
peer-keepalive destination 10.82.140.43
interface port-channel1
vpc peer-link
N9K-2# show running-config vpc
<snip>
vpc domain 1
peer-keepalive destination 10.82.140.42
interface port-channel1
vpc peer-link
N9K-1# show running-config interface vlan 10
<snip>
interface Vlan10
no shutdown
ip address 192.168.10.2/24
hsrp 10
preempt
priority 150
ip 192.168.10.1
N9K-2# show running-config interface vlan 10
<snip>
interface Vlan10
no shutdown
ip address 192.168.10.3/24
hsrp 10
ip 192.168.10.1
N9K-1# show hsrp interface vlan 10 brief
*:IPv6 group #:group belongs to a bundle
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Vlan10 10 150 P Active local 192.168.10.3 192.168.10.1 (conf)
N9K-2# show hsrp interface vlan 10 brief
*:IPv6 group #:group belongs to a bundle
P indicates configured to preempt.
|
Interface Grp Prio P State Active addr Standby addr Group addr
Vlan10 10 100 Standby 192.168.10.2 local 192.168.10.1 (conf)
Su N9K-1 la SVI della VLAN 10 ha un indirizzo MAC pari a 00ee.ab67.db47, su N9K-2 l'indirizzo MAC della SVI della VLAN 10 è 00ee.abd8.747f. L'indirizzo MAC virtuale HSRP della VLAN 10 è 0000.0c07.ac0a. In questo stato, l'indirizzo MAC VLAN 10 SVI di ciascuno switch e l'indirizzo MAC virtuale HSRP sono presenti nella tabella degli indirizzi MAC di ciascuno switch. L'indirizzo MAC VLAN 10 SVI di ciascuno switch e l'indirizzo MAC virtuale HSRP hanno il flag Gateway (G) presente, che indica che lo switch instrada localmente i pacchetti destinati a questo indirizzo MAC.
Tenere presente che nella tabella degli indirizzi MAC di N9K-1, l'indirizzo MAC della SVI della VLAN 10 di N9K-2 non è contrassegnato con il flag Gateway. Analogamente, nella tabella degli indirizzi MAC di N9K-2 anche l'indirizzo MAC della SVI della VLAN 10 di N9K-1 non è contrassegnato con il flag Gateway.
N9K-1# show mac address-table vlan 10
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
G 10 0000.0c07.ac0a static - F F sup-eth1(R)
G 10 00ee.ab67.db47 static - F F sup-eth1(R)
* 10 00ee.abd8.747f static - F F vPC Peer-Link(R)
N9K-2# show mac address-table vlan 10
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
G 10 0000.0c07.ac0a static - F F vPC Peer-Link(R)
* 10 00ee.ab67.db47 static - F F vPC Peer-Link(R)
G 10 00ee.abd8.747f static - F F sup-eth1(R)
La funzionalità vPC Peer Gateway può essere abilitata con il comando di configurazione peer-gateway nel dominio vPC. In questo modo lo switch può indirizzare localmente i pacchetti ricevuti con un indirizzo MAC di destinazione appartenente all'indirizzo MAC peer vPC appreso sul collegamento peer vPC. A tale scopo, è possibile impostare il flag del gateway sull'indirizzo MAC peer vPC all'interno della tabella degli indirizzi MAC dello switch.
N9K-1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. N9K-1(config)# vpc domain 1 N9K-1(config-vpc-domain)# peer-gateway N9K-1(config-vpc-domain)# end N9K-1# N9K-2# configure terminal Enter configuration commands, one per line. End with CNTL/Z. N9K-2(config)# vpc domain 1 N9K-2(config-vpc-domain)# peer-gateway N9K-2(config-vpc-domain)# end N9K-2#
Per verificare che vPC Peer Gateway funzioni come previsto, verificare che l'indirizzo MAC del vPC peer sia contrassegnato con il flag Gateway nella tabella degli indirizzi MAC.
N9K-1# show mac address-table vlan 10
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
G 10 0000.0c07.ac0a static - F F sup-eth1(R)
G 10 00ee.ab67.db47 static - F F sup-eth1(R)
G 10 00ee.abd8.747f static - F F vPC Peer-Link(R)
N9K-2# show mac address-table vlan 10
Legend:
* - primary entry, G - Gateway MAC, (R) - Routed MAC, O - Overlay MAC
age - seconds since last seen,+ - primary entry using vPC Peer-Link,
(T) - True, (F) - False, C - ControlPlane MAC, ~ - vsan
VLAN MAC Address Type age Secure NTFY Ports
---------+-----------------+--------+---------+------+----+------------------
G 10 0000.0c07.ac0a static - F F vPC Peer-Link(R)
G 10 00ee.ab67.db47 static - F F vPC Peer-Link(R)
G 10 00ee.abd8.747f static - F F sup-eth1(R)
Conseguenze
L'impatto dell'abilitazione del miglioramento di vPC Peer Gateway può variare a seconda della topologia circostante e del comportamento degli host connessi, come descritto in queste sottosezioni. Se nessuna di queste sottosezioni si applica all'ambiente, l'attivazione del miglioramento di vPC Peer Gateway non comporta interruzioni e non ha alcun impatto sull'ambiente.
Instabilità delle adiacenze del protocollo di routing unicast sui vPC o sulle VLAN del vPC
Se tra due peer vPC e un router connesso tramite vPC o un router connesso tramite una porta orfana vPC si formano adiacenze del protocollo di routing unicast dinamico, queste ultime possono iniziare a lampeggiare continuamente dopo aver abilitato il miglioramento di vPC Peer Gateway se il miglioramento di Routing/Layer 3 su vPC non è configurato immediatamente dopo. Questi scenari di errore sono descritti in dettaglio negli esempi Adiacenze del protocollo di routing unicast su un vPC con vPC Peer Gateway e Adiacenze del protocollo di routing unicast su una VLAN del vPC con vPC Peer Gateway in questo documento.
Per risolvere il problema, abilitare la funzionalità migliorata Routing/Layer 3 over vPC con il comando di configurazione layer3 peer-router nel dominio vPC subito dopo aver abilitato la funzionalità vPC Peer Gateway con il comando di configurazione peer-gateway nel dominio vPC.
Disattivazione automatica dei reindirizzamenti ICMP e ICMPv6
Quando la funzionalità migliorata vPC Peer Gateway è abilitata, la generazione di pacchetti di reindirizzamento ICMP e ICMPv6 viene disattivata automaticamente sulle SVI di tutte le VLAN del vPC, ossia su ogni SVI associata a una VLAN trasmessa in un trunk sul collegamento vPC Peer-Link. Lo switch imposta quindi i comandi no ip redirects e no ipv6 redirects sulle SVI di tutte le VLAN del vPC. In questo modo, si impedisce che uno switch generi pacchetti di reindirizzamento ICMP in risposta a pacchetti in entrata nello switch, ma che hanno un indirizzo MAC di destinazione e un indirizzo IP del peer vPC dello switch.
In caso una specifica VLAN richieda l'uso di pacchetti di reindirizzamento ICMP o ICMPv6, è necessario escluderla per sfruttare la funzionalità migliorata vPC Peer Gateway con il comando di configurazione peer-gateway exclude-vlan<vlan-id> nel dominio vPC.
Esempi di scenari di errore
Host connessi al vPC con inoltro non standard
Supponiamo di avere questa topologia:
In questa topologia, N9K-1 e N9K-2 sono peer vPC in un dominio vPC che eseguono il routing tra la VLAN 10 e la VLAN 20. Po1 è l'interfaccia del collegamento tra i peer vPC, o vPC Peer-Link. L'host con nome Host-1 è connesso ai peer N9K-1 e N9K-2 della VLAN 10 tramite il collegamento vPC Po10. L'indirizzo IP dell'Host-1 è 192.168.10.10 con indirizzo MAC pari a 0000.0000.0010. L'host con nome Host-2 è connesso ai peer N9K-1 e N9K-2 della VLAN 20 tramite il collegamento vPC Po20. L'indiirzzo IP dell'Host-2 è 192.168.20.10 con indirizzo MAC pari a 0000.0000.0020.
N9K-1 e N9K-2 hanno entrambi le SVI nella VLAN 10 e nella VLAN 20 con protocollo HSRP attivato per ciascuna SVI. Per l'interfaccia della VLAN 10 di N9K-1, l'indirizzo IP è 192.168.10.2, per l'interfaccia della VLAN 20 di N9K-1 è 192.168.20.2. Per entrambe le SVI di N9K-1, l'indirizzo MAC fisico è 00ee.ab67.db47. Per l'interfaccia della VLAN 10 di N9K-2, l'indirizzo IP è 192.168.10.3, per l'interfaccia della VLAN 20 di N9K-2 è 192.168.20.3. Per entrambe le SVI di N9K-2, l'indirizzo MAC fisico è 00ee.abd8.747f. L'indirizzo IP virtuale HSRP della VLAN 10 è 192.168.10.1, l'indirizzo MAC virtuale HSRP è 0000.0c07.ac0a. L'indirizzo IP virtuale HSRP della VLAN 20 è 192.168.20.1, l'indirizzo MAC virtuale HSRP è 0000.0c07.ac14.
Supponiamo che l'Host-1 invii un pacchetto di richiesta echo ICMP all'Host-2. Dopo aver risolto l'ARP con il gateway predefinito (indirizzo IP virtuale HSRP), l'Host-1 applica una politica di inoltro standard e genera un pacchetto di richiesta echo ICMP con un indirizzo IP di origine 192.168.10.10, un indirizzo IP di destinazione 192.168.20.10, un indirizzo MAC di origine 0000.0000.0010 e un indirizzo MAC di destinazione 0000.0c07.ac0a. Il pacchetto esce indirizzato a N9K-1. Ecco un diagramma grafico esplicativo.
N9K-1 riceve il pacchetto. Poiché il pacchetto è destinato all'indirizzo MAC virtuale HSRP, N9K-1 può indirizzarlo in base alla tabella di routing locale a prescindere dallo stato del piano di controllo HSRP. Questo pacchetto viene indirizzato dalla VLAN 10 alla VLAN 20. Come parte del routing del pacchetto, N9K-1 esegue la riscrittura del pacchetto indirizzando nuovamente i campi degli indirizzi MAC di origine e destinazione del pacchetto. La nuova origine del pacchetto coincide con l'indirizzo MAC fisico associato alla SVI della VLAN 20 di N9K-1 (00ee.ab67.db47), la destinazione coincide con l'indirizzo MAC associato all'Host-2 (0000.0000.0020). Ecco un diagramma grafico esplicativo.
L'Host-2 riceve il pacchetto e genera un pacchetto di risposta echo ICMP in risposta al pacchetto di richiesta echo ICMP dell'Host-1. Tuttavia, l'Host-2 non applica in questo caso una politica di inoltro standard. Per ottimizzare l'inoltro, l'Host-2 non cerca l'indirizzo IP dell'Host-1 (192.168.10.10) nella tabella di routing o nella cache ARP, ma inverte i campi degli indirizzi MAC di origine e di destinazione del pacchetto di richiesta echo ICMP originariamente ricevuto dall'Host-2. Di conseguenza, il pacchetto di risposta echo ICMP generato dall'Host-2 ha un indirizzo IP di origine 192.168.20.10, un indirizzo IP di destinazione 192.168.10.10, un indirizzo MAC di origine 0000.0000.0020 e un indirizzo MAC di destinazione 00ee.ab67.db47.
Se questo pacchetto di risposta echo ICMP viene inoltrato a N9K-1, verrà poi inoltrato all'Host-1 senza problemi. Tuttavia, supponiamo di avere un pacchetto di risposta echo ICMP inoltrato a N9K-2, come mostrato qui.
N9K-2 riceve il pacchetto. Poiché questo pacchetto è destinato all'indirizzo MAC fisico della VLAN 20 SVI della N9K-1, N9K-2 inoltra il pacchetto attraverso vPC Peer-Link verso N9K-1, in quanto N9K-2 non può inoltrare il pacchetto per conto di N9K-1. Di seguito è riportato un esempio visivo.
N9K-1 riceve il pacchetto. Poiché il pacchetto è destinato all'indirizzo MAC virtuale della SVI della VLAN 20 di N9K-1, N9K-1 può indirizzarlo in base alla tabella di routing locale a prescindere dallo stato del piano di controllo HSRP. Questo pacchetto viene indirizzato dalla VLAN 20 alla VLAN 10. Tuttavia, l'interfaccia in uscita per questo percorso viene risolta in vPC Po10, che è attivo su N9K-2. Questa è una violazione della regola vPC Loop Avoidance: se N9K-1 riceve un pacchetto tramite vPC Peer-Link, N9K-1 non può inoltrarlo da un'interfaccia vPC se la stessa interfaccia vPC è attiva su N9K-2. N9K-1 scarta il pacchetto come conseguenza di questa violazione. Ecco un diagramma grafico esplicativo.
Il problema può essere risolto abilitando la funzionalità vPC Peer Gateway con il comando di configurazione peer-gateway nel dominio vPC. In questo modo, N9K-2 può indirizzare il pacchetto di risposta echo ICMP (e altri pacchetti analoghi) per conto di N9K-1, anche se l'indirizzo MAC di destinazione del pacchetto appartiene a N9K-1 e non a N9K-2. N9K-2 può quindi inoltrare il pacchetto sulla sua interfaccia vPC Po10 anziché doverlo inoltrare sul collegamento vPC Peer-Link.
Routing/layer 3 su vPC (router peer layer 3)
In questa sezione viene descritta la funzionalità migliorata Routing/Layer 3 over vPC (Routing/Layer 3 su vPC), abilitata con il comando di configurazione layer3 peer-router nel dominio vPC.
Panoramica
In alcuni ambienti, i clienti potrebbero chiedere di collegare una coppia di switch Nexus tramite vPC e di formare adiacenze del protocollo di routing unicast sul vPC con entrambi i peer vPC. In alternativa, ad alcuni utenti piace connettere un router a un singolo peer vPC tramite una VLAN vPC e creare adiacenze del protocollo di routing unicast con entrambi i peer vPC sulla VLAN vPC. Il router connesso al vPC avrebbe così un percorso ECMP (Equal-Cost Multi-Path) per i prefissi annunciati da entrambi gli switch Nexus. Questa opzione può essere preferibile all'utilizzo di collegamenti di routing dedicati tra il router connesso al vPC ed entrambi i peer vPC per preservare l'utilizzo degli indirizzi IP (sono necessari 3 indirizzi IP invece di 4) o ridurre la complessità della configurazione (interfacce di routing insieme alle SVI, in particolare in ambienti VRF-Lite che richiederebbero sottointerfacce).
Le adiacenze del protocollo di routing unicast su un vPC non erano supportate in passato sulle piattaforme Cisco Nexus. Tuttavia, alcuni utenti possono aver implementato una topologia in cui le adiacenze del protocollo di routing unicast si formano su un vPC senza problemi, anche se non sono supportate. Dopo aver apportato delle modifiche alla rete, ad esempio aver aggiornato il software sul router connesso al vPC o sui peer vPC o dopo un failover del firewall, le adiacenze del protocollo di routing unicast su un vPC non funzionano più con conseguente perdita di pacchetti sul traffico del piano dati o mancata formazione delle adiacenze su uno o entrambi i peer vPC. I dettagli tecnici di questi scenari sono discussi nella sezione Esempi di scenari di errore in questo documento.
La funzionalità Routing/Layer 3 over vPC è stata introdotta per supportare la formazione di adiacenze del protocollo di routing unicast su un vPC. Tale scopo viene raggiunto autorizzando l'inoltro dei pacchetti del protocollo di routing unicast con TTL pari a 1 sul vPC Peer-Link senza di diminuire il valore TTL del pacchetto. Le adiacenze del protocollo di routing unicast potranno così formarsi sul vPC o sulla VLAN del vPC senza problemi. La funzionalità Routing/Layer 3 over vPC può essere abilitata con il comando di configurazione layer3 peer-router nel dominio vPC dopo aver abilitato la funzionalità vPC Peer Gateway con il comando di configurazione peer-gateway nel dominio vPC.
Le versioni software NX-OS che supportano la funzionalità Routing/Layer 3 over vPC su ciascuna piattaforma Cisco Nexus sono riportate nella Tabella 2 ("Supporto delle adiacenze dei protocolli di routing sulle VLAN del vPC") del documento Topologie supportate per il routing su vPC (Virtual Port Channel) sulle piattaforme Nexus.
Avvertenze
Generazione reiterata di syslog VPC-2-L3_VPC_UNEQUAL_WEIGHT
Dopo l'abilitazione del miglioramento di Routing/Layer 3 su vPC, entrambi i peer vPC iniziano a generare syslog simili a quello riportato di seguito una volta all'ora:
2021 May 26 19:13:47.079 switch %VPC-2-L3_VPC_UNEQUAL_WEIGHT: Layer3 peer-router is enabled. Please make sure both vPC peers have the same L3 routing configuration. 2021 May 26 19:13:47.351 switch %VPC-2-L3_VPC_UNEQUAL_WEIGHT: Unequal weight routing is not supported in L3 over vPC. Please make sure both vPC peers have equal link cost configuration
Nessuno di questi syslog è indice di un problema nello switch. Questi syslog avvisano l'amministratore che la configurazione, il costo e il peso del routing devono essere identici su entrambi i peer vPC quando il miglioramento di Routing/Layer 3 su vPC è abilitato per garantire che entrambi i peer vPC siano in grado di indirizzare il traffico in modo identico. Non indicano necessariamente differenze nella configurazione, nel costo o nel peso del routing dei due peer vPC.
I syslog possono essere disabilitati con questa configurazione.
switch# configure terminal switch(config)# vpc domain 1 switch(config-vpc-domain)# no layer3 peer-router syslog switch(config-vpc-domain)# end switch#
La configurazione deve essere eseguita su tutti e due i peer vPC per disabilitare il syslog su entrambi.
Traffico del piano dati con TTL 1 inoltrato al software a causa degli ID bug Cisco CSCvs82183 
e CSCvw16965
Quando la funzionalità Routing/Layer 3 over vPC è abilitata sui dispositivi Nexus serie 9000 Switch con Cloud Scale ASIC e una versione del software NX-OS precedente alla 9.3(6), il traffico del piano dati che non è associato al protocollo di routing unicast e che ha un TTL pari a 1 viene indirizzato al Supervisor e inoltrato al software anziché all'hardware. A seconda che lo switch Nexus sia uno switch a chassis fisso (detto anche "Top of Rack") o modulare (detto anche "End of Row") o una versione software NX-OS dello switch, la causa principale di questo problema può essere attribuita al difetto software Cisco ID bug CSCvs82183 o nell'ID bug Cisco CSCvw16965 . Entrambi i difetti software riguardano esclusivamente gli switch Nexus serie 9000 con Cloud Scale ASIC e nessun'altra piattaforma hardware Cisco Nexus. Per ulteriori dettagli, consultare le informazioni di ciascun difetto software.
Per evitare questi difetti software, Cisco consiglia di aggiornare il software NX-OS alla versione 9.3(6) o successive. In generale, Cisco consiglia di aggiornare regolarmente le versioni del software NX-OS sugli switch Nexus serie 9000 menzionate nel documento Versioni Cisco NX-OS consigliate per gli switch Cisco Nexus serie 9000.
Configurazione
Questo è un esempio di come configurare la funzionalità Routing/Layer 3 over vPC.
Nell'esempio, N9K-1 e N9K-2 sono i peer vPC di un dominio vPC. Su entrambi i peer vPC la funzionalità vPC Peer Gateway, necessaria per abilitare Routing/Layer 3 over vPC, è già stata abilitata. I due peer vPC hanno una SVI nella VLAN 10, abilitata nel processo OSPF 1. N9K-1 e N9K-3 sono bloccati nello stato OSPF EXSTART/EXCHANGE con un router OSPF connesso al vPC con indirizzo IP 192.168.10.3 che è anche l'ID del dispositivo vicino.
N9K-1# show running-config vpc <snip> vpc domain 1 role priority 150 peer-keepalive destination 10.122.190.196 peer-gateway interface port-channel1 vpc peer-link N9K-2# show running-config vpc <snip> vpc domain 1 peer-keepalive destination 10.122.190.195 peer-gateway interface port-channel1 vpc peer-link N9K-1# show running-config interface Vlan10 interface Vlan10 no shutdown no ip redirects ip address 192.168.10.1/24 no ipv6 redirects ip router ospf 1 area 0.0.0.0 N9K-2# show running-config interface Vlan10 interface Vlan10 no shutdown no ip redirects ip address 192.168.10.2/24 no ipv6 redirects ip router ospf 1 area 0.0.0.0 N9K-1# show running-config ospf feature ospf router ospf 1 interface Vlan10 ip router ospf 1 area 0.0.0.0 N9K-2# show running-config ospf feature ospf router ospf 1 interface Vlan10 ip router ospf 1 area 0.0.0.0 N9K-1# show ip ospf neighbors OSPF Process ID 1 VRF default Total number of neighbors: 3 Neighbor ID Pri State Up Time Address Interface 192.168.10.2 1 TWOWAY/DROTHER 00:08:10 192.168.10.2 Vlan10 192.168.10.3 1 EXCHANGE/BDR 00:07:43 192.168.10.3 Vlan10 N9K-2# show ip ospf neighbors OSPF Process ID 1 VRF default Total number of neighbors: 3 Neighbor ID Pri State Up Time Address Interface 192.168.10.1 1 TWOWAY/DROTHER 00:08:21 192.168.10.1 Vlan10 192.168.10.3 1 EXSTART/BDR 00:07:48 192.168.10.3 Vlan10
Possiamo abilitare la funzionalità Routing/Layer 3 over vPC usando il comando di configurazione layer3 peer-router nel dominio vPC. In questo modo, il peer vPC non diminuisce il valore TTL dei pacchetti del protocollo di routing unicast indirizzati dopo aver abilitato la funzionalità vPC Peer Gateway.
N9K-1# configure terminal Enter configuration commands, one per line. End with CNTL/Z. N9K-1(config)# vpc domain 1 N9K-1(config-vpc-domain)# layer3 peer-router N9K-1(config-vpc-domain)# end N9K-1# N9K-2# configure terminal Enter configuration commands, one per line. End with CNTL/Z. N9K-2(config)# vpc domain 1 N9K-2(config-vpc-domain)# layer3 peer-router N9K-2(config-vpc-domain)# end N9K-2#
È possibile verificare che Routing/Layer 3 over vPC funzioni come previsto confermando che l'adiacenza OSPF con il dispositivo vicino connesso al vPC passi allo stato FULL subito dopo aver abilitato Routing/Layer 3 over vPC.
N9K-1# show ip ospf neighbors OSPF Process ID 1 VRF default Total number of neighbors: 3 Neighbor ID Pri State Up Time Address Interface 192.168.10.2 1 TWOWAY/DROTHER 00:12:17 192.168.10.2 Vlan10 192.168.10.3 1 FULL/BDR 00:00:29 192.168.10.3 Vlan10 N9K-2# show ip ospf neighbors OSPF Process ID 1 VRF default Total number of neighbors: 3 Neighbor ID Pri State Up Time Address Interface 192.168.10.1 1 TWOWAY/DROTHER 00:12:27 192.168.10.1 Vlan10 192.168.10.3 1 FULL/BDR 00:00:19 192.168.10.3 Vlan10
Conseguenze
La funzionalità Routing/Layer 3 over vPC non ha conseguenze intrinseche sul dominio vPC. Quando si abilita la funzionalità Routing/Layer 3 over vPC, non si verifica alcuna sospensione dei vPC né il traffico del piano dati viene modificato.
Tuttavia, se le adiacenze del protocollo di routing dinamico che in precedenza erano inattive a causa della mancata abilitazione del miglioramento di Routing/Layer 3 su vPC improvvisamente si presentano come risultato dell'abilitazione di questo miglioramento, a seconda del ruolo delle adiacenze del protocollo di routing interessate, dei prefissi specifici annunciati tramite tali adiacenze e dello stato corrente della tabella di routing unicast, è possibile osservare alcune interruzioni quando si abilita il miglioramento di Routing/Layer 3 su vPC.
Per questo motivo, Cisco consiglia ai clienti di abilitare questo miglioramento durante un intervento di manutenzione in modo che si possa verificare un'interruzione del control plane o del data plane, a meno che i clienti non siano estremamente certi che le adiacenze del protocollo di routing interessate non influiscano in modo significativo sul funzionamento della rete.
Cisco consiglia inoltre di esaminare attentamente la sezione Avvertenze di questo documento per individuare eventuali difetti software che influiscono sulla versione del software NX-OS e che possono causare l'elaborazione del traffico del piano dati naturale con un valore TTL di 1 nel software anziché nell'hardware.
Esempi di scenari di errore
Adiacenze del protocollo di routing unicast su un vPC senza vPC Peer Gateway
Supponiamo di avere questa topologia:
In questa topologia, gli switch Nexus N9K-1 e N9K-2 sono i peer di un dominio vPC in cui la funzionalità vPC Peer Gateway non è abilitata. Po1 è l'interfaccia del collegamento tra i peer vPC, o vPC Peer-Link. Un router con nome host Router viene connesso tramite vPC da Po10 a N9K-1 e N9K-2. Un host viene connesso a N9K-1 e N9K-2 tramite vPC Po20. L'interfaccia Po10 del router è un canale di porta instradato che viene attivato tramite un protocollo di routing unicast. N9K-1 e N9K-2 hanno interfacce SVI attivate con lo stesso protocollo di routing unicast e si trovano nello stesso dominio di broadcast del Router.
Le adiacenze del protocollo di routing unicast su un vPC senza il miglioramento di vPC Peer Gateway abilitato non sono supportate perché la decisione di hashing ECMP del router connesso a vPC e la decisione di hashing del canale della porta di layer 2 possono essere diverse. In questa topologia, le adiacenze del protocollo di routing tra il router, N9K-1 e N9K-2 sarebbero configurate correttamente. Considerare il flusso di traffico tra il router e l'host. Il traffico del data plane che attraversa il router destinato all'host può essere riscritto con un indirizzo MAC di destinazione appartenente all'indirizzo MAC SVI di N9K-1 (a causa della decisione di hashing ECMP presa dal router), ma in uscita dall'interfaccia Ethernet1/2 (a causa della decisione di hashing del canale della porta di layer 2 presa dal router).
N9K-2 riceve il pacchetto e lo inoltra sul vPC Peer-Link, in quanto l'indirizzo MAC di destinazione appartiene a N9K-1 e la funzionalità vPC Peer Gateway (che permetterebbe a N9K-2 di indirizzare il pacchetto per conto di N9K-1) non è abilitata. N9K-1 riceve il pacchetto sul vPC Peer-Link e riconosce che deve inoltrarlo sulla sua interfaccia Ethernet1/2 sul collegamento vPC Po20. Ciò viola la regola vPC Loop Avoidance, quindi N9K-1 scarta il pacchetto nell'hardware. Di conseguenza, è possibile rilevare problemi di connettività o perdita di pacchetti per alcuni flussi che attraversano il dominio vPC in questa topologia.
Per risolvere il problema, abilitare la funzionalità vPC Peer Gateway con il comando di configurazione peer-gateway nel dominio vPC, quindi abilitare la funzionalità Routing/Layer 3 over vPC con il comando di configurazione layer3 peer-router nel dominio vPC. Per ridurre al minimo le interruzioni, è necessario abilitare entrambi i miglioramenti vPC in rapida successione in modo che lo scenario di errore descritto in Adiacenze del protocollo di routing unicast su un vPC con vPC Peer Gateway non abbia tempo di verificarsi.
Adiacenze del protocollo di routing unicast su un vPC con vPC Peer Gateway
Supponiamo di avere questa topologia:
In questa topologia, gli switch Nexus N9K-1 e N9K-2 sono i peer di un dominio vPC in cui la funzionalità vPC Peer Gateway è abilitata. Po1 è l'interfaccia del collegamento tra i peer vPC, o vPC Peer-Link. Un router con nome host Router viene connesso tramite vPC da Po10 a N9K-1 e N9K-2. L'interfaccia Po10 del router è un canale di porta routing attivato tramite un protocollo di routing unicast. N9K-1 e N9K-2 hanno interfacce SVI attivate con lo stesso protocollo di routing unicast e si trovano nello stesso dominio di broadcast del Router.
Le adiacenze del protocollo di routing unicast su un vPC con il miglioramento di vPC Peer Gateway abilitato non sono supportate perché il miglioramento di vPC Peer Gateway può impedire la formazione di adiacenze del protocollo di routing unicast tra il router connesso al vPC ed entrambi i peer vPC. In questa topologia, un protocollo di routing adiacente tra il router e il router N9K-1 o N9K-2 può non restituire il risultato previsto, a seconda di come i pacchetti del protocollo di routing unicast sono stati originati dal router nell'hash N9K-1 o N9K-2 in vPC Po10.
Tutti i router sono in grado di inviare e ricevere senza problemi i pacchetti del protocollo di routing multicast link-local, chiamati comunemente pacchetti "Hello", in quanto questi pacchetti vengono inoltrati a tutte le porte della VLAN del vPC (modalità flooding). Tuttavia, si consideri uno scenario in cui un pacchetto del protocollo di routing unicast inviato dal router destinato all'N9K-1 esce da Ethernet1/2 verso N9K-2 a causa della decisione di hashing del canale della porta di layer 2 del router. Questo pacchetto viene destinato all'indirizzo MAC della SVI di N9K-1, ma entra dall'interfaccia Ethernet1/1 di N9K-2. N9K-2 riconosce che il pacchetto è destinato all'indirizzo MAC della SVI di N9K-1, presente nella tabella degli indirizzi MAC di N9K-2 e contrassegnato con il flag "G", o "Gateway", per segnalare che la funzionalità vPC Peer Gateway è abilitata. N9K-2 cerca quindi di indirizzare localmente il pacchetto del protocollo di routing unicast per conto di N9K-1.
Tuttavia, instradando il pacchetto, il valore TTL (Time to Live) del pacchetto diminuisce e il valore TTL della maggior parte dei pacchetti del protocollo di routing unicast è 1. Di conseguenza, il valore TTL del pacchetto viene diminuito a 0 e scartato da N9K-2. Dal punto di vista di N9K-1, N9K-1 riceve pacchetti del protocollo di routing multicast locale rispetto al collegamento dal router ed è in grado di inviare pacchetti del protocollo di routing unicast al router, ma non riceve pacchetti del protocollo di routing unicast dal router. N9K-1 elimina quindi l'adiacenza del protocollo di routing con il router e riavvia la macchina a stati finiti locale per il protocollo di routing. Analogamente, il router riavvia la macchina a stati finiti locale per il protocollo di routing.
Per risolvere il problema, è possibile abilitare la funzionalità Routing/Layer 3 over vPC con il comando di configurazione layer 3 peer-router nel dominio vPC. Ciò permette di inoltrare i pacchetti unicast con TTL pari a 1 sul collegamento vPC Peer-Link senza diminuire il TTL del pacchetto. Le adiacenze del protocollo di routing unicast potranno così formarsi sul vPC o sulla VLAN del vPC senza problemi.
Adiacenze del protocollo di routing unicast su una VLAN del vPC senza vPC Peer Gateway
Supponiamo di avere questa topologia:
In questa topologia, gli switch Nexus N9K-1 e N9K-2 sono i peer di un dominio vPC in cui la funzionalità vPC Peer Gateway non è abilitata. Po1 è l'interfaccia del collegamento tra i peer vPC, o vPC Peer-Link. Un router con un nome host pari a Router viene connesso tramite Ethernet1/1 alla rete Ethernet1/1 di N9K-1. L'interfaccia Ethernet1/1 del router è un'interfaccia di routing attivata tramite un protocollo di routing unicast. N9K-1 e N9K-2 hanno interfacce SVI attivate con lo stesso protocollo di routing unicast e si trovano nello stesso dominio di broadcast del Router.
Le adiacenze del protocollo di routing unicast su una VLAN vPC senza il miglioramento di vPC Peer Gateway abilitato non sono supportate perché la decisione di hashing ECMP del router connesso alla VLAN vPC può causare all'N9K-2 il rifiuto del traffico del piano dati per la violazione della regola di prevenzione del loop vPC. In questa topologia, le adiacenze del protocollo di routing tra il router, N9K-1 e N9K-2 sarebbero configurate correttamente. Considerare il flusso di traffico tra il router e l'host. Il traffico del data plane che attraversa il router destinato all'host può essere riscritto con un indirizzo MAC di destinazione appartenente all'indirizzo MAC SVI dell'N9K-2 (a causa della decisione di hashing ECMP presa dal router) e può uscire dall'interfaccia Ethernet1/1 fino a N9K-1.
N9K-1 riceve il pacchetto e lo inoltra sul vPC Peer-Link, in quanto l'indirizzo MAC di destinazione appartiene a N9K-2 e la funzionalità vPC Peer Gateway (che permetterebbe a N9K-1 di indirizzare il pacchetto per conto di N9K-2) non è abilitata. N9K-2 riceve questo pacchetto sul vPC Peer-Link e riconosce che deve inoltrarlo dalla sua interfaccia Ethernet1/2 sul collegamento vPC Po20. Ciò viola la regola vPC Loop Avoidance, quindi N9K-2 scarta il pacchetto nell'hardware. Di conseguenza, è possibile rilevare problemi di connettività o perdita di pacchetti per alcuni flussi che attraversano il dominio vPC in questa topologia.
Per risolvere il problema, abilitare la funzionalità vPC Peer Gateway con il comando di configurazione peer-gateway nel dominio vPC, quindi abilitare la funzionalità Routing/Layer 3 over vPC con il comando di configurazione layer3 peer-router nel dominio vPC. Per ridurre al minimo le interruzioni, è necessario abilitare entrambi i miglioramenti vPC in rapida successione in modo che lo scenario di errore descritto in Adiacenze del protocollo di routing unicast su un vPC con vPC Peer Gateway non abbia tempo di verificarsi.
Adiacenze del protocollo di routing unicast su una VLAN del vPC con vPC Peer Gateway
Supponiamo di avere questa topologia:
In questa topologia, gli switch Nexus N9K-1 e N9K-2 sono i peer di un dominio vPC in cui la funzionalità vPC Peer Gateway è abilitata. Po1 è l'interfaccia del collegamento tra i peer vPC, o vPC Peer-Link. Un router con un nome host pari a Router viene connesso tramite Ethernet1/1 alla rete Ethernet1/1 di N9K-1. L'interfaccia Ethernet1/1 del router è un'interfaccia di routing attivata tramite un protocollo di routing unicast. N9K-1 e N9K-2 hanno interfacce SVI attivate con lo stesso protocollo di routing unicast e si trovano nello stesso dominio di broadcast del Router.
Le adiacenze del protocollo di routing unicast su una VLAN del vPC con vPC Peer Gateway abilitata non sono supportate perché la funzionalità vPC Peer Gateway impedisce la formazione di adiacenze del protocollo di routing unicast tra il router connesso alla VLAN del vPC e il peer vPC a cui il router connesso alla VLAN non è direttamente connesso. In questa topologia, l'adiacenza del protocollo di routing tra il Router e N9K-2 non si forma come previsto in quanto la funzionalità vPC Peer Gateway abilitata fa sì che i pacchetti unicast di N9K-1 siano destinati all'indirizzo MAC della SVI di N9K-2. Poiché i pacchetti vengono indirizzati, il valore Time To Live (TTL) viene ridotto. I pacchetti del protocollo di routing unicast hanno in genere un valore TTL pari a 1 e un router che diminuisce il valore TTL di un pacchetto a 0 deve eliminare il pacchetto.
Tutti i router sono in grado di inviare e ricevere senza problemi i pacchetti del protocollo di routing multicast link-local, chiamati comunemente pacchetti "Hello", in quanto questi pacchetti vengono inoltrati a tutte le porte della VLAN del vPC (modalità flooding). Tuttavia, si consideri uno scenario in cui un pacchetto del protocollo di routing unicast inviato dal router destinato all'N9K-2 esce da Ethernet1/1 verso N9K-1. Questo pacchetto è destinato all'indirizzo MAC SVI dell'N9K-2, ma è in entrata nell'interfaccia Ethernet1/1 dell'N9K-1. N9K-1 riconosce che il pacchetto è destinato all'indirizzo MAC della SVI di N9K-2, presente nella tabella degli indirizzi MAC di N9K-1 e contrassegnato con il flag "G", o "Gateway", per segnalare che la funzionalità vPC Peer Gateway è abilitata. N9K-1 cerca quindi di indirizzare localmente il pacchetto del protocollo di routing unicast per conto di N9K-2.
Tuttavia, instradando il pacchetto, il valore TTL del pacchetto diminuisce e il valore TTL della maggior parte dei pacchetti del protocollo di routing unicast è 1. Di conseguenza, il valore TTL del pacchetto viene diminuito a 0 e scartato da N9K-1. Dal punto di vista di N9K-2, N9K-2 riceve pacchetti del protocollo di routing multicast locale del collegamento dal router ed è in grado di inviare pacchetti del protocollo di routing unicast al router, ma non riceve pacchetti del protocollo di routing unicast dal router. N9K-2 elimina quindi l'adiacenza del protocollo di routing con il router e riavvia la macchina a stati finiti locale per il protocollo di routing. Analogamente, il router riavvia la macchina a stati finiti locale per il protocollo di routing.
Per risolvere il problema, è possibile abilitare la funzionalità Routing/Layer 3 over vPC con il comando di configurazione layer 3 peer-router nel dominio vPC. Ciò permette di inoltrare i pacchetti unicast con TTL pari a 1 sul collegamento vPC Peer-Link senza diminuire il TTL del pacchetto. Le adiacenze del protocollo di routing unicast potranno così formarsi sul vPC o sulla VLAN del vPC senza problemi.
Adiacenze del protocollo di routing unicast su un vPC back-to-back con vPC Peer Gateway
Supponiamo di avere questa topologia:
In questa topologia, gli switch Nexus N9K-1 e N9K-2 sono i peer di un dominio vPC in cui la funzionalità vPC Peer Gateway è abilitata. Gli switch Nexus N9K-3 e N9K-4 sono i peer di un dominio vPC in cui la funzionalità migliorata vPC Peer Gateway è abilitata. Entrambi i domini vPC sono connessi tra loro tramite un collegamento vPC Po10 back-to-back. Tutti e quattro gli switch hanno interfacce SVI attivate con un protocollo di routing unicast e si trovano nello stesso dominio di broadcast.
Le adiacenze del protocollo di routing unicast su un vPC back-to-back con vPC Peer Gateway abilitata non sono supportate perché la funzionalità vPC Peer Gateway può impedire la formazione di adiacenze del protocollo di routing unicast tra un dominio vPC e l'altro. In questa topologia, è possibile che l'adiacenza del protocollo di routing tra N9K-1 e N9K-3 o N9K-4 (o entrambi) non si formi come previsto. Analogamente, è possibile che l'adiacenza del protocollo di routing tra N9K-2 e N9K-3 o N9K-4 (o entrambi) non si formi come previsto. Infatti, i pacchetti del protocollo di routing unicast possono essere destinati a un router (ad esempio, N9K-3) ma essere inoltrati a un router diverso (ad esempio, N9K-4) in base alla decisione di hashing del canale della porta di layer 2 del router di origine.
La causa profonda di questo problema è già stata descritta nella sezione Adiacenze del protocollo di routing unicast su un vPC con vPC Peer Gateway in questo documento. Per risolvere il problema, è possibile abilitare la funzionalità Routing/Layer 3 over vPC con il comando di configurazione layer 3 peer-router nel dominio vPC. Ciò permette di inoltrare i pacchetti unicast con TTL pari a 1 sul collegamento vPC Peer-Link senza diminuire il TTL del pacchetto. Le adiacenze del protocollo di routing unicast potranno così formarsi sul vPC back-to-back senza problemi.
Adiacenze OSPF sul vPC con vPC Peer Gateway abilitata e prefisso presente nel database OSPF LSDB ma non nella tabella di routing
Supponiamo di avere questa topologia:
In questa topologia, gli switch Nexus N9K-1 e N9K-2 sono i peer di un dominio vPC in cui la funzionalità vPC Peer Gateway è abilitata. Gli switch Nexus N9K-3 e N9K-4 sono i peer di un dominio vPC in cui la funzionalità migliorata vPC Peer Gateway è abilitata. Entrambi i domini vPC sono connessi tra loro tramite un collegamento vPC Po10 back-to-back. Tutti e quattro gli switch hanno interfacce SVI attivate con un protocollo di routing unicast e si trovano nello stesso dominio di broadcast. N9K-4 è il router OSPF designato, o DR (Designated Router), per il dominio di broadcast, mentre N9K-3 è il router OSPF designato di backup, o BDR (Backup Designated Router), del dominio di broadcast.
In questo scenario, un'adiacenza OSPF tra N9K-1 e N9K-3 passa allo stato FULL perché i pacchetti OSPF unicast vengono trasmessi sull'interfaccia Ethernet1/1 di entrambi gli switch. Analogamente, un'adiacenza OSPF tra N9K-2 e N9K-3 passa allo stato FULL perché i pacchetti OSPF unicast vengono trasmessi sull'interfaccia Ethernet1/2 di entrambi gli switch.
Tuttavia, un'adiacenza OSPF tra N9K-1 e N9K-4 è bloccata nello stato EXSTART o EXCHANGE in quanto i pacchetti OSPF unicast escono dall'interfaccia Ethernet1/1 di entrambi gli switch e vengono eliminati da N9K-2 e N9K-4 come descritto nella sezione Adiacenze del protocollo di routing unicast su vPC back-to-back con vPC Peer Gateway in questo documento. Analogamente, un'adiacenza OSPF tra N9K-2 e N9K-4 è bloccata nello stato EXSTART o EXCHANGE in quanto i pacchetti OSPF unicast escono dall'interfaccia Ethernet1/2 di entrambi gli switch e vengono eliminati da N9K-1 e N9K-3 come descritto nella sezione Adiacenze del protocollo di routing unicast su vPc back-to-back con vPC Peer Gateway in questo documento.
Di conseguenza, N9K-1 e N9K-2 sono nello stato FULL per il BDR del dominio di broadcast, ma sono nello stato EXSTART o EXCHANGE per il DR del dominio di broadcast. Sia il DR che il BDR di un dominio di broadcast conservano una copia completa del database OSPF LSDB (Link State Data Base), ma i router OSPF DROTHER devono avere lo stato FULL per il router designato del dominio di broadcast per installare i prefissi acquisiti tramite OSPF dal router designato o dal router designato di backup. Di conseguenza, N9K-1 e N9K-2 hanno prefissi acquisiti da N9K-3 e N9K-4 presenti nel database OSPF LSDB, ma tali prefissi non risultano installati nella tabella di routing unicast finché N9K-1 e N9K-2 non passano allo stato FULL con N9K-4 (il router designato del dominio di broadcast).
Per risolvere il problema, è possibile abilitare la funzionalità Routing/Layer 3 over vPC con il comando di configurazione layer 3 peer-router nel dominio vPC. Ciò permette di inoltrare i pacchetti unicast con TTL pari a 1 sul collegamento vPC Peer-Link senza diminuire il TTL del pacchetto. Le adiacenze del protocollo di routing unicast potranno così formarsi sul vPC back-to-back senza problemi. N9K-1 e N9K-2 passano quindi allo stato FULL per N9K-4 (il router designato del dominio di broadcast) e installano i prefissi acquisiti da N9K-3 e N9K-4 tramite OSPF nelle rispettive tabelle di routing unicast.
Informazioni correlate
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 10.5(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 10.4(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 10.3(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 10.2(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 10.1(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 9.3(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 9.2(x)
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 9000, versione 7.x
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 7000, versione 8.x
- Guida alla configurazione delle interfacce NX-OS sui Cisco Nexus serie 7000, versione 7.x
- Guida alla progettazione e alla configurazione: best practice per vPC (Virtual Port Channel) sugli switch Cisco Nexus serie 7000
- Topologie supportate per il routing su vPC (Virtual Port Channel) sulle piattaforme Nexus
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
5.0 |
05-Dec-2024 |
Intestazioni e collegamenti fissi, traduzione automatica e ottimizzazione SEO |
4.0 |
12-Dec-2022 |
Certificazione |
3.0 |
29-Oct-2021 |
È stato corretto l'errore nello scenario di errore di vPC Peer Gateway. |
2.0 |
15-Sep-2021 |
Aggiungere una nota per informare che il comando di configurazione del dominio vPC "peer-gateway exclude-vlan" non è supportato sugli switch Nexus serie 9000. |
1.0 |
30-Jul-2021 |
Versione iniziale |
Feedback