Nexus 9000 Series ARP- en MAC-tabelsynchronisatiegedrag controleren

Inleiding

In dit document wordt een specifiek synchronisatiegedrag beschreven dat wordt waargenomen in de ARP- en MAC-adrestabellen van Cisco Nexus 9000-switches. 

Voorwaarden

Vereisten

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

1. Virtual Port Channel (vPC): vertrouwd zijn met de installatie, configuratie en het operationele beheer van vPC's, aangezien deze integraal deel uitmaken van het begrip van de beschreven netwerkscenario's.

2. NX-OS Virtual Port Channel Peer Gateway Feature: Kennis van hoe de peer gateway-functie functioneert binnen een vPC-configuratie, inclusief de rol ervan in het doorsturen van verkeer en redundantie mechanismen.

3. Cisco Nexus Operating System (NX-OS): een werkbegrip van NX-OS, gericht op de opdrachtregelinterface en standaardconfiguraties die van belang zijn voor de Nexus 9000-serie switches.

Gebruikte componenten

• Switch Modellen: Nexus 3000 en Nexus 9000 serie switches (alleen de eerste generatie), die van cruciaal belang zijn voor het illustreren van de specifieke ARP en MAC tabel gedrag als gevolg van hun unieke ASIC beperkingen.

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

• vPC Peer-Gateway Feature: 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 onderzoeken wanneer door de gebruiker gedefinieerde MAC-adressen niet worden gebruikt, met de nadruk op de standaardbehandeling van ARP- en MAC-adressynchronisatie.

• 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 om een consistente gegevensstroom en netwerkbetrouwbaarheid te garanderen. Deze gids is bedoeld om een uitgebreid overzicht van deze gedragingen te bieden, ondersteund door real-world laboratoriumwaarnemingen en -configuraties, om te helpen bij het oplossen van problemen en het effectief configureren van Nexus 9000-serie switches. 

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

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

2. Wanneer de functie Virtual Port Channel (vPC) peer-gateway is geactiveerd binnen de instellingen van het vPC-domein.

Dit specifieke gedrag is belangrijk omdat het van invloed is op de manier waarop ARP-vermeldingen worden behouden, ondanks dat overeenkomstige MAC-adresvermeldingen mogelijk verouderen of expliciet worden gewist uit de MAC-adrestabel. Dit kan leiden tot inconsistenties in het doorsturen van pakketten en netwerkinstabiliteit.

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

Topologie

Overzicht

Overweeg een netwerkscenario waarbij VLAN 150 is geconfigureerd als een niet-vPC VLAN en zowel de ARP- als de MAC-adrestabellen in eerste instantie leeg zijn tussen host-A en Nexus 9000 switch B (N9K-B), en een 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

Deze ping vraagt Host-A om een ARP-verzoek gericht op N9K-B te verzenden. Dit verzoek wordt uitgezonden vanuit port-channel 21 (Po21) op de Nexus 9000 switch A (N9K-A), die verantwoordelijk is voor VLAN-overstromingen. Tegelijkertijd wordt het verzoek ook getunneld via Cisco Fabric Services (CFS) over port-channel 20 (Po20). Als direct gevolg hiervan wordt de MAC-adrestabel op N9K-B bijgewerkt om de juiste vermelding voor Host-A op te nemen, en een ARP-vermelding wordt ook vastgesteld in de ARP-tabel van N9K-B, wijzend naar Po21 - de niet-vPC Layer 2-stam - 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 plaatsvinden, waaronder het natuurlijke verouderingsproces van het MAC-adres, ontvangst van Spanning Tree Protocol (STP), Topology Change Notifications (TCN's) of handmatige interventies zoals het uitvoeren van de dynamische opdracht clearmac-adrestabel.

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

Ondanks deze verwijderingen is het opmerkelijk dat ping-verkeer succesvol blijft. De ARP-vermelding voor host-A op N9K-B wijst echter onverwacht naar poort-kanaal 20 (Po20 - de vPC Peer Link) in plaats van poort-kanaal 21 (Po21), de aangewezen niet-vPC Layer 2-trunk. 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 show ip arp internal event-history event op beide Nexus 9000-switches gebruiken om aan te tonen dat pakketten via Cisco Fabric Services (CFS) worden getunneld:

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 ook de debug ip arp reeks van debug commando's op 9K-B te gebruiken om dit gedrag te detailleren ook:

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). Met name N9K-A stuurt het ARP-antwoord door naar zijn controlevlak, gebruikmakend van de peer-gateway vPC-domeinverbetering. Met deze configuratie kan N9K-A de routering van het pakket voor N9K-B afhandelen, een bewerking die doorgaans niet wordt verwacht in een niet-vPC VLAN-installatie.

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 Ethanalyzer-functie op NX-OS worden gebruikt. Deze tool bevestigt dat het controlevlak van N9K-B dit ARP-antwoord niet direct waarneemt, wat de gespecialiseerde afhandeling 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>

Let op: Afhankelijk van de volgorde van gebeurtenissen en omstandigheden, kunt u pakketverlies ervaren van N9K-B naar 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

Conclusie en workaround

Het waargenomen gedrag, waarbij ARP-vermeldingen ten onrechte verwijzen naar de vPC-peerlink in plaats van naar de verwachte niet-vPC-trunk, treedt meestal op onder specifieke omstandigheden: wanneer door de gebruiker gedefinieerde MAC-adressen niet zijn geconfigureerd op niet-vPC Switch Virtual Interfaces (SVI's), zelfs als deze SVI's niet worden gebruikt voor het routeren van aangrenzende punten over een vPC.

Dit geldt alleen voor de eerste generatie Nexus 9000-switches.

Om dit probleem te verhelpen, wordt aanbevolen om de MAC-adressen handmatig te configureren voor de getroffen SVI's. Het wijzigen van de MAC-adressen kan voorkomen dat de ARP-misleiding optreedt, zodat het netwerk functioneert zoals bedoeld zonder te vertrouwen op de vPC-peer-link in niet-vPC-scenario's. 

Voorbeeld van workaround hieronder:

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 per apparaat slechts 16 door de gebruiker gedefinieerde MAC-adressen tegelijk configureren. Dit is gedocumenteerd in de configuratiehandleiding voor NX-OS-interfaces uit de Cisco Nexus 9000-reeks, aangezien de switch een limiet heeft van 16 door de gebruiker gedefinieerde MAC-adressen (MEv6/static). Als u deze limiet overschrijdt, kan dit leiden tot problemen die zijn gedocumenteerd in Cisco bug ID CSCux84428

Nadat de tijdelijke oplossing is toegepast, kan de Ethanalyzer-functie op NX-OS worden gebruikt om te controleren of Nexus 9000 switch A (N9K-A) niet langer het ARP-antwoord doorstuurt naar het controlevlak, waarmee de juiste afhandeling 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

Raadpleeg het document Create Topologies for Routing over Virtual Port Channel voor meer informatie over Layer 2 non-vPC-trunks, routeringsadjacencies en SVI User Defined MAC-vereisten.