Verifica del comportamento di sincronizzazione della tabella MAC ARP & Nexus serie 9000 con trunk L2 non vPC
Sommario
Introduzione
Questo documento descrive il comportamento ARP e MAC Table che può verificarsi tra dispositivi Nexus 9000 che condividono un trunk non vPC Layer 2.
Premesse
Questo comportamento si verifica solo quando le SVI non utilizzano indirizzi MAC definiti dall'utente e la funzione vPC peer-gateway è configurata nel dominio vPC. Inoltre, può essere visualizzato solo quando la tabella ARP rimane popolata, mentre la tabella degli indirizzi MAC non ha una voce MAC per un dato host.
Il comportamento descritto in questo documento è una limitazione ASIC degli switch Nexus di prima generazione e non influisce sugli switch Nexus 9300 Cloud Scale (EX/FX/GX/C) e versioni successive. È stato documentato come parte dell'ID bug Cisco CSCuh94866.
Requisiti
Conoscenze generali di Virtual Port Channel (vPC), funzionalità peer gateway di NXOS Virtual Port Channel e sistema operativo Nexus (NXOS).
Componenti usati
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.
- Nexus 3000s/Nexus 9000s (solo prima generazione)
- Funzionalità Virtual Port Channel (vPC)
- Funzione vPC Peer-Gateway
- Trunk non vPC Layer 2 (L2)
- SVI non vPC
- NX-OS 7.0(3)I7(5)
Topologia
Panoramica
Si consideri uno scenario in cui le tabelle ARP e MAC Address sono vuote tra l'host A e l'host N9K-B e in cui 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
Il ping tra l'host A e l'host A invia una richiesta ARP per 9K-B. La richiesta ARP parte dal Po21 sulla N9K-A (inondata sulla VLAN) e anche sul Po20 (tunneling tramite Cisco Fabric Services [CFS]). Di conseguenza, la tabella degli indirizzi MAC in 9K-B viene popolata correttamente e una voce ARP viene inserita nella tabella ARP di N9K-B che punta a Po21 (il trunk L2 non-vPC) per l'indirizzo MAC dell'host A di 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 per l'host A viene rimosso dalla tabella degli indirizzi MAC di N9K-B. L'indirizzo MAC può essere rimosso per diversi motivi, ad esempio la durata dell'indirizzo MAC, le notifiche TCN (Topology Change Notifications) del protocollo Spanning Tree Protocol (STP), l'esecuzione del comando clear mac address-table dynamic tramite l'interfaccia della riga di comando e così via.
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
---------+-----------------+--------+---------+------+----+------------------
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
Si noti che i ping hanno ancora esito positivo. Tuttavia, la voce ARP ora punta a Po20 (vPC PL) anziché a Po21, che non è il canale previsto a livello di porta perché VLAN 150 è una VLAN non VPC:
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 entra in 9K-A dall'host-A e viene quindi tunneling a 9K-B. Notare che 9K-A punta la risposta ARP al control plane, poiché il miglioramento del dominio vPC peer-gateway è stato abilitato. In questo modo, 9K-A instrada il pacchetto per conto di N9K-B, anche se questa è una 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
È possibile utilizzare la funzione di acquisizione dei pacchetti del control plane dell'etanalizzatore del sistema NX-OS per dimostrare che il control plane di 9K-B non vede mai questa risposta ARP in modo nativo.
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>
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
Questo comportamento si verifica quando gli indirizzi MAC SVI definiti dall'utente non sono configurati su SVI non vPC, anche se non vengono utilizzati per il routing delle adiacenze su vPC. Questo comportamento si applica solo agli switch Nexus 9000 di prima generazione.
Per risolvere questo problema, modificare l'indirizzo MAC delle SVI interessate.
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
Una volta applicata la soluzione alternativa, è possibile utilizzare la funzione di acquisizione pacchetti del control plane di Eanalyzer di NX-OS per mostrare come 9K-A non esegua mai punzonature della risposta ARP sul relativo control plane.
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.
Cronologia delle revisioni
| Revisione | Data di pubblicazione | Commenti |
|---|---|---|
2.0 |
09-Feb-2023 |
Correggere la formattazione degli articoli in modo da rispettare i moderni standard di documentazione. |
1.0 |
17-Dec-2018 |
Versione iniziale |
Feedback