Vérification du comportement de synchronisation des tables ARP et MAC de la gamme Nexus 9000

Introduction

Ce document décrit un comportement de synchronisation spécifique observé dans les tables d'adresses ARP et MAC des commutateurs Cisco Nexus 9000. 

Conditions préalables

Exigences

Pour tirer pleinement parti des discussions dans ce document, le lecteur peut avoir une compréhension de base de plusieurs concepts et technologies clés :

1. Virtual Port Channel (vPC) : familiarité avec la configuration, la configuration et la gestion opérationnelle des vPC, car ils sont essentiels à la compréhension des scénarios réseau décrits.

2. Fonctionnalité de passerelle homologue de canal de port virtuel NX-OS : connaissance du fonctionnement de la fonctionnalité de passerelle homologue dans une configuration vPC, y compris son rôle dans les mécanismes de transfert de trafic et de redondance.

3. Système d'exploitation Cisco Nexus (NX-OS) : compréhension pratique de NX-OS, en se concentrant sur son interface de ligne de commande et sur les configurations types pertinentes pour les commutateurs de la gamme Nexus 9000.

Composants utilisés

• Modèles de commutateurs : commutateurs des gammes Nexus 3000 et Nexus 9000 (première génération uniquement), qui sont essentiels pour illustrer le comportement spécifique des tables ARP et MAC en raison de leurs contraintes ASIC uniques.

• Virtual Port Channel (vPC) : configuré pour tester les comportements de synchronisation sur les périphériques liés. 

• Fonction Peer-Gateway vPC : activée dans le domaine vPC pour étudier son influence sur la synchronisation ARP et MAC.

• Agrégation de couche 2 non-vPC : utilisée pour connecter les périphériques homologues Nexus.

• Interfaces virtuelles de commutateur non-vPC (SVI) : configurées pour explorer les comportements lorsque les adresses MAC définies par l'utilisateur ne sont pas utilisées, mettant en évidence la gestion par défaut de la synchronisation des adresses ARP et MAC.

• Système d'exploitation : NX-OS version 7.0(3)I7(5).

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 réseau complexes, la synchronisation des tables d’adresses MAC et ARP (Address Resolution Protocol) entre les périphériques interconnectés est essentielle pour garantir un flux de données cohérent et la fiabilité du réseau. Ce guide vise à fournir une présentation complète de ces comportements, étayée par des observations et des configurations réelles en laboratoire, afin de faciliter le dépannage et la configuration efficace des commutateurs de la gamme Nexus 9000. 

Les problèmes de synchronisation d'adresses ARP et MAC détaillés dans ce document sont spécifiques à certaines configurations de commutateurs Cisco Nexus 9000. Ces problèmes se posent dans deux conditions principales :

1. Lorsque des interfaces virtuelles de commutateur (SVI) sont configurées sans adresses MAC définies par l'utilisateur.

2. Lorsque la fonctionnalité de passerelle homologue vPC (Virtual Port Channel) est activée dans les paramètres de domaine vPC.

Ce comportement spécifique est important car il affecte la façon dont les entrées ARP sont maintenues malgré le fait que les entrées d'adresses MAC correspondantes vieillissent potentiellement ou sont explicitement effacées de la table d'adresses MAC. Cela peut entraîner des incohérences dans le transfert de paquets et une instabilité du réseau.

En outre, il est important de noter que ce comportement est dû à une limitation matérielle ASIC présente uniquement dans les commutateurs de la gamme Nexus 9000 de première génération. Cette limitation ne s'étend pas aux modèles Nexus 9300 Cloud Scale (versions EX, FX, GX et C) introduits ultérieurement. Le problème a été reconnu et catalogué dans le bogue Cisco IDCSCuh94866.

Topologie

Aperçu

Imaginez un scénario de réseau dans lequel le VLAN 150 est configuré comme un VLAN non-vPC, et les tables d'adresses ARP et MAC sont initialement vides entre l'hôte A et le commutateur B Nexus 9000 (N9K-B), et une requête ping est lancée de l'hôte A vers N9K-B.

Host-A# ping 192.0.2.3
PING 192.0.2.3 (192.0.2.3): 56 data bytes
36 bytes from 192.0.2.100: Destination Host Unreachable
Request 0 timed out
64 bytes from 192.0.2.3: icmp_seq=1 ttl=254 time=1.011 ms
64 bytes from 192.0.2.3: icmp_seq=2 ttl=254 time=0.763 ms
64 bytes from 192.0.2.3: icmp_seq=3 ttl=254 time=0.698 ms
64 bytes from 192.0.2.3: icmp_seq=4 ttl=254 time=0.711 ms

--- 192.0.2.3 ping statistics ---
5 packets transmitted, 4 packets received, 20.00% packet loss
round-trip min/avg/max = 0.698/0.795/1.011 ms

Cette requête ping invite l’hôte A à envoyer une requête ARP ciblée sur N9K-B. Cette requête est diffusée à partir du port-channel 21 (Po21) sur le commutateur A Nexus 9000 (N9K-A), qui est responsable de l'inondation VLAN. Simultanément, la requête est également tunnellisée via Cisco Fabric Services (CFS) sur le port-channel 20 (Po20). En conséquence directe, la table d'adresses MAC sur N9K-B est mise à jour pour inclure l'entrée correcte pour l'hôte A, et une entrée ARP est également établie dans la table ARP de N9K-B, pointant vers Po21 (l'agrégation de couche 2 non-vPC) en tant qu'interface pour l'adresse MAC de l'hôte A (0223.e957.6a3a).

N9K-B# show ip arp 192.0.2.100

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry
       D - Static Adjacencies attached to down interface

IP ARP Table
Total number of entries: 1
Address         Age       MAC Address     Interface       Flags
192.0.2.100   00:01:07  0223.e957.6a3a  Vlan150         

N9K-B# show mac address-table address  | i i 6a3a
*  150     0223.e957.6a3a   dynamic  0         F      F    Po21

N9K-B# show ip arp detail | i 3a
192.0.2.100   00:03:22  0223.e957.6a3a  Vlan150          port-channel21   <<<< Expected port-channel

Le problème peut être constaté lorsque l’adresse MAC de l’hôte A est supprimée de la table d’adresses MAC de N9K-B. Cette suppression peut avoir lieu pour diverses raisons, notamment le processus de vieillissement naturel de l'adresse MAC, la réception du protocole STP (Spanning Tree Protocol), des notifications de modification de topologie (TCN) ou des interventions manuelles telles que l'exécution de la commande clear address-table dynamic.

N9K-B# show ip arp 192.0.2.100

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry
       D - Static Adjacencies attached to down interface

IP ARP Table
Total number of entries: 1
Address         Age       MAC Address     Interface       Flags
192.0.2.100   00:00:29     0223.e957.6a3a  Vlan150             <<< ARP remains populated

N9K-B# show mac address-table address 0223.e957.6a3a
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
---------+-----------------+--------+---------+------+----+------------------
<empty, no MAC>

N9K-B# ping 192.0.2.100
PING 192.0.2.100 (192.0.2.100): 56 data bytes
64 bytes from 192.0.2.100: icmp_seq=0 ttl=253 time=1.112 ms
64 bytes from 192.0.2.100: icmp_seq=1 ttl=253 time=0.647 ms
64 bytes from 192.0.2.100: icmp_seq=2 ttl=253 time=0.659 ms
64 bytes from 192.0.2.100: icmp_seq=3 ttl=253 time=0.634 ms
64 bytes from 192.0.2.100: icmp_seq=4 ttl=253 time=0.644 ms

--- 192.0.2.100 ping statistics ---
5 packets transmitted, 5 packets received, 0.00% packet loss
round-trip min/avg/max = 0.634/0.739/1.112 ms

En dépit de ces suppressions, il est intéressant de noter que le trafic ping reste réussi. Cependant, l'entrée ARP pour l'hôte A sur N9K-B pointe de manière inattendue vers le port-channel 20 (Po20 - la liaison d'homologue vPC), plutôt que vers le port-channel 21 (Po21), qui est la liaison de couche 2 non vPC désignée. Cette redirection se produit malgré la configuration du VLAN 150 en tant que VLAN non-vPC, ce qui entraîne une incohérence dans le flux de trafic attendu.

N9K-B# show ip arp detail | i i 6a3a

Flags: * - Adjacencies learnt on non-active FHRP router
       + - Adjacencies synced via CFSoE
       # - Adjacencies Throttled for Glean
       CP - Added via L2RIB, Control plane Adjacencies
       PS - Added via L2RIB, Peer Sync
       RO - Re-Originated Peer Sync Entry

IP ARP Table for context default
Total number of entries: 2
Address         Age       MAC Address     Interface        Physical Interface  Flags
192.0.2.100   00:15:54   0223.e957.6a3a    Vlan150          port-channel20   <<< Not Po21 once the issue is triggered.

Vous pouvez utiliser la commande show ip arp internal event-history event sur les deux commutateurs Nexus 9000 pour démontrer que les paquets sont tunnellisés via Cisco Fabric Services (CFS) :

N9K-B# show ip arp internal event-history event | i i tunnel
    [116] [27772]: Tunnel Packets came with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677
    [116] [27772]: Received tunneled packet on iod: Vlan150, physical iod: port-channel20

N9K-A# show ip arp internal event-history event | i i tunnel
    [116] [28142]: Tunnel Packets sent with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677
    [116] [28142]: Tunnel it to peer destined to remote SVI's Gateway MAC. Peer Gateway Enabled

Vous pouvez également utiliser la série de commandes debug ip arp de debug sur 9K-B pour détailler également ce comportement :

N9K-B# debug logfile TAC_ARP
N9K-B# debug ip arp packet 
N9K-B# debug ip arp event 
N9K-B# debug ip arp error 

N9K-B# show debug logfile TAC_ARP | beg "15:31:23"
2018 Oct 11 15:31:23.954433 arp: arp_send_request_internal: Our own address 192.0.2.3 on interface Vlan150,sender_pid =27661 
2018 Oct 11 15:31:23.955221 arp: arp_process_receive_packet_msg: Received tunneled packet on iod: Vlan150, physical iod: port-channel20 
2018 Oct 11 15:31:23.955253 arp: arp_process_receive_packet_msg: Tunnel Packets came with: vlan: 150, L2-SMAC :0223.e957.6a3a, L2-DMAC: 00be.758e.5677 
2018 Oct 11 15:31:23.955275 arp: (context 1) Receiving packet from Vlan150, logical interface Vlan150 physical interface port-channel20, (prty 6) Hrd type 1 Prot type 800 Hrd len 6 Prot len 4 OP 2,  Pkt size 46 
2018 Oct 11 15:31:23.955293 arp: Src 0223.e957.6a3a/192.0.2.100 Dst 00be.758e.5677/192.0.2.3 
2018 Oct 11 15:31:23.955443 arp: arp_add_adj: arp_add_adj: Updating MAC on interface Vlan150, phy-interface port-channel20, flags:0x1 
2018 Oct 11 15:31:23.955478 arp: arp_adj_update_state_get_action_on_add: Different MAC(0223.e957.6a3a) Successful action on add Previous State:0x10, Current State:0x10 Received event:Data Plane Add, entry: 192.0.2.100, 0000.0000.0000, Vlan150, action to be taken send_to_am:TRUE, arp_aging:TRUE 
2018 Oct 11 15:31:23.955576 arp: arp_add_adj: Entry added for 192.0.2.100, 0223.e957.6a3a, state 2 on interface Vlan150, physical interface port-channel20, ismct 0. flags:0x10, Rearp (interval: 0, count: 0), TTL: 1500 seconds update_shm:TRUE 
2018 Oct 11 15:31:23.955601 arp: arp_add_adj: Adj info: iod: 77, phy-iod: 91, ip: 192.0.2.100, mac: 0223.e957.6a3a, type: 0, sync: FALSE, suppress-mode: ARP Suppression Disabled flags:0x10

La réponse ARP de l'hôte A atteint d'abord le commutateur Nexus 9000 A (N9K-A), puis est tunnellisée vers le commutateur Nexus 9000 B (N9K-B). Notamment, N9K-A transfère la réponse ARP à son plan de contrôle, en exploitant l'amélioration du domaine vPC de passerelle homologue. Cette configuration permet à N9K-A de gérer le routage du paquet pour N9K-B, une opération généralement inattendue dans une configuration de VLAN non-vPC.

N9K-A# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:32:47.378648 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3 <<<< 
2018-10-11 15:32:47.379262 02:23:e9:57:6a:3a -> 00:be:75:8e:56:77 ARP 192.0.2.100 is at 02:23:e9:57:6a:3a

Pour valider le comportement de la réponse ARP, la fonctionnalité d'analyseur Ethernet sur NX-OS peut être utilisée. Cet outil confirme que le plan de contrôle de N9K-B n'observe pas directement cette réponse ARP, mettant en évidence la gestion spécialisée du trafic ARP dans les configurations vPC.

N9K-B# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:33:30.053239 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3
2018-10-11 15:34:16.817309 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3
2018-10-11 15:34:42.222965 00:be:75:8e:56:77 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.44?  Tell 192.0.2.43
<snip>

Attention : selon la séquence d'événements et les circonstances, vous pourriez subir une perte de paquets de N9K-B vers l'hôte A.

N9K-B# ping 192.0.2.100
PING 192.0.2.100 (192.0.2.100): 56 data bytes
36 bytes from 192.0.2.3: Destination Host Unreachable
Request 0 timed out
Request 1 timed out
Request 2 timed out
Request 3 timed out
Request 4 timed out

--- 192.0.2.100 ping statistics ---
5 packets transmitted, 0 packets received, 100.00% packet loss

Conclusion et contournement

Le comportement observé, où les entrées ARP font référence incorrectement à la liaison entre homologues vPC plutôt qu'à l'agrégation non-vPC attendue, se produit généralement dans des circonstances spécifiques : lorsque les adresses MAC définies par l'utilisateur ne sont pas configurées sur des interfaces virtuelles de commutateur (SVI) non-vPC, même si ces SVI ne sont pas utilisées pour le routage de contiguïtés sur un vPC.

Ce comportement s'applique uniquement aux commutateurs Nexus 9000 de première génération.

Pour atténuer ce problème, il est recommandé de configurer manuellement les adresses MAC pour les interfaces SVI concernées. La modification des adresses MAC peut empêcher la mauvaise direction ARP, garantissant ainsi le bon fonctionnement du réseau sans dépendre de la liaison entre homologues vPC dans les scénarios non vPC. 

Exemple de solution ci-dessous :

N9K-A(config)# interface Vlan150
N9K-A(config-if)# mac-address 0000.aaaa.0030
N9K-A(config-if)# end

N9K-B(config)# interface Vlan150
N9K-B(config-if)# mac-address 0000.bbbb.0030
N9K-B(config-if)# end

Remarque : en raison d'une limitation matérielle, vous ne pouvez configurer que 16 adresses MAC définies par l'utilisateur par périphérique à la fois. Ceci est documenté dans le Guide de configuration des interfaces NX-OS de la gamme Cisco Nexus 9000 car le commutateur a une limite de 16 adresses MAC définies par l'utilisateur (MEv6/statique). La configuration au-delà de cette limite peut entraîner des problèmes documentés dans l'ID de bogue Cisco CSCux84428

Une fois la solution de contournement appliquée, la fonctionnalité d'analyseur Ethernet de NX-OS peut être utilisée pour vérifier que le commutateur A Nexus 9000 (N9K-A) ne transmet plus la réponse ARP à son plan de contrôle, confirmant ainsi la gestion correcte des réponses ARP dans le réseau.

N9K-A# ethanalyzer local interface inband display-filter arp limit-c 0

Capturing on inband
2018-10-11 15:36:11.675108 00:00:bb:bb:00:30 -> ff:ff:ff:ff:ff:ff ARP Who has 192.0.2.100?  Tell 192.0.2.3

Informations connexes

Consultez le document Créer des topologies pour le routage sur le canal de port virtuel pour plus d'informations sur les agrégations non vPC de couche 2, les contiguïtés de routage et les exigences MAC définies par l'utilisateur SVI.