Verifica del comportamento di sincronizzazione delle tabelle ARP e MAC Nexus serie 9000

Introduzione

Questo documento descrive un comportamento di sincronizzazione specifico osservato nelle tabelle degli indirizzi ARP e MAC degli switch Cisco Nexus serie 9000. 

Prerequisiti

Requisiti

Per trarre il massimo vantaggio dalle discussioni di questo documento, il lettore può avere una conoscenza di base di diversi concetti e tecnologie chiave:

1. Virtual Port Channel (vPC): familiarità con l'installazione, la configurazione e la gestione operativa dei vPC, in quanto parte integrante della comprensione degli scenari di rete descritti.

2. Funzionalità gateway peer canale porta virtuale NX-OS: informazioni sul funzionamento della funzionalità gateway peer in un'installazione vPC, incluso il ruolo nei meccanismi di inoltro del traffico e ridondanza.

3. Sistema operativo Cisco Nexus (NX-OS): una comprensione operativa di NX-OS, con particolare attenzione all'interfaccia della riga di comando e alle configurazioni tipiche degli switch Nexus serie 9000.

Componenti usati

• Modelli di switch: switch Nexus serie 3000 e Nexus serie 9000 (solo prima generazione), fondamentali per illustrare il comportamento specifico delle tabelle ARP e MAC a causa dei loro vincoli ASIC univoci.

• Virtual Port Channel (vPC): configurato per verificare i comportamenti di sincronizzazione tra i dispositivi collegati. 

• Funzione vPC Peer-Gateway: attivata all'interno del dominio vPC per esaminarne l'influenza sulla sincronizzazione ARP e MAC.

• Trunk non vPC di livello 2: utilizzato per collegare i dispositivi peer Nexus.

• Interfacce virtuali switch non vPC (SVI): configurate per esplorare i comportamenti quando non vengono utilizzati indirizzi MAC definiti dall'utente, evidenziando la gestione predefinita della sincronizzazione degli indirizzi ARP e MAC.

• Sistema operativo: NX-OS versione 7.0(3)I7(5).

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Premesse

In ambienti di rete complessi, la sincronizzazione delle tabelle di indirizzi MAC e ARP (Address Resolution Protocol) tra dispositivi interconnessi è fondamentale per garantire un flusso di dati coerente e l'affidabilità della rete. Questa guida ha lo scopo di fornire una panoramica completa di questi comportamenti, supportata da osservazioni e configurazioni di laboratorio reali, per facilitare la risoluzione dei problemi e la configurazione efficace degli switch Nexus serie 9000. 

I problemi di sincronizzazione degli indirizzi ARP e MAC descritti in questo documento sono specifici di alcune configurazioni di switch Cisco Nexus serie 9000. Tali problemi sorgono in due condizioni principali:

1. Quando le interfacce virtuali di switch (SVI) sono configurate senza indirizzi MAC definiti dall'utente.

2. Quando la funzionalità gateway peer Virtual Port Channel (vPC) è attivata nelle impostazioni del dominio vPC.

Questo comportamento specifico è significativo perché influisce sulla modalità di gestione delle voci ARP nonostante le voci corrispondenti dell'indirizzo MAC siano potenzialmente obsolete o vengano cancellate esplicitamente dalla tabella degli indirizzi MAC. Ciò può causare incoerenze nell'inoltro dei pacchetti e instabilità della rete.

Inoltre, è importante notare che questo comportamento è dovuto a una limitazione hardware ASIC presente solo negli switch Nexus serie 9000 di prima generazione. Questa limitazione non si estende ai modelli Nexus 9300 Cloud Scale (versioni EX, FX, GX e C) introdotti successivamente. Il problema è stato riconosciuto e catalogato con il bug Cisco IDCSCuh94866.

Topologia

Panoramica

Si consideri uno scenario di rete in cui la VLAN 150 è configurata come VLAN non vPC e le tabelle ARP e MAC Address sono inizialmente vuote tra l'host A e lo switch B Nexus 9000 (N9K-B), mentre il ping viene avviato dall'host A all'host 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

Questo ping chiede all'host A di inviare una richiesta ARP destinata all'host N9K-B. Questa richiesta viene trasmessa dal canale porta 21 (Po21) sullo switch Nexus 9000 A (N9K-A), responsabile delle inondazioni della VLAN. Contemporaneamente, la richiesta viene anche tunneling tramite Cisco Fabric Services (CFS) su port-channel 20 (Po20). Come diretta conseguenza, la tabella degli indirizzi MAC su N9K-B viene aggiornata per includere la voce corretta per l'host-A, e una voce ARP viene anche stabilita nella tabella ARP di N9K-B, puntando a Po21—il trunk non-vPC Layer 2—come interfaccia per l'indirizzo MAC dell'host-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

Il problema può essere rilevato quando l'indirizzo MAC dell'host A viene rimosso dalla tabella degli indirizzi MAC di N9K-B. Questa rimozione può verificarsi per una serie di motivi, tra cui il processo di misurazione durata naturale dell'indirizzo MAC, la ricezione del protocollo Spanning Tree Protocol (STP), le notifiche di modifica della topologia (TCN) o interventi manuali quali l'esecuzione del comando dinamico clear mac address-table.

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

Nonostante le eliminazioni, il traffico ping ha esito positivo. Tuttavia, la voce ARP per Host-A su N9K-B punta inaspettatamente al canale porta 20 (Po20—il vPC Peer Link), piuttosto che al canale porta 21 (Po21), che è il trunk non vPC Layer 2 designato. Il reindirizzamento viene eseguito nonostante la VLAN 150 sia configurata come VLAN non vPC, il che determina un'incoerenza nel flusso di traffico previsto.

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.

È possibile usare il comando show ip arp internal event-history su entrambi gli switch Nexus 9000 per dimostrare che i pacchetti vengono tunneling tramite 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

Inoltre, è possibile usare la serie di comandi debug ip arp di debug sulla versione 9K-B per descrivere in dettaglio questo comportamento:

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 risposta ARP dell'host A raggiunge prima lo switch A Nexus 9000 (N9K-A) e viene quindi tunneling allo switch B Nexus 9000 (N9K-B). In particolare, N9K-A inoltra la risposta ARP al suo control plane, sfruttando il miglioramento del dominio vPC peer-gateway. Questa configurazione consente a N9K-A di gestire il routing del pacchetto per N9K-B, un'operazione in genere non prevista in una configurazione di 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

Per convalidare il comportamento della risposta ARP, è possibile utilizzare la funzione Ethanalyzer su NX-OS. Questo strumento conferma che il control plane di N9K-B non osserva direttamente questa risposta ARP, evidenziando la gestione specializzata del traffico ARP nelle configurazioni 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>

Attenzione: a seconda della sequenza di eventi e circostanze, si potrebbe verificare una perdita di pacchetti da N9K-B a Host-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

Conclusione e soluzione

Il comportamento osservato, in cui le voci ARP fanno erroneamente riferimento al collegamento peer vPC anziché al trunk non vPC previsto, si verifica in genere in circostanze specifiche: quando gli indirizzi MAC definiti dall'utente non sono configurati su interfacce virtuali di switch non vPC (SVI), anche se queste SVI non vengono utilizzate per il routing delle adiacenze su un vPC.

Questo comportamento si applica solo agli switch Nexus 9000 di prima generazione.

Per risolvere il problema, si consiglia di configurare manualmente gli indirizzi MAC delle SVI interessate. La modifica degli indirizzi MAC può impedire che si verifichino errori di direzione ARP, garantendo che la rete funzioni come previsto senza fare affidamento sul collegamento peer vPC in scenari non vPC. 

Di seguito è riportato un esempio di soluzione:

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

Nota: a causa di una limitazione hardware, è possibile configurare solo 16 indirizzi MAC definiti dall'utente per dispositivo alla volta. Questa condizione viene documentata nella guida alla configurazione delle interfacce NX-OS di Cisco Nexus serie 9000 poiché lo switch ha un limite di 16 indirizzi MAC definiti dall'utente (MEv6/statici). La configurazione oltre questo limite può causare i problemi documentati nell'ID bug Cisco CSCux84428

Dopo aver applicato la soluzione alternativa, è possibile utilizzare la funzione Ethanalyzer su NX-OS per verificare che lo switch Nexus 9000 A (N9K-A) non inoltri più la risposta ARP al suo control plane, confermando la corretta gestione delle risposte ARP nella rete.

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

Informazioni correlate

Per ulteriori informazioni sui trunk non vPC di layer 2, sulle adiacenze di routing e sui requisiti MAC definiti dall'utente SVI, consultare il documento Creazione di topologie per il routing su canale della porta virtuale.