Comprendre la prévention des boucles VPC Nexus

Introduction

Ce document décrit les scénarios dans lesquels l'évitement de boucle vPC peut avoir un impact sur le transfert du trafic dans les conceptions de réseau de couche 3 basées sur Nexus.

Conditions préalables

Exigences

Cisco vous recommande de prendre connaissance des rubriques suivantes :

• CLI du système d'exploitation Nexus
• Concepts vPC

Composants utilisés

Les informations contenues dans ce document sont basées sur les versions de matériel et de logiciel suivantes :

• Logiciels 10.4(4)

• Matériel N9K-C9364C-GX

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. Si votre réseau est en ligne, assurez-vous de bien comprendre l’incidence possible des commandes.

Informations générales

Dans les environnements de data center actuels, la technologie Cisco Nexus Virtual Port Channel (vPC) est essentielle pour permettre la redondance et l'équilibrage de charge. En permettant aux connexions à deux commutateurs Nexus distincts de fonctionner comme un seul canal de port logique, vPC simplifie l'architecture réseau et améliore la fiabilité des périphériques en aval. Toutefois, certains détails de configuration peuvent présenter des difficultés opérationnelles.

Ce document explore les scénarios dans lesquels l'évitement de boucle vPC devient important et examine son impact sur le transfert de trafic. Une compréhension claire de ce mécanisme est essentielle pour les ingénieurs réseau qui cherchent à concevoir et à maintenir une connectivité de couche 3 robuste et efficace dans une infrastructure basée sur Nexus, ce qui permet d'éviter les interruptions de trafic et de maintenir des performances réseau optimales.

Problème

Dans un environnement Cisco Nexus utilisant vPC, les opérateurs réseau peuvent observer un comportement de transfert de trafic inattendu provoqué par la règle d'évitement de boucle vPC. Lorsque le trafic circule d'un homologue vPC à un autre via la liaison homologue vPC, il ne peut pas sortir via un canal de port vPC actif sur les deux commutateurs. Par conséquent, les périphériques dépendant de ce chemin pour la connectivité peuvent subir des paquets abandonnés ou une perte de connectivité, même si toutes les liaisons physiques semblent actives.

La compréhension et la prise en compte de la règle d'évitement des boucles vPC sont essentielles pour la conception et le dépannage des topologies de réseau résilientes, car la non-prise en compte de ce comportement peut entraîner des interruptions de service inattendues et rendre le diagnostic des problèmes de réseau plus difficile.

Diagramme du réseau

Dans cette topologie, le domaine vPC est créé par N9K-C9364C-1 et N9K-C9364C-2. Les deux commutateurs sont configurés avec les VLAN 100 et 200 en tant que VLAN vPC, et des interfaces SVI sont configurées pour chaque VLAN. Le domaine vPC est responsable du routage inter-VLAN entre ces VLAN. Sauf indication contraire, l'IP virtuelle HSRP (VIP) partagée entre les commutateurs homologues vPC est utilisée comme tronçon suivant pour la route par défaut par les autres commutateurs de la topologie.

• Configuration SVI N9K-C9364C-1

interface Vlan100
no shutdown
no ip redirects
adresse ip 192.168.100.1/24
no ipv6 redirects
hsrp 100
ip 192.168.100.254

interface Vlan200
no shutdown
no ip redirects
adresse ip 192.168.200.1/24
no ipv6 redirects
hsrp 200
ip 192.168.200.254

• Configuration SVI N9K-C9364C-2

interface Vlan100
no shutdown
no ip redirects
adresse ip 192.168.100.2/24
no ipv6 redirects
hsrp 100
ip 192.168.100.254

interface Vlan200
no ip redirects
adresse ip 192.168.200.2/24
no ipv6 redirects
hsrp 200
ip 192.168.200.254

Scénarios

Scénario 1 : L'interface SVI pour le VLAN vPC est administrativement désactivée sur l'homologue vPC

a) Le trafic routé de vPC à vPC est affecté

Dans un scénario de travail, N9K-C9504-4 (VLAN 200) peut envoyer une requête ping à N9K-C9364C-3 (VLAN 100). Traceroute indique que le chemin de connexion passe par 192.168.200.2, qui est attribué à N9K-C9364C-2.

N9K-C9504-4# ping 192.168.100.10
PING 192.168.100.10 (192.168.100.10): 56 data bytes
64 bytes from 192.168.100.10: icmp_seq=0 ttl=253 time=8.48 ms
64 bytes from 192.168.100.10: icmp_seq=1 ttl=253 time=0.618 ms
64 bytes from 192.168.100.10: icmp_seq=2 ttl=253 time=0.582 ms
64 bytes from 192.168.100.10: icmp_seq=3 ttl=253 time=0.567 ms
64 bytes from 192.168.100.10: icmp_seq=4 ttl=253 time=0.55 ms

--- 192.168.100.10 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.55/2.159/8.48 ms
N9K-C9504-4#

N9K-C9504-4# traceroute 192.168.100.10
traceroute to 192.168.100.10 (192.168.100.10), 30 hops max, 40 byte packets
1 192.168.200.2 (192.168.200.2) 1.129 ms 0.602 ms 0.724 ms    <<<---- SVI 200 on N9K-C9364C-2
2 192.168.100.10 (192.168.100.10) 1.001 ms 0.657 ms 0.588 ms

À ce stade, le flux de trafic fonctionne de la manière suivante :

• N9K-C9364C-2 reçoit le trafic de 192.168.200.20 destiné à 192.168.100.10, avec l'adresse MAC de destination définie sur l'adresse MAC virtuelle (VMAC) HSRP partagée au sein du domaine vPC.
• Comme HSRP fonctionne en mode actif-actif du point de vue du plan de données sur le vPC, N9K-C9364C-2 achemine le trafic du VLAN 200 vers le VLAN 100 et le transfère via le vPC 10.

Imaginez un scénario dans lequel l'interface SVI 200 est arrêtée sur N9K-C9364C-2, mais reste active sur N9K-C9364C-1 :

N9K-C9364C-1# show ip interface brief

IP Interface Status for VRF "default"(1)
Interface IP Address Interface Status
Vlan100 192.168.100.1 protocol-up/link-up/admin-up 
Vlan200 192.168.200.1 protocol-up/link-up/admin-up <<<---- SVI 200 is up
N9K-C9364C-1#

N9K-C9364C-2# show ip interface brief

IP Interface Status for VRF "default"(1)
Interface IP Address Interface Status
Vlan100 192.168.100.2 protocol-up/link-up/admin-up 
Vlan200 192.168.200.2 protocol-down/link-down/admin-down  <<<---- SVI 200 is down
N9K-C9364C-2#

En raison de la différence d'état opérationnel des interfaces SVI entre les homologues vPC, une incohérence de type 2 est détectée dans le domaine vPC :

N9K-C9364C-1# show vPC
Legend:
(*) - local vPC is down, forwarding via vPC peer-link

vPC domain id : 100 
Peer status : peer adjacency formed ok 
vPC keep-alive status : peer is alive 
Configuration consistency status : success 
Per-vlan consistency status : success 
Type-2 consistency status : failed 
Type-2 inconsistency reason : SVI type-2 configuration incompatible
vPC role : primary 
Number of vPCs configured : 2 
Peer Gateway : Enabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Delay-restore Orphan-port status : Timer is off.(timeout = 0s)
Operational Layer3 Peer-router : Disabled
Virtual-peerlink mode : Disabled

vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans 
-- ---- ------ -------------------------------------------------
1 Po100 up 1,100,200

vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
10 Po10 up success success 1,100,200 
20 Po20 up success success 1,100,200
N9K-C9364C-1#

N9K-C9364C-2# show vPC 
Legend:
(*) - local vPC is down, forwarding via vPC peer-link

vPC domain id : 100 
Peer status : peer adjacency formed ok 
vPC keep-alive status : peer is alive 
Configuration consistency status : success 
Per-vlan consistency status : success 
Type-2 consistency status : failed 
Type-2 inconsistency reason : SVI type-2 configuration incompatible
vPC role : secondary 
Number of vPCs configured : 2 
Peer Gateway : Enabled
Dual-active excluded VLANs : -
Graceful Consistency Check : Enabled
Auto-recovery status : Disabled
Delay-restore status : Timer is off.(timeout = 30s)
Delay-restore SVI status : Timer is off.(timeout = 10s)
Operational Layer3 Peer-router : Disabled
Virtual-peerlink mode : Disabled

vPC Peer-link status
---------------------------------------------------------------------
id Port Status Active vlans 
-- ---- ------ -------------------------------------------------
1 Po100 up 1,100,200

vPC status
----------------------------------------------------------------------------
Id Port Status Consistency Reason Active vlans
-- ------------ ------ ----------- ------ ---------------
10 Po10 up success success 1,100,200 
20 Po20 up success success 1,100,200 

N9K-C9364C-2#

À ce stade, le trafic de 192.168.200.20 à 192.168.100.10 n'aboutit plus :

N9K-C9504-4# ping 192.168.100.10
PING 192.168.100.10 (192.168.100.10): 56 data bytes
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out

--- 192.168.100.10 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss
N9K-C9504-4#

Une requête ping colorée (une requête ping avec une taille MTU spécifiée) est utilisée pour tracer le chemin emprunté par ce trafic :

N9K-C9504-4# ping 192.168.100.10 count 100 timeout 0 packet-size 1030
PING 192.168.100.10 (192.168.100.10): 1030 data bytes
Request 0 timed out
Request 1 timed out
---- snip -----
Request 98 timed out
Request 99 timed out

--- 192.168.100.10 ping statistics ---
100 packets transmitted, 0 packets received, 100.00% packet loss
N9K-C9504-4# ^C
N9K-C9504-4#

Selon les compteurs d'interface sur N9K-C9364C-2, ce trafic est reçu sur le port-channel 20 et transmis au port-channel 100 (la liaison entre homologues vPC) :

N9K-C9364C-2# show interface port-channel 20 counters detailed all | i "1024 to|po" ; sh int port-channel 10 counters detailed all | i "1024 to|po" ; sh int port-channel 100 counters detailed all | i "1024 to|po"
port-channel20
52. Rx Packets from 1024 to 1518 bytes: = 100    <<<----- Ingress vPC po20
60. Tx Packets from 1024 to 1518 bytes: = 0
port-channel10
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 0
port-channel100
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 100 <<<----- Egress po100 (vPC peer-link)
N9K-C9364C-2#

Ce comportement se produit parce que SVI 200 est arrêté sur N9K-C9364C-2, empêchant le routage local du trafic pour VLAN 200. Dans ce scénario, le trafic est ponté à travers la liaison homologue vPC vers N9K-C9364C-1, de sorte que le périphérique effectue le routage inter-VLAN.

En examinant les compteurs d'interface sur N9K-C9364C-1, il est confirmé que les paquets atteignent ce périphérique via la liaison entre homologues vPC. Cependant, il n'y a aucun paquet sortant observé sur le port-channel 10 vPC, qui se connecte à 192.168.100.10.

N9K-C9364C-1# show interface port-channel 20 counters detailed all | i "1024 to|po" ; sh int port-channel 10 counters detailed all | i "1024 to|po" ; sh int port-channel 100 counters detailed all | i "1024 to|po"
port-channel20
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 0
port-channel10
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 0  <<<----- Expected egress vPC po10. No packets!!!
port-channel100
52. Rx Packets from 1024 to 1518 bytes: = 100 <<<----- Ingress po100 (vPC peer-link)
60. Tx Packets from 1024 to 1518 bytes: = 0
N9K-C9364C-1#

Même si le trafic arrive à N9K-C9364C-1 via la liaison homologue vPC, il n'est pas transféré au port-channel 10 vPC. En effet, le bit egress_vsl_drop est défini sur 1 pour ce vPC, ce qui se produit lorsque le même port-channel vPC est opérationnel sur le commutateur homologue (dans ce cas, N9K-C9364C-2).

N9K-C9364C-1# show system internal eltm info interface Po10 | i i vsl
egress_vsl_drop = 1
N9K-C9364C-1#

N9K-C9364C-1# show system internal vPCm info interface Po10 | i "Peer stat|Inform|vPC sta"
IF Elem Information:
MCECM DB Information:
vPC state: Up Old Compat Status: Pass
vPC Peer Information:
Peer state: Up         <<<------------- vPC 10 up on peer 
PSS Information:
vPC state: Up Old Compat Status: Pass
vPC Peer Information:
Peer state: Up         <<<------------- vPC 10 up on peer 
Shared Database Information:
Application database Information:
Lock Information:
N9K-C9364C-1# 

Topologie illustrant le flux de trafic et le point auquel il est abandonné :

Conclusion: 

N9K-C9364C-1 abandonne le trafic en raison de la règle d'évitement de boucle vPC : Le trafic reçu sur la liaison entre homologues vPC ne peut pas être transféré vers un canal de port vPC actif sur les deux commutateurs."Pour éviter ce problème, assurez-vous que l'état administratif des interfaces SVI est cohérent sur les deux commutateurs et que leurs configurations sont symétriques.

b) Le trafic routé de l'hôte orphelin vers l'hôte vPC est affecté

En considérant le même scénario où SVI 200 est arrêté sur N9K-C9364C-2, mais reste actif sur N9K-C9364C-1. Une requête ping de N9K-C9504-6 (VLAN 200) à N9K-C9364C-3 (VLAN 100) échoue.

N9K-C9504-6# ping 192.168.100.10 packet-size 1030 count 100 timeout 0
PING 192.168.100.10 (192.168.100.10): 1030 data bytes
Request 0 timed out
Request 1 timed out
Request 2 timed out
---- snip -----
Request 97 timed out
Request 98 timed out
Request 99 timed out

--- 192.168.100.10 ping statistics ---
100 packets transmitted, 0 packets received, 100.00% packet loss
N9K-C9504-6#

Une requête ping colorée (une requête ping avec une taille MTU spécifiée) est utilisée pour tracer le chemin emprunté par ce trafic :

N9K-C9364C-2# show interface eth1/59 counters detailed all | i "1024 to|Eth" ; sh int port-channel 10 counters detailed all | i "1024 to|po" ; sh int port-channel 100 counters detailed all | i "1024 to|po"
Ethernet1/59
52. Rx Packets from 1024 to 1518 bytes: = 100 <<<----- Ingress port to N9K-C9504-6
60. Tx Packets from 1024 to 1518 bytes: = 0
port-channel10
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 0
port-channel100
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 100 <<<----- Egress po100 (vPC peer-link)
N9K-C9364C-2#

N9K-C9364C-1# show interface port-channel 10 counters detailed all | i "1024 to|po" ; sh int port-channel 100 counters detailed all | i "1024 to|po"
port-channel10
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 0 <<<----- Expected egress vPC po10. No packets!!!
port-channel100
52. Rx Packets from 1024 to 1518 bytes: = 100 <<<----- Ingress po100 (vPC peer-link)
60. Tx Packets from 1024 to 1518 bytes: = 0
N9K-C9364C-1#

Même si le trafic arrive à N9K-C9364C-1 via la liaison homologue vPC, il n'est pas transféré au port-channel 10 vPC. En effet, le bit egress_vsl_drop est défini sur 1 pour ce vPC, ce qui se produit lorsque le même port-channel vPC est opérationnel sur le commutateur homologue (dans ce cas, N9K-C9364C-2).

N9K-C9364C-1# show system internal eltm info interface Po10 | i i vsl
egress_vsl_drop = 1
N9K-C9364C-1#

N9K-C9364C-1# show system internal vpcm info interface Po10 | i "Peer stat|Inform|vPC sta"
IF Elem Information:
MCECM DB Information:
vPC state: Up Old Compat Status: Pass
vPC Peer Information:
Peer state: Up <<<------------- vPC 10 up on peer 
PSS Information:
vPC state: Up Old Compat Status: Pass
vPC Peer Information:
Peer state: Up <<<------------- vPC 10 up on peer 
Shared Database Information:
Application database Information:
Lock Information:
N9K-C9364C-1# 

Topologie illustrant le flux de trafic et le point auquel il est abandonné :

Conclusion: 

Même si le trafic provient d'un hôte orphelin connecté à N9K-C9364C-2, il est abandonné par N9K-C9364C-1 en raison de la règle d'évitement de boucle vPC : Le trafic reçu sur la liaison entre homologues vPC ne peut pas être transféré vers un canal de port vPC actif sur les deux commutateurs. Le fait que le port d'entrée sur le commutateur homologue soit un vPC ou un port orphelin n'a pas d'importance ; Ce qui importe, c'est que le trafic entre via la liaison entre homologues vPC et soit destiné à un vPC actif sur les deux commutateurs. Pour éviter ce problème, assurez-vous que le statut administratif des interfaces SVI est cohérent sur les deux commutateurs et que leurs configurations sont symétriques. 

Scénario 2 : tous les vPC et les interfaces SVI sont activés - Points de tronçon suivant vers l'homologue vPC

Dans ce scénario, toutes les interfaces SVI et tous les canaux de port vPC du domaine vPC sont activés. Cependant, N9K-C9504-5, qui est connecté à N9K-C9364C-1 via une interface de couche 3, ne peut pas envoyer de requête ping à Loopback 0 sur N9K-C9364C-3. 

Une commande traceroute à partir de N9K-C9504-5 indique que le paquet atteint d’abord son tronçon suivant immédiat à l’adresse 192.168.1.2, puis passe à l’adresse 192.168.100.2, qui est associée à N9K-C9364C-2.

N9K-C9504-5# traceroute 172.16.100.10
traceroute to 172.16.100.10 (172.16.100.10), 30 hops max, 40 byte packets
1 192.168.1.2 (192.168.1.2) 1.338 ms 0.912 ms 0.707 ms
2 192.168.100.2 (192.168.100.2) 0.948 ms 0.751 ms 0.731 ms
3 * * *
4 * * *
N9K-C9504-5#

La vérification du saut suivant à partir de N9K-C9364C-1 (le saut initial pour ce trafic) montre que la destination est accessible via 192.168.100.2, ce qui correspond à SVI 100 sur N9K-C9364C-2.

N9K-C9364C-1# show ip route 172.16.100.10
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

172.16.100.0/24, ubest/mbest: 1/0
*via 192.168.100.2, [1/0], 00:05:05, static
N9K-C9364C-1#

Une requête ping colorée (une requête ping avec une taille MTU spécifiée) est utilisée pour tracer le chemin emprunté par ce trafic :

N9K-C9364C-1# show interface e1/58 counters detailed all | i "1024 to|Eth" ; sh int port-channel 100 counters detailed all | i "1024 to|po" ; sh int port-channel 10 counters detailed all | i "1024 to|po"
Ethernet1/58
52. Rx Packets from 1024 to 1518 bytes: = 100 <<<----- Ingress Eth1/58
60. Tx Packets from 1024 to 1518 bytes: = 0
port-channel100
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 100 <<<----- Egress po100 (vPC peer-link)
port-channel10
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 0
N9K-C9364C-1# 

N9K-C9364C-2# sh int port-channel 100 counters detailed all | i "1024 to|po" ; sh int port-channel 10 counters detailed all | i "1024 to|po"
port-channel100
52. Rx Packets from 1024 to 1518 bytes: = 100 <<<----- Ingress po100 (vPC peer-link)
60. Tx Packets from 1024 to 1518 bytes: = 0
port-channel10
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 0 <<<----- Egress vPC po10, no packets!!!
N9K-C9364C-2# 

Même si le trafic arrive à N9K-C9364C-2 via la liaison homologue vPC, il n'est pas transféré au port-channel 10 vPC. En effet, le bit egress_vsl_drop est défini sur 1 pour ce vPC, ce qui se produit lorsque le même port-channel vPC est opérationnel sur le commutateur homologue (dans ce cas, N9K-C9364C-1).

N9K-C9364C-2# show system internal eltm info interface Po10 | i i vsl
egress_vsl_drop = 1
N9K-C9364C-2# 

N9K-C9364C-2# show system internal vPCm info interface Po10 | i "Peer stat|Inform|vPC sta"
IF Elem Information:
MCECM DB Information:
vPC state: Up Old Compat Status: Pass
vPC Peer Information:
Peer state: Up <<<------------- vPC 10 up on peer 
PSS Information:
vPC state: Up Old Compat Status: Pass
vPC Peer Information:
Peer state: Up <<<------------- vPC 10 up on peer 
Shared Database Information:
Application database Information:
Lock Information:
N9K-C9364C-2# 

Topologie illustrant le flux de trafic et le point auquel il est abandonné :

Conclusion: 

Le problème est observé, car N9K-C9364C-1 utilise N9K-C9364C-2 comme tronçon suivant, envoyant le trafic sur la liaison entre homologues vPC avant qu'il ne tente de sortir par vPC 10. Le trafic est abandonné en raison de la règle d'évitement de boucle vPC : Le trafic reçu sur la liaison entre homologues vPC ne peut pas être transféré à partir d'un canal de port vPC actif sur les deux commutateurs. Pour éviter ce problème, assurez-vous que les routes (dynamiques ou statiques) avec un saut suivant via un canal de port vPC sont configurées sur les deux commutateurs homologues vPC, de sorte que le trafic n'a pas besoin de traverser la liaison entre homologues vPC et de sortir sur un vPC.

Scénario 3 : tous les vPC et les interfaces SVI sont activés - la fonctionnalité de passerelle homologue VPC est désactivée

Dans ce scénario, toutes les interfaces SVI et tous les canaux de port vPC sont actifs sur le domaine vPC ; Cependant, la fonctionnalité de passerelle homologue vPC est désactivée. À ce stade, N9K-C9504-4 (VLAN 200) ne peut pas envoyer de requête ping à N9K-C9364C-3 (VLAN 100).

N9K-C9504-4# ping 192.168.100.10
PING 192.168.100.10 (192.168.100.10): 56 data bytes
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out

--- 192.168.100.10 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss
N9K-C9504-4#

La vérification du tronçon suivant à partir de N9K-C9504-4 montre que la destination est accessible via 192.168.200.2, ce qui correspond à SVI 200 sur N9K-C9364C-2 et connecté via le canal de port 20 vPC.

N9K-C9504-4# show ip route 192.168.100.10
IP Route Table for VRF "default"
'*' denotes best ucast next-hop
'**' denotes best mcast next-hop
'[x/y]' denotes [preference/metric]
'%<string>' in via output denotes VRF <string>

0.0.0.0/0, ubest/mbest: 1/0
*via 192.168.200.2, [1/0], 01:22:46, static
N9K-C9504-4#

N9K-C9504-4# show ip arp detail | i 192.168.200.2
192.168.200.2 00:08:05 a478.06de.7edb Vlan200 port-channel20 default

Une requête ping colorée (une requête ping avec une taille de MTU spécifiée) est utilisée pour tracer le chemin emprunté par ce trafic. Ici, les compteurs d'interface révèlent que N9K-C9364C-1 reçoit le trafic de 192.168.200.20 à 192.168.100.10 sur le port-channel 20 et l'envoie au peer-link vPC (port-channel100)

N9K-C9364C-1# show interface port-channel 20 counters detailed all | i "1024 to|po" ; sh int port-channel 10 counters detailed all | i "1024 to|po" ; sh int port-channel 100 counters detailed all | i "1024 to|po"
port-channel20
52. Rx Packets from 1024 to 1518 bytes: = 100   <<<----- Ingress vPC 20
60. Tx Packets from 1024 to 1518 bytes: = 0
port-channel10
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 0
port-channel100
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 100   <<<----- Egress po100 (vPC peer-link)
N9K-C9364C-1#

N9K-C9364C-2 reçoit le trafic sur la liaison entre homologues vPC (port-channel100), mais ne le transfère pas vers le port-channel 10 vPC.

N9K-C9364C-2# show int port-channel 20 counters detailed all | i "1024 to|po" ; sh int port-channel 10 counters detailed all | i "1024 to|po" ; sh int port-channel 100 counters detailed all | i "1024 to|po"
port-channel20
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 0
port-channel10
52. Rx Packets from 1024 to 1518 bytes: = 0
60. Tx Packets from 1024 to 1518 bytes: = 0   <<<----- Egress vPC po10, no packets!!!
port-channel100
52. Rx Packets from 1024 to 1518 bytes: = 100  <<<----- Ingress po100 (vPC peer-link)
60. Tx Packets from 1024 to 1518 bytes: = 0
N9K-C9364C-2# 

Même si le trafic arrive à N9K-C9364C-2 via la liaison homologue vPC, il n'est pas transféré au port-channel 10 vPC. En effet, le bit egress_vsl_drop est défini sur 1 pour ce vPC, ce qui se produit lorsque le même port-channel vPC est opérationnel sur le commutateur homologue (dans ce cas, N9K-C9364C-1).

Comme la passerelle homologue est désactivée, N9K-C9364C-1 peut uniquement acheminer les paquets adressés à sa propre adresse MAC locale. Par conséquent, les paquets destinés à a478.06de.7edb (MAC de N9K-C9364C-2) sont transférés par N9K-C9364C-1 via la liaison homologue vPC.

N9K-C9364C-1# show mac address-table add a478.06de.7edb
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
---------+-----------------+--------+---------+------+----+------------------
* 100 a478.06de.7edb static - F F vPC Peer-Link(R)
* 200 a478.06de.7edb static - F F vPC Peer-Link(R)
N9K-C9364C-1# 

Topologie illustrant le flux de trafic et le point auquel il est abandonné :

Conclusion: 

Si la passerelle homologue est activée, le trafic routé destiné à l'adresse MAC de l'homologue vPC est traité localement en programmant l'adresse MAC homologue en tant que passerelle. Cela empêche la liaison entre homologues vPC d'être utilisée dans le chemin de trafic et évite les pertes causées par la règle d'évitement de boucle vPC. Pour éviter de tels problèmes, assurez-vous que la fonctionnalité de passerelle homologue vPC est activée sur le domaine vPC.

Présentation de la solution

• Assurez la cohérence de la configuration SVI sur les VLAN vPC.

Les configurations d'interface virtuelle commutée asymétrique (SVI) entre les commutateurs homologues vPC peuvent entraîner des problèmes critiques de transfert du trafic, notamment le blackholing. Une pratique courante mais non prise en charge qui contribue à cette condition est de tester le basculement entre homologues vPC en arrêtant les interfaces SVI d'un côté. Cette méthode crée un état SVI asymétrique que l'architecture vPC Nexus ne prend pas en charge, ce qui entraîne des défaillances de transfert et de blocage du trafic. Assurez-vous que la configuration SVI est toujours cohérente sur tous les VLAN vPC pour lesquels le routage est nécessaire.

• Activez la passerelle homologue sur le domaine vPC.

La fonctionnalité de passerelle homologue est une amélioration essentielle dans les déploiements Cisco Nexus vPC. Lorsqu'elle est activée sur le domaine vPC, elle permet à chaque commutateur homologue vPC d'accepter et de traiter les paquets destinés à l'adresse MAC virtuelle de l'homologue vPC. Cela signifie que l'un des homologues vPC peut répondre au trafic lié à la passerelle, quel que soit le commutateur qui a reçu le paquet à l'origine.  Si la passerelle d'homologue n'est pas activée, certains types de trafic, tels que les paquets envoyés à l'adresse MAC de la passerelle par défaut, peuvent être abandonnés s'ils arrivent sur un homologue et doivent sinon traverser la liaison d'homologue et quitter un port membre vPC. Assurez-vous que la passerelle d'homologue vPC est configurée sur le domaine vPC.

Informations connexes

Comprendre les améliorations du canal de port virtuel (vPC)

Meilleures pratiques pour les canaux de port virtuel (vPC) sur Nexus

Fonction de passerelle homologue sur le Nexus 7000