Controleer Nexus 9000 Series ARP- en MAC-tafelsynchronisatiegedrag

Inleiding

Dit document beschrijft een specifiek synchronisatiegedrag dat is waargenomen in de ARP- en MAC-adrestabellen van Cisco Nexus 9000 Series switches. 

Voorwaarden

Vereisten

Om ten volle te profiteren van de discussies in dit document, kan de lezer een fundamenteel inzicht hebben in verschillende belangrijke concepten en technologieën:

1. Virtual Port Channel (vPC): vertrouwdheid met de installatie, configuratie en het operationele beheer van vPC's, aangezien deze volledig zijn geïntegreerd in het begrijpen van de beschreven netwerkscenario's.

2. NX-OS Virtual Port Channel Peer Gateway-functie: kennis van de manier waarop de peer-gateway werkt binnen een vPC-configuratie, inclusief de rol in traffic Forwarding en redundantiemechanismen.

3. Cisco Nexus Operating System (NX-OS): een goede kennis van NX-OS, waarbij de nadruk ligt op de opdrachtregelinterface en standaardconfiguraties die relevant zijn voor de Nexus 9000 Series switches.

Gebruikte componenten

• Switch Modellen: Nexus 3000 en Nexus 9000 Series switches (alleen eerste generatie), die van cruciaal belang zijn voor het illustreren van het specifieke ARP en MAC-tabelgedrag vanwege hun unieke ASIC-beperkingen.

• Virtual Port Channel (vPC): geconfigureerd om synchronisatiegedrag op gekoppelde apparaten te testen. 

• vPC Peer-Gateway-functie: geactiveerd binnen het vPC-domein om de invloed ervan op ARP- en MAC-synchronisatie te onderzoeken.

• Niet-vPC Layer 2 Trunk: gebruikt om de Nexus peer-apparaten aan te sluiten.

• Non-vPC Switch Virtual Interfaces (SVI's): geconfigureerd om gedragingen te verkennen wanneer door de gebruiker gedefinieerde MAC-adressen niet worden gebruikt, waarbij de standaardverwerking van ARP- en MAC-adressynchronisatie wordt benadrukt.

• Besturingssysteem: NX-OS versie 7.0(3)I7(5).

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u zorgen dat u de potentiële impact van elke opdracht begrijpt.

Achtergrondinformatie

In complexe netwerkomgevingen is de synchronisatie van Address Resolution Protocol (ARP) en MAC-adrestabellen tussen onderling verbonden apparaten van cruciaal belang voor het waarborgen van een consistente gegevensstroom en netwerkbetrouwbaarheid. Deze handleiding heeft als doel een uitgebreid overzicht te geven van deze gedragingen, ondersteund door real-world lab waarnemingen en configuraties, om te helpen bij het oplossen van problemen en het effectief configureren van Nexus 9000 Series switches. 

De ARP- en MAC-adressynchronisatieproblemen die in dit document worden beschreven, zijn specifiek voor bepaalde configuraties van Cisco Nexus 9000 Series switches. Deze problemen doen zich voor onder twee primaire voorwaarden:

1. Wanneer Switch Virtual Interfaces (SVI’s) zijn geconfigureerd zonder door de gebruiker gedefinieerde MAC-adressen.

2. Wanneer de functie Virtual Port Channel (vPC) peer-gateway wordt geactiveerd binnen de vPC-domeininstellingen.

Dit specifieke gedrag is significant omdat het beïnvloedt hoe ARP ingangen worden gehandhaafd ondanks overeenkomstige MAC-adresingangen die mogelijk uit verouderen of uitdrukkelijk van de MAC-adreslijst worden ontruimd. Dit kan leiden tot inconsistenties in het doorsturen van pakketten en netwerkinstabiliteit.

Bovendien is het belangrijk om op te merken dat dit gedrag te wijten is aan een ASIC hardwarebeperking die alleen aanwezig is in de eerste-generatie Nexus 9000 reeks switches. Deze beperking geldt niet voor de Nexus 9300 Cloud Scale-modellen (EX-, FX-, GX- en C-versies) die later zijn geïntroduceerd. Het probleem is herkend en gecatalogiseerd onder Cisco-bug IDCuh94866.

Topologie

Overzicht

Overweeg een netwerkscenario waarin VLAN 150 is geconfigureerd als een niet-vPC VLAN, en zowel de ARP- als de MAC-adrestabellen aanvankelijk leeg zijn tussen Host-A en Nexus 9000 switch B (N9K-B), en ping wordt gestart van Host-A naar 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

Dit pingelt vraagt Host-A om een ARP-verzoek te verzenden dat bij N9K-B wordt gericht. Dit verzoek wordt uitgezonden vanuit poortkanaal 21 (Po21) op Nexus 9000 switch A (N9K-A), die verantwoordelijk is voor VLAN-overstroming. Tegelijkertijd wordt het verzoek ook getunneld via Cisco Fabric Services (CFS) over poort-kanaal 20 (Po20). Als direct gevolg wordt de MAC-adrestabel voor N9K-B bijgewerkt met de juiste vermelding voor host-A, en een ARP-vermelding wordt ook vastgesteld in de ARP-tabel van N9K-B, die verwijst naar Po21 — de niet-vPC Layer 2-trunk — als de interface voor het MAC-adres van 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

Het probleem kan worden gezien wanneer het MAC-adres van host-A wordt verwijderd uit de MAC-adrestabel van N9K-B. Deze verwijdering kan om verschillende redenen optreden, waaronder het natuurlijke verouderingsproces van het MAC-adres, ontvangst van Spanning Tree Protocol (STP), topologiewijzigingen (TCN's) of handmatige interventies zoals het uitvoeren van de clearmac adrestabel dynamische opdracht.

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

Ondanks deze schrappingen, is het opmerkelijk dat pingelen verkeer succesvol blijft. De ARP-ingang voor Host-A op N9K-B wijst echter onverwacht naar poortkanaal 20 (Po20 — de vPC Peer Link) in plaats van poortkanaal 21 (Po21), dat de aangewezen niet-vPC Layer 2-trunk is. Deze omleiding vindt plaats ondanks dat VLAN 150 is geconfigureerd als een niet-vPC VLAN, wat leidt tot een inconsistentie in de verwachte verkeersstroom.

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.

U kunt de opdracht gebeurtenis in het internethistorie van de show ip arp gebruiken op beide Nexus 9000 switches om aan te tonen dat pakketten worden getunneld 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

U kunt de debug ip arp serie van debug commando's op 9K-B ook gebruiken om dit gedrag te detailleren:

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

Het ARP antwoord van host-A bereikt eerst Nexus 9000 switch A (N9K-A) en wordt vervolgens getunneld naar Nexus 9000 switch B (N9K-B). N9K-A stuurt met name het ARP-antwoord door naar zijn besturingsplane, waarbij gebruik wordt gemaakt van de peer-gateway vPC domeinverbetering. Met deze configuratie kan N9K-A de routing van het pakket voor N9K-B verwerken, een bewerking die doorgaans niet wordt verwacht in een installatie van een niet-vPC VLAN.

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

Om het gedrag van het ARP-antwoord te valideren, kan de functie Ethanalyzer op NX-OS worden gebruikt. Deze tool bevestigt dat het besturingsplane van N9K-B dit ARP-antwoord niet direct waarneemt, wat de gespecialiseerde behandeling van ARP-verkeer in vPC-configuraties benadrukt.

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>

Voorzichtig: Afhankelijk van de opeenvolging van gebeurtenissen en omstandigheden, kon u pakketverlies van N9K-B aan host-A ervaren.

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

Conclusie en tijdelijke oplossing

Het waargenomen gedrag, waarbij ARP-vermeldingen de vPC-peer link onjuist verwijzen in plaats van de verwachte non-vPC trunk, doet zich meestal onder specifieke omstandigheden voor: wanneer door de gebruiker gedefinieerde MAC-adressen niet zijn geconfigureerd op virtuele interfaces (SVI’s) die geen vPC-Switch zijn, zelfs als deze SVI’s niet worden gebruikt voor het routeren van nabijheid via een vPC.

Dit geldt alleen voor de eerste generatie Nexus 9000 switches.

Om dit probleem te verhelpen, is het aan te raden om de MAC-adressen handmatig te configureren voor de getroffen SVI’s. Door de MAC-adressen te wijzigen kan voorkomen worden dat ARP-misleiding optreedt, waardoor het netwerk functioneert zoals bedoeld zonder te vertrouwen op de vPC-peer link in niet-vPC-scenario's. 

Hier volgt een voorbeeld van tijdelijke oplossing:

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

Opmerking: vanwege een hardwarebeperking kunt u slechts 16 door de gebruiker gedefinieerde MAC-adressen per apparaat tegelijk configureren. Dit is gedocumenteerd in de configuratiehandleiding voor Cisco Nexus 9000 Series NX-OS-interfaces, aangezien de switch maximaal 16 door de gebruiker gedefinieerde MAC-adressen (MEv6/statisch) heeft. Als u deze beperking overschrijdt, kan dit resulteren in problemen die worden gedocumenteerd in Cisco bug-id CSCux84428

Nadat de tijdelijke oplossing is toegepast, kan de Ethanalyzer-functie op NX-OS worden gebruikt om te verifiëren dat Nexus 9000 switch A (N9K-A) het ARP-antwoord niet langer doorstuurt naar zijn besturingsplane, waarbij de juiste behandeling van ARP-reacties in het netwerk wordt bevestigd.

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

Gerelateerde informatie

Verwijzing naar de Create Topologies for Routing over Virtual Port Channel-document voor meer informatie over Layer 2 niet-vPC-trunks, routingnabijheid en SVI-door de gebruiker gedefinieerde MAC-vereisten.