FlexPod Nexus 5k nel comportamento vPC durante l'interruzione
Sommario
Introduzione
Questo documento delinea il comportamento della rete in reazione a diversi guasti, concentrandosi su Virtual Port-Channel (vPC).
Un'interruzione tipica potrebbe essere un ricaricamento, una perdita di collegamento o una perdita di connettività.
Lo scopo di questo documento è quello di dimostrare la perdita di pacchetti durante scenari comuni.
Topologia
Durante il test, se non diversamente specificato nella topologia.
Le linee verdi e blu indicano un canale di porta vPC da ciascuna interconnessione fabric a entrambi gli switch Nexus.
Non è descritta la rete di gestione fuori banda.
Si tratta di una topologia semplificata comunemente consigliata nelle implementazioni FlexPod, come mostrato ad esempio in:
http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/UCS_CVDs/flexpod_esxi51_ucsm2.html
Componenti usati
Due switch Nexus 5548P.
Due Unified Computing System (UCS) 6120 Fabric Interconnect con software 2.2(4b).
Uno chassis UCS 5108.
Due blade B200M3 con adattatore VIC 1240 e software 2.2(4).
Per eseguire e verificare i test di connettività sono stati installati due blade e il sistema operativo RedHat Enterprise Linux 7.1 è installato.
Configurazione.
Per la configurazione di vPC e portchannel viene utilizzata l'impostazione predefinita.
feature vpc
vpc domain 75
role priority 3000
peer-keepalive destination 10.48.43.79 source 10.48.43.78
delay restore 150
peer-gateway
interface port-channel1
description vPC Peer-Link
switchport mode trunk
spanning-tree port type network
vpc peer-link
Esempio di vPC che porta a UCS Fabric Interconnect (FI) in questo caso bdsol-6120-05—A
interface port-channel101
description bdsol-6120-05-A
switchport mode trunk
spanning-tree port type edge trunk
vpc 101
Test
Verrà eseguito il seguente test.
- Perdita del collegamento dati.
- Upgrade con interruzioni
- Aggiornamento software in servizio (ISSU)
- Perdita del collegamento keepalive peer - interfaccia mgmt0 in caso di topologia/configurazione.
- Perdita del portchannel peer - Port-channel 1 in questa configurazione.
- Disattivazione funzione vPC
Flusso del traffico di base.
Una singola sessione iperf3 viene utilizzata per generare 6,5 gigabit al secondo di traffico TCP di prova per verificare la perdita di frame durante le transizioni.
RedHat2 è bloccato sulla Fabric Interconnect B mentre RedHat1 è bloccato sull'interconnessione A del fabric: questo genera traffico che deve attraversare la porzione di commutazione.
Parametri Iperf3:
- Server: iperf3 -s -i 1
- Client iperf3 -c 10.37.9.131 -t 0 -i 1 -w 1M -V
I suddetti parametri sono stati scelti per consentire un'alta velocità di traffico e una facile individuazione delle perdite dei pacchetti.
La finestra TCP è bloccata per evitare burst di dati per cui iperf è noto. Consentendo l'iperf di eseguire lo sblocco, si potrebbero verificare occasionali cadute nei buffer in entrata lungo il percorso, a seconda della configurazione QoS. I suddetti parametri consentono una velocità sostenuta di 6-7 Gbps senza perdita di frame.
Per verificare, è possibile controllare la velocità cumulativa del traffico sulle interfacce.
bdsol-n5548-07# show interface ethernet 1/1-2 | i rate
30 seconds input rate 5612504 bits/sec, 9473 packets/sec
30 seconds output rate 7037817832 bits/sec, 578016 packets/sec
input rate 5.60 Mbps, 9.38 Kpps; output rate 7.01 Gbps, 576.10 Kpps
30 seconds input rate 7037805336 bits/sec, 578001 packets/sec
30 seconds output rate 5626064 bits/sec, 9489 packets/sec
input rate 7.01 Gbps, 575.71 Kpps; output rate 6.56 Mbps, 9.79 Kpps
L'output precedente mostra 7 Gbps di traffico in entrata sull'interfaccia Ethernet 1/2 e in uscita sull'interfaccia Ethernet 1/1.
Perdita di collegamento dati
Questo test è progettato per verificare il comportamento dei dati se un collegamento che fa parte di vPC viene arrestato.
In questo esempio viene utilizzato Ethernet 1/1, l'interfaccia di output per il traffico di dati, che viene chiusa dalla riga di comando.
bdsol-n5548-07# conf t
Enter configuration commands, one per line. End with CNTL/Z.
bdsol-n5548-07(config)# int et1/1
bdsol-n5548-07(config-if)# shut
In questo caso è stato perso un solo pacchetto, su un flusso di 6,5 Gbps.
Il traffico viene quasi immediatamente bilanciato tra i collegamenti rimanenti in portchannel su UCS, in questo caso utilizzando la porta Ethernet 1/8 (l'unica restante) di UCS FI B fino a Nexus 5548 B, da dove verrà trasportato a UCS FI A utilizzando Ethernet 1/1.
bdsol-n5548-08# show interface ethernet 1/1-2 | i rate
30 seconds input rate 5575896 bits/sec, 9413 packets/sec
30 seconds output rate 6995947064 bits/sec, 574567 packets/sec
input rate 2.21 Mbps, 3.70 Kpps; output rate 2.78 Gbps, 227.99 Kpps
30 seconds input rate 6995940736 bits/sec, 574562 packets/sec
30 seconds output rate 5581920 bits/sec, 9418 packets/sec
input rate 2.78 Gbps, 227.99 Kpps; output rate 2.22 Mbps, 3.71 Kpps
Upgrade o ricaricamento con interruzioni
È possibile emulare un'interruzione combinata dei dati e del control plane eseguendo un aggiornamento dirompente del bdsol-n5548-07 (vPC primario).
È prevista una perdita di traffico.
Dal punto di vista funzionale, questo test equivale a ricaricare un peer vPC.
bdsol-n5548-07# install all kickstart bootflash:n5000-uk9-kickstart.7.1.0.N1.1a.bin system bootflash:n5000-uk9.7.1.0.N1.1a.bin
(...)
Compatibility check is done:
Module bootable Impact Install-type Reason
------ -------- -------------- ------------ ------
1 yes disruptive reset Incompatible image
(...)
Switch will be reloaded for disruptive upgrade.
Do you want to continue with the installation (y/n)? [n] y
Install is in progress, please wait.
Performing runtime checks.
[####################] 100% -- SUCCESS
Setting boot variables.
[####################] 100% -- SUCCESS
Performing configuration copy.
[####################] 100% -- SUCCESS
Finishing the upgrade, switch will reboot in 10 seconds.
Dopo i 10 secondi indicati, il pacchetto viene perso.
Durante questo periodo vengono persi solo 55 pacchetti (su un flusso di 6,6 Gbps).
Se l'iperf3 viene riavviato immediatamente, l'operatore può verificare che il traffico sia effettivamente passato a bdsol-n5548-08.
bdsol-n5548-08# show interface ethernet 1/1-2 | i rate
30 seconds input rate 5601392 bits/sec, 9455 packets/sec
30 seconds output rate 7015307760 bits/sec, 576159 packets/sec
input rate 2.25 Mbps, 3.77 Kpps; output rate 2.81 Gbps, 231.14 Kpps
30 seconds input rate 7015303696 bits/sec, 576152 packets/sec
30 seconds output rate 5605280 bits/sec, 9462 packets/sec
input rate 2.81 Gbps, 231.14 Kpps; output rate 2.25 Mbps, 3.77 Kpps
La velocità del traffico è inferiore a 6 Gb/s poiché il contatore della velocità è in media di oltre 30 secondi.
Collegamento peer vPC non attivo
In questo esempio il collegamento peer vPC diventa inattivo, attivato da una modifica della configurazione.
A quel punto il traffico viene gestito da bdsol-n5548-07, che agisce come vPC secondario.
Sequenza degli eventi.
Il canale porta 1 si blocca.
2015 lug 10 15:00:25 bdsol-n5548-07 %ETHPORT-5-IF_DOWN_CFG_CHANGE: Interface port-channel1 non è attivo (modifica della configurazione)
Poiché bdsol-n5548-07 agisce come secondario, sospenderà i suoi vPC poiché non può garantire una topologia senza loop:
2015 Jul 10 15:00:28 bdsol-n5548-07 %VPC-2-VPC_SUSP_ALL_VPC: Peer-link going down, suspending all vPCs on secondary
2015 Jul 10 15:00:28 bdsol-n5548-07 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface port-channel928 is down (Initializing)
2015 Jul 10 15:00:28 bdsol-n5548-07 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface port-channel102 is down (Initializing)
2015 Jul 10 15:00:28 bdsol-n5548-07 %ETHPORT-5-IF_DOWN_INITIALIZING: Interface port-channel101 is down (Initializing)
Durante questo periodo iperf3 perse una parte del traffico - 90 pacchetti.
Ma è stato in grado di riprendersi abbastanza in fretta.
Poiché i vPC sono sospesi su bdsol-n5548-07, tutto il traffico viene gestito da bdsol-n5548-08
bdsol-n5548-08# show int ethernet 1/1-2 | i rate
30 seconds input rate 5623248 bits/sec, 9489 packets/sec
30 seconds output rate 7036030160 bits/sec, 577861 packets/sec
input rate 2.83 Mbps, 4.74 Kpps; output rate 3.54 Gbps, 290.64 Kpps
30 seconds input rate 7036025712 bits/sec, 577854 packets/sec
30 seconds output rate 5627216 bits/sec, 9498 packets/sec
input rate 3.54 Gbps, 290.64 Kpps; output rate 2.83 Mbps, 4.75 Kpps
Anche in questo caso, la velocità non mostra 6,5 gigabit al secondo immediatamente a causa del calcolo della media di carico.
Ripristino dal collegamento vPC non attivo.
Quando il collegamento peer vPC torna attivo, è possibile che il traffico venga riequilibrato tra i collegamenti e che si verifichi una perdita di pacchetti di breve durata dovuta a modifiche della topologia.
In questo test di laboratorio 1 pacchetto è andato perso.
Aggiornamento software in servizio (ISSU)
In questo test è stato eseguito un aggiornamento di ISSU per verificare l'interruzione del traffico.
I ruoli vPC durante il test sono i seguenti:
bdsol-n5548-07 - primario
bdsol-n5548-08 - secondario.
Per eseguire un'operazione è necessario che siano soddisfatti i criteri definiti dall'ISSU.
Per trovare informazioni sui comandi utilizzati per verificare questi criteri ed eseguire un problema, è stata utilizzata la seguente guida:
Dopo aver eseguito un'operazione ISSU prima sul sistema primario e successivamente sul sistema vPC secondario, non è stato perso alcun pacchetto.
Ciò è dovuto al fatto che l'ISSU non interrompe tutte le funzionalità del data plane e influisce solo sul traffico del control plane.
Problemi noti relativi a ISSU
Funzionalità e licenze di layer 3.
Durante la verifica dell'ISSU è stato necessario risolvere una serie di problemi. Il messaggio "show install all impact ..." potrebbe fornire un output che non è possibile eseguire con la seguente spiegazione: "Installazione senza interruzioni non supportata se L3 è stato abilitato." Nell'ambiente di test, ciò è dovuto al fatto che LAN_BASE_SERVICES_PKG è in uso nel file di licenza installato.
LAN_BASE_SERVICES_PKG include la funzionalità L3 e per eseguire il comando IOS, questo pacchetto deve essere inutilizzato e il file della licenza deve essere cancellato dal dispositivo usando il comando "clear license LICENSEFILE". È possibile che il file di licenza sia attualmente utilizzato dal dispositivo. Per cancellare un file di licenza di questo tipo, è importante controllare quali pacchetti sono in uso usando il comando "show license usage" e disabilitando le funzionalità di questi pacchetti.
Porte STP non edge
Durante i test è stato necessario arrestare anche il canale della porta in direzione nord, in quanto non ha superato il controllo "show spanning-tree issu-impact" non-edge, Criteria 3, e questo avrebbe portato a un upgrade con interruzioni. Questo canale della porta verso nord non è stato elencato come vPC Edge nel comando "show spanning-tree vlan 1".
Perdita del collegamento peer keepalive
Dopo la perdita del collegamento peer keepalive mgmt0, non è stata registrata alcuna interruzione del traffico. In questa topologia, l'interfaccia di gestione (mgmt0) viene utilizzata come collegamento keepalive, pertanto non influisce sul traffico di dati generato durante il test.
I dispositivi rilevano l'interruzione dell'interfaccia mgmt0 e un errore dei pacchetti keepalive peer, ma poiché il collegamento peer è attivo, la comunicazione tra i siti dati può continuare.
2015 Jul 14 12:11:28 bdsol-n5548-07 %IM-5-IM_INTF_STATE: mgmt0 is DOWN in vdc 1
2015 Jul 14 12:11:32 bdsol-n5548-07 %VPC-2-PEER_KEEP_ALIVE_RECV_FAIL: In domain 75, VPC peer keep-alive receive has failed
2015 Jul 14 12:12:07 bdsol-n5548-07 %IM-5-IM_INTF_STATE: mgmt0 is UP in vdc 1
Disattivazione funzionalità vPC
Questo test descrive cosa succede quando il vPC viene disabilitato su uno degli switch durante il trasferimento di dati in tempo reale.
La funzione VPC può essere disabilitata usando il seguente comando nella modalità di configurazione globale:
bdsol-n5548-07(config)# no feature vpc
La disattivazione della funzionalità vPC sul peer vPC primario o secondario comporta la perdita immediata della connettività dei dati. Ciò è dovuto alla natura peer-based di vPC. Non appena la funzione viene disabilitata, tutte le funzionalità vPC sullo switch cessano di funzionare, il collegamento peer si interrompe, lo stato vPC keepalive viene sospeso e il canale porta 101 dell'ambiente di test si interrompe. Ciò è evidente nell'output show vPC dello switch peer per cui è ancora abilitata la funzione vPC.
bdsol-n5548-07# show vpc
Legend:
(*) - local vPC is down, forwarding via vPC peer-link
vPC domain id : 75
Peer status : peer link is down
vPC keep-alive status : Suspended (Destination IP not reachable)
...
vPC status
----------------------------------------------------------------------------
id Port Status Consistency Reason Active vlans
------ ----------- ------ ----------- -------------------------- -----------
101 Po101 down success success -
L'interruzione del traffico, come in precedenza, è di breve durata.
Nelle condizioni di test sopra descritte, 50-80 pacchetti sono stati persi da una singola sessione.
La rimozione del comando "feature vpc" ha causato anche la rimozione della configurazione vPC dai canali delle porte.
Questa configurazione deve essere letta.
Conclusioni
La funzionalità vPC è progettata per offrire prestazioni di resilienza dividendo il traffico di dati in un canale porta tra più dispositivi.
Questa semplice idea richiede complicate implementazioni del control plane.
I test sopra descritti sono stati concepiti per mostrare interruzioni sia al control-plane che al data-plane che possono verificarsi durante il ciclo di vita della feature.
Come previsto, le interruzioni del data plane sono state rilevate e corrette quasi immediatamente, con la perdita di singoli pacchetti durante i test.
Le interruzioni del control plane testate mostrano che vPC mantiene ancora il tempo di convergenza al di sotto del secondo anche quando il control plane è interessato.
Il test più dirompente eseguito, ovvero l'arresto del collegamento peer vPC, combina potenzialmente sia il guasto dei dati che quello del control plane. È stato comunque dimostrato un rapido tempo di convergenza.
Feedback