Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.
Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.
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.
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
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 :
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.
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
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.
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.
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é :
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é.
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.
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
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.
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é.