Contenu

Introduction

Topologie

Tests

Perte de liaison de données

Mise à niveau ou rechargement perturbant

Arrêt de la liaison homologue vPC

Mise à niveau logicielle en service (ISSU)

Problèmes connus avec ISSU

Perte de la liaison de keepalive d'homologue

Désactivation de la fonctionnalité vPC

Conclusion

Discussions connexes de la communauté d’assistance Cisco

Introduction

Ce document décrit le comportement du réseau en réaction à différentes interruptions, en se concentrant sur Virtual Port-Channel (vPC).

Une perturbation typique serait un rechargement, une perte de liaison ou une perte de connectivité.

L'objectif de ce document est de démontrer la perte de paquets lors de scénarios courants.

Topologie

Lors du test, sauf indication contraire, la topologie suivante est utilisée.

Les lignes vertes et bleues indiquent un canal de port vPC de chacune des interconnexions de fabric aux deux commutateurs Nexus.

Le réseau de gestion hors bande n’est pas présenté.

Il s'agit d'une topologie simplifiée généralement recommandée dans les déploiements FlexPod, comme le montrent par exemple :

http://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/UCS_CVDs/flexpod_esxi51_ucsm2.html

Composants utilisés

Deux commutateurs Nexus 5548P.

Deux Unified Computing System (UCS) 6120 Fabric Interconnect exécutant le logiciel 2.2(4b).

Un châssis UCS 5108.

Deux lames B200M3 avec carte VIC 1240 exécutant le logiciel 2.2(4).

Pour effectuer et vérifier les tests de connectivité, deux lames ont été installées et le système d'exploitation RedHat Enterprise Linux 7.1 est installé.

Configuration.

La configuration vPC et portchannel est utilisée par défaut.

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

Exemple de vPC menant à l'interconnexion de fabric UCS (FI) dans ce cas bdsol-6120-05—A

interface port-channel101

description bdsol-6120-05-A

switchport mode trunk

spanning-tree port type edge trunk

vpc 101

Tests

L'essai suivant sera effectué.

- Perte de liaison de données.

- Mise à niveau perturbante

- Mise à niveau logicielle en service (ISSU)

- Perte de la liaison de keepalive homologue - interface mgmt0 dans le cas de cette topologie/configuration.

- Perte de peer portchannel - Port-channel 1 dans cette configuration.

- Désactivation de la fonction vPC

Flux de trafic de base.

Une seule session iperf3 est utilisée pour générer 6,5 gigabits par seconde du trafic TCP de test afin de vérifier la perte de trame pendant les transitions.

RedHat2 est épinglé vers Fabric Interconnect B tandis que RedHat1 est épinglé vers Fabric Interconnect A, ce qui entraîne un trafic qui doit traverser la partie commutation.

Paramètres Iperf3 :

- Serveur : iperf3 -s -i 1

- Client iperf3 -c 10.37.9.131 -t 0 -i 1 -w 1M -V

Les paramètres ci-dessus ont été sélectionnés pour permettre un trafic élevé et une perte de paquets facile à détecter.

La fenêtre TCP est serrée pour éviter les rafales de données que iperf est connu. Permettre à iperf de s'exécuter en mode non clamped pourrait entraîner des pertes occasionnelles dans les tampons d'entrée le long du chemin, selon la configuration QoS. Les paramètres ci-dessus permettent un débit soutenu de 6 à 7 Gbit/s sans perte de trame.

Pour vérifier, nous pouvons vérifier le débit cumulé du trafic sur les interfaces.

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

La sortie ci-dessus montre 7 Gbits/s de trafic entrant sur l'interface Ethernet 1/2 et sortant sur l'interface Ethernet 1/1.

Perte de liaison de données

Ce test est désigné pour tester le comportement des données si une liaison faisant partie de vPC est arrêtée.

Cet exemple utilise Ethernet 1/1, l'interface de sortie pour le trafic de données, il sera arrêté à l'aide de la ligne de commande.

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

Dans ce cas, seul un paquet a été perdu, par inondation de flux de 6,5 Gbits/s.

Le trafic est presque immédiatement équilibré entre les liaisons restantes dans portchannel sur UCS, dans ce cas en utilisant le port Ethernet 1/8 de l'UCS FI B (le seul restant) allant jusqu'au Nexus 5548 B, à partir de là il sera transporté vers l'UCS FI A à l'aide d'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

Mise à niveau ou rechargement perturbant

Une perturbation combinée des données et du plan de contrôle peut être émulée en effectuant une mise à niveau perturbatrice du bdsol-n5548-07 (vPC principal).

La perte de trafic est attendue.

Fonctionnellement, ce test est identique au rechargement d'un homologue 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.

Après les 10 secondes mentionnées, la perte de paquets se produit.

Pendant ce temps, seuls 55 paquets sont perdus (sur le flux de 6,6 Gbits/s).

Si l'iperf3 a été redémarré immédiatement, l'opérateur peut vérifier que le trafic a effectivement basculé vers 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

Le débit de trafic est inférieur à 6 Gbit/s, car le compteur de débit est en moyenne sur 30 secondes.

Arrêt de la liaison homologue vPC

Dans cet exemple, la liaison homologue vPC est désactivée, déclenchée par une modification de configuration.

À ce moment-là, le trafic est géré par bdsol-n5548-07, agissant vPC secondaire.

Séquence d'événements.

Port-channel 1 tombe en panne.

10 juillet 2015 15:00:25 bdsol-n5548-07 %ETHPORT-5-IF_DOWN_CFG_CHANGE : L’interface port-channel1 est désactivée(modification de configuration)

Étant donné que bdsol-n5548-07 agit comme secondaire, il suspendra ses vPC car il ne peut pas garantir une topologie sans perte :

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)

Au cours de cette période, iperf3 a perdu une partie du trafic - 90 paquets.

Mais il a pu se rétablir assez rapidement.

Puisque les vPC sont suspendus sur bdsol-n5548-07, tout le trafic est traité par 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

Encore une fois, le débit ne montre pas 6,5 gigabits par seconde immédiatement en raison du calcul de la moyenne de charge.

Récupération à partir de la liaison vPC arrêtée.

Lorsque la liaison homologue vPC redevient active, le trafic peut être rééquilibré entre les liaisons et une perte de paquets de courte durée due à une modification de la topologie peut être attendue.

Dans le cas de ce test de TP, le paquet 1 a été perdu.

Mise à niveau logicielle en service (ISSU)

Au cours de ce test, une mise à niveau ISSU a été effectuée afin de vérifier l'interruption du trafic.

Les rôles vPC au cours de ce test sont les suivants :

bdsol-n5548-07 - primaire

bdsol-n5548-08 - secondaire.

Pour exécuter un critère défini par l'ISSU, il faut respecter.

Afin de trouver des informations sur les commandes utilisées pour vérifier ces critères et exécuter un ISSU, le guide suivant a été utilisé :

http://www.cisco.com/c/en/us/td/docs/switches/datacenter/nexus5500/sw/upgrade/705_N1_1/n5500_upgrade_downgrade_700.html#pgfId-727913.

Après avoir exécuté un ISSU d'abord sur le terminal principal et ensuite sur le terminal vPC secondaire, aucun paquet n'a été perdu.

Cela est dû au fait que la fonctionnalité ISSU de tous les plans de données reste inchangée et que seul le trafic du plan de contrôle serait affecté.

Problèmes connus avec ISSU

Fonctionnalités et licences de couche 3.

Au cours du test ISSU, un certain nombre de problèmes devaient être résolus. La commande « show install all impact... » peut fournir un résultat que ISSU ne peut pas être exécuté avec l'explication suivante : « Installation sans interruption non prise en charge si L3 a été activé. » Dans l'environnement de test, cela est dû au fait que LAN_BASE_SERVICES_PKG est utilisé dans le fichier de licence installé.

LAN_BASE_SERVICES_PKG inclut la fonctionnalité de couche 3 et pour exécuter le ISSU, ce package doit être inutilisé et le fichier de licence doit être effacé du périphérique à l'aide de la commande clear license LICENSEFILE. Il est possible que le fichier de licence soit actuellement utilisé par le périphérique. Pour effacer un tel fichier de licence, il est important de vérifier quels paquets sont utilisés en utilisant la commande show license usage et en désactivant les fonctionnalités de ces paquets.

Ports STP non Edge

Au cours des tests, il a également été nécessaire d'arrêter le port-channel vers le nord car il n'a pas réussi la vérification « show spanning-tree issu-impact » non-edge, Critère 3, et cela aurait conduit à une mise à niveau perturbatrice. Ce port-channel vers le nord ne figure pas dans la liste des périphériques vPC dans la commande show spanning-tree vlan 1.

Perte de la liaison de keepalive d'homologue

Après la perte de la liaison mgmt0 de keepalive homologue, aucune interruption du trafic n'a été enregistrée. Dans cette topologie, l'interface de gestion (mgmt0) est utilisée comme liaison keepalive, ce qui n'a pas d'impact sur le trafic de données généré lors du test.

Les périphériques remarquent que l'interface mgmt0 est désactivée et que les keepalives d'homologue échouent, mais comme la liaison d'homologue est active, la communication de la place de données peut continuer.

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

Désactivation de la fonctionnalité vPC

Ce test décrit ce qui se passe lorsque vPC est désactivé sur l'un des commutateurs pendant le transfert de données en direct.

La fonctionnalité VPC peut être désactivée à l'aide de la commande suivante en mode de configuration globale :

bdsol-n5548-07(config)# no feature vpc

La désactivation de la fonctionnalité vPC sur un homologue vPC principal ou secondaire entraîne une perte instantanée de la connectivité des données. Cela est dû à la nature homologue de vPC. Dès que la fonctionnalité est désactivée, toutes les fonctionnalités vPC du commutateur cessent de fonctionner, la liaison homologue tombe en panne, l'état keepalive vPC est suspendu et le port-channel 101 de l'environnement de test est désactivé. Ceci est évident dans la sortie show vPC du commutateur homologue qui a toujours la fonctionnalité vPC activée.

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 -

Comme avant, l'interruption de la circulation n'est que de courte durée.

Dans les conditions de test susmentionnées, 50 à 80 paquets ont été perdus lors d’une seule session.

La suppression de la commande feature vpc a également entraîné la suppression de la configuration vPC des canaux de port.

Cette configuration doit être lue.

Conclusion

La fonctionnalité vPC est conçue pour fournir des performances de résilience en divisant le trafic de données dans un canal de port entre plusieurs périphériques.

Cette idée simple nécessite des implémentations de plan de contrôle compliquées.

Les essais ci-dessus étaient destinés à montrer des perturbations du plan de contrôle et du plan de données qui peuvent survenir pendant le cycle de vie de la fonction.

Comme prévu, les perturbations du plan de données ont été détectées et corrigées presque immédiatement, avec des paquets uniques perdus dans les tests.

Les perturbations du plan de contrôle testées montrent que vPC conserve un temps de convergence inférieur à la seconde, même lorsque le plan de contrôle est affecté.

Le test le plus perturbateur effectué - la liaison homologue vPC en cours d'arrêt - combine potentiellement les défaillances du plan de contrôle et des données. Un temps de convergence encore rapide a été démontré.