Comprendere il processo di elezione di vPC

Introduzione

Questo documento descrive il processo di selezione del ruolo Virtual PortChannel (vPC) sugli switch serie Nexus.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza dei seguenti argomenti:

• vPC sugli switch serie Nexus
• STP (Spanning Tree Protocol)

Componenti usati

Per la stesura del documento, è stata usata la piattaforma dello switch Nexus serie 9000.

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.

Tecnologia Virtual PortChannel 

I vPC (Virtual PortChannel) consentono ai collegamenti fisicamente connessi a due switch Cisco diversi di apparire come un singolo PortChannel su un terzo dispositivo. Il terzo dispositivo può essere uno switch, un server o qualsiasi altro dispositivo di rete che supporti i canali porte IEEE 802.3ad. vPC consente inoltre la creazione di canali porte di layer 2 che si estendono su due switch. Al momento, vPC è implementato sulle piattaforme Cisco Nexus serie 9000, 7000, 5000 e 3000 (con o senza Cisco Nexus serie 2000 Fabric Extender).

Nota: i vPC software Cisco NX-OS e i VSS (Cisco Catalyst Virtual Switching Systems) sono tecnologie simili. Per la tecnologia Cisco EtherChannel, il termine Multi-Chassis EtherChannel (MCEC) si riferisce in modo intercambiabile a entrambe le tecnologie.

Ruolo vPC

Sebbene entrambi gli switch vPC vengano visualizzati come un singolo switch in un dispositivo downstream, tra di essi, due switch vPC hanno ruoli vPC chiaramente definiti: vPC primario e vPC secondario.

I ruoli vPC non hanno diritti di priorità, il che significa che un dispositivo può essere configurato come primario vPC, ma funzionare come dispositivo peer secondario vPC. Questo può verificarsi in questo scenario:

1. Quando il dispositivo principale originale si guasta, il dispositivo vPC secondario diventa il nuovo dispositivo principale.
2. Quando il sistema viene ripristinato automaticamente, il dispositivo primario precedente diventa il dispositivo secondario e viceversa. 

Il ruolo vPC definisce quale dei due dispositivi peer vPC elabora le BPDU (Bridge Protocol Data Unit) e risponde alle richieste ARP (Address Resolution Protocol). Il ruolo vPC definisce inoltre una serie di azioni che devono essere eseguite dal primario vPC e dal secondario vPC in risposta alla situazione di inattività del collegamento peer vPC. 

Priorità ruolo vPC 

È inoltre possibile utilizzare la priorità dei ruoli nel comando vPC domain mode per influenzare il processo di selezione di vPC. L'intervallo di valori è compreso tra 1 e 65636 e il valore predefinito è 32667. Un valore inferiore indica che lo switch ha maggiori probabilità di essere il vPC principale.

Se si modifica la priorità dei dispositivi peer vPC, è possibile che le interfacce della rete diventino attive e inattive. Se si desidera configurare di nuovo la priorità del ruolo in modo che un dispositivo vPC diventi il dispositivo primario, configurare la priorità del ruolo sia sul dispositivo vPC primario con un valore di priorità inferiore che sul dispositivo vPC secondario con il valore più alto. Quindi, arrestare il collegamento peer vPC su entrambi i dispositivi e immettere il comando shutdown, quindi riattivare il canale della porta su entrambi i dispositivi e immettere il comando no shutdown.

Modifica ruolo vPC hitless

La funzionalità di modifica dei ruoli vPC hitless offre un framework per lo switch dei ruoli vPC tra peer vPC senza alcun impatto sui flussi di traffico. Lo scambio di ruoli vPC viene eseguito in base al valore di priorità del ruolo del dispositivo nel dominio vPC. Quando si esegue il comando vpc role priority, un dispositivo peer vPC con priorità inferiore viene selezionato come dispositivo vPC primario.

Per ulteriori informazioni, vedere Scenario di utilizzo del ruolo vPC hitless.

Comportamento dei sistemi vPC quando un collegamento peer vPC non funziona

Quando il collegamento peer vPC si interrompe e il collegamento peer-keepalive vPC è ancora attivo, il dispositivo peer secondario vPC esegue le seguenti operazioni:

1. Sospende le porte membro vPC.
2. Arresta la SVI associata alla VLAN vPC.

Questo comportamento di protezione da vPC reindirizza tutto il traffico da sud a nord verso il dispositivo primario vPC. 

Bit Sticky primario vPC

Il bit Sticky primario di vPC è un meccanismo di protezione programmato introdotto per evitare modifiche inutili ai ruoli (che potrebbero causare interruzioni alla rete) quando lo switch primario viene ricaricato in modo imprevisto. Il bit Sticky primario di vPC consente allo switch attivo di mantenere il suo ruolo PRIMARIO quando uno switch inattivo torna attivo o quando uno switch isolato viene nuovamente integrato nel dominio VPC.

Attivazione/disattivazione bit permanente primario vPC:

  1. Il valore di vPC Primary Sticky Bit è impostato su TRUE in questo scenario:

• L'attuale vPC Primary si riavvia e lo switch abilitato per vPC cambia il suo ruolo da vPC Secondario a vPC Operational Primary. Il bit sticky non viene impostato se il ruolo passa da secondario operativo vPC a primario vPC.
• Uno switch abilitato per vPC cambia il suo ruolo da Nessuno stabilito a vPC primario quando scade il timer di ripristino del ricaricamento (240 sec per impostazione predefinita).

  2. Il valore di vPC Primary Sticky Bit è impostato su FALSE nei seguenti scenari:

• Uno switch abilitato per vPC viene riavviato (per impostazione predefinita, Sticky Bit è impostato su FALSE).
• La priorità del ruolo vPC è stata modificata o immessa di nuovo.

Il bit primario di vPC Sticky è riportato nella struttura dei componenti del software vPC Manager e può essere controllato con questo comando di modalità di esecuzione NX-OS.

Campus_N7K2-VPC# show system internal vpcm info global | include ignore-case sticky
        Sticky Primary: TRUE
Campus_N7K2-VPC#

Ripristino ritardato vPC

Dopo il riavvio e il riavvio di un dispositivo peer vPC, il protocollo di routing ha bisogno di tempo per riconvertirsi. La gamba dei vPC in fase di ripristino può bloccare il traffico instradato dal buco nero dall'accesso all'aggregazione/core fino a quando non viene ristabilita la connettività uplink di layer 3.

La funzione vPC Delay Restore ritarda l'attivazione della gamba dei vPC sul dispositivo peer vPC che viene ripristinato. vPC Delay Restore consente la convergenza dei protocolli di routing di layer 3 prima che autorizzino qualsiasi traffico sulla gamba vPC. Il risultato sono un ripristino più agevole e nessuna perdita di pacchetti durante la fase di ripristino (il traffico viene ancora deviato sul dispositivo peer vPC attivo). Questa funzione è abilitata per impostazione predefinita con un timer predefinito di ripristino vPC di 30 secondi. Il timer può essere sintonizzato su una specifica linea di base di convergenza di layer 3 da 1 a 3600 secondi.

Vlan interfaccia vPC Delay Restore

Per ritardare l'accensione delle interfacce VLAN sul dispositivo peer vPC ripristinato, usare l'opzione interfaces-vlan del comando delay restore. Questa funzione è abilitata per impostazione predefinita con un timer predefinito di ripristino vPC di 10 secondi.

vPC Delay Restore durante l'utilizzo di una configurazione SVI scalata di 4000 SVI

È stato introdotto un nuovo comando delay restore interface-VLAN batch <1-4094> per configurare il pacchetto in modo che visualizzi le interfacce della VLAN o del dominio bridge in un batch di 200 SVI alla volta. Il comando delay restore timer di vPC <Timeout value> può essere configurato su un valore maggiore della somma di tutti i timer batch configurati. Questa operazione viene effettuata in modo che la gamba del VPC venga sollevata solo dopo che tutte le SVI sono salite sul posto per evitare un buco nero del traffico.

Esempio: 4000 Vlan, 200 batch, ritardo di 15 sec  

ripristino ritardato > (4000/2000)x 15

Processo elettorale vPC

In un sistema vPC, un dispositivo peer vPC è definito come primario vPC e uno è definito come secondario vPC, in base a questi parametri e nell'ordine seguente

1. vPC Primary sticky-bit impostato su 0 o 1.
2. Priorità del ruolo vPC definita dall'utente (il software Cisco NX-OS utilizza il valore numerico più basso per selezionare il dispositivo principale).
3. Valore indirizzo MAC di sistema (il software Cisco NX-OS utilizza l'indirizzo MAC più basso per selezionare il dispositivo principale).

In questo diagramma di flusso (immagine 1) sono riepilogati i passaggi che i dispositivi peer vPC devono eseguire durante il processo di selezione dello switch primario vPC.

1. Il primo parametro controllato tra due dispositivi durante il processo di selezione principale di vPC è il bit di Sticky primario di vPC. Se il dispositivo peer vPC ottiene questo confronto, diventa il dispositivo primario vPC indipendentemente dal valore di priorità del ruolo vPC configurato o dagli indirizzi MAC di sistema di entrambi i peer.
2. Se entrambi gli switch peer vPC hanno lo stesso valore di bit permanente, il processo di selezione procede al passaggio successivo per confrontare la priorità del ruolo vPC definita dall'utente.  
3. Se entrambi i ruoli vPC sono configurati con lo stesso valore, il processo di selezione procede confrontando gli indirizzi MAC del sistema.

Immagine 1

Come mostrato nell'immagine, quando sullo switch vPC il bit Sticky di vPC primario è impostato su 1 (condizione TRUE) e il relativo peer con il bit Sticky impostato su 0 (condizione FALSE), il lato TRUE vince la scelta e assume il ruolo di vPC primario.

vPC Peer 1 Sticky Bit impostato su 1	vPC Peer 2 Sticky Bit impostato su 1	Primario vPC
Falso (0)	Falso (0)	Cravatta
Vero (1)	Falso (0)	vPC Peer 1
Falso (0)	Vero (1)	vPC Peer 2
Vero (1)	Vero (1)	Cravatta

Scenario di ripristino vPC

È importante comprendere il processo di elezione vPC e non può essere sottovalutato, soprattutto negli scenari di ripristino vPC.

L'immagine 2 mostra una configurazione VPC tipica, Nexus-01 è il VPC primario e Nexus-02 è il VPC secondario. Per impostazione predefinita, in entrambi i casi il bit di Sticky viene reimpostato su FALSE.

  

 Immagine 2

Come mostrato in questa immagine, Nexus-01 ha ora un'interruzione dell'alimentazione ed è stato isolato dalla rete. Nexus-02 si è promosso a vPC Primary e ha impostato vPC Sticky Bit su TRUE. 

E Nexus-02 diventa Operational Primary, e il bit adesivo è ora impostato su TRUE.

                        

 Immagine 3

Come mostrato in questa immagine, quando Nexus-01 ritorna online dopo il ripristino dell'interruzione di corrente, Nexus-02 conserva il ruolo Operational PRIMARY indipendentemente dalla priorità del suo ruolo (in quanto ha un bit TRUE sticky) e Nexus-01 assume il ruolo SECONDARY quando è in linea. Solo Nexus-01 avvia il processo di inizializzazione VPC, mentre Nexus-02 rimane PRIMARY e inoltra il traffico come di consueto. Pertanto, non si verifica alcun guasto della rete.

Al processo di inizializzazione vPC su Nexus-01, ora dispositivo secondario operativo vPC, sono associati due timer:

• delay restore SVI (10 secondi per impostazione predefinita) 
• delay restore (30 secondi per impostazione predefinita)

Di conseguenza, è possibile prevedere un tempo di ripristino di 40 secondi su Nexus-01 dopo la reintroduzione di Nexus-01 nella rete come dispositivo secondario vPC. Tuttavia, dal momento che Nexus-02 ha il ruolo di principale, tutto il traffico sta passando attraverso Nexus-01 come indicato in precedenza, non si verifica alcuna interruzione della rete. 

 Immagine 4

Esempio di interruzione di rete relativa a un bit di Sticky impostato in modo errato

L'interruzione della rete è causata da un bit sticky impostato in modo non corretto quando uno switch isolato (Nexus-02) viene introdotto di nuovo nel dominio VPC

Tuttavia, è possibile che si verifichi un'interruzione della rete dopo che uno switch isolato è stato introdotto nuovamente nel dominio VPC se i bit adesivi non sono impostati correttamente su entrambi gli switch Nexus. Prima di reintrodurre uno switch isolato nel dominio VPC, il bit sticky dello switch deve essere impostato su FALSE. (Per le procedure di sostituzione di uno chassis N7K, vedere Procedura di sostituzione dello chassis Nexus 7000).

Come mostrato nell'Immagine 5, Nexus-01 è configurato con una priorità di ruolo VPC più alta rispetto a Nexus-02, e Nexus-02 ha il suo Sticky Bit impostato su TRUE. I collegamenti E1/1 ed E1/2 di Nexus-01 sono in stato di inoltro, mentre E1/1 ed E1/2 sono in stato di arresto. 

 Immagine 5

Quando PKA e Peer Link vengono ripristinati, Nexus-02 assume il ruolo PRIMARIO indipendentemente dalla priorità del ruolo (perché ha un bit TRUE sticky) e forza Nexus-01 a diventare SECONDARIO e il processo di inizializzazione VPC inizia su Nexus-01. Pertanto, i collegamenti E1/1 e E1/2 di Nexus-01 vengono sospesi dal VPC e vengono messi in linea dopo la scadenza dei timer di ripristino del relay (40 secondi per impostazione predefinita).  In questo caso, dopo il ripristino della chiave PAK e del collegamento peer, si verifica un'interruzione della rete di 40 secondi, come mostrato nell'immagine 6.

 Immagine 6

Nota: quando un Nexus viene reintrodotto nel dominio vPC, è necessario verificare che non vi siano modifiche al ruolo vPC nel dispositivo vPC attivo. Per evitare una modifica del ruolo vPC quando i bit di Sticky Notes di entrambi gli switch sono impostati sullo stesso valore, il dispositivo vPC attivo deve avere una priorità di ruolo più alta per mantenere il suo ruolo PRIMARIO. Per ulteriori informazioni sul processo di selezione dei ruoli VPC, fare riferimento all'immagine 1 di questo documento.