& Verifieer Nexus 9000 Series ARP Tabel Sync Gedrag met Non-vPC L2 Trunk

Inleiding

Dit document beschrijft het ARP- en MAC-tabelgedrag dat kan optreden tussen Nexus 9000 apparaten die een niet-vPC Layer 2-trunk delen.

Achtergrondinformatie

Dit gedrag treedt alleen op wanneer SVI’s geen door de gebruiker gedefinieerde MAC-adressen gebruiken, en de functie voor de peer-gateway voor vPC wordt geconfigureerd onder het vPC-domein. Bovendien, kan het slechts worden gezien wanneer de ARP lijst bevolkt blijft, terwijl de MAC- Adreslijst geen ingang van MAC voor een bepaalde gastheer heeft. 

Het gedrag dat in dit document wordt beschreven, is een ASIC-beperking van Nexus-switches van de eerste generatie en is niet van invloed op Nexus 9300 Cloud Scale (EX/FX/GX/C)-switches en hoger en is gedocumenteerd als deel van Cisco bug-id CSCuh94866.

Vereisten

Algemene kennis van Virtual Port Channel (vPC), NXOS Virtual Port Channel peer-gatewayfunctie en het Nexus Operating System (NXOS).

Gebruikte componenten

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.

• Nexus 3000s/Nexus 9000s (alleen eerste generatie)
• Functie voor virtueel poortkanaal (vPC)
• vPC-peer-gateway functie
• Non-vPC Layer 2 (L2) Trunk 
• Niet-vPC SVI’s
• NX-OS 7.0(3)I7(5)

Topologie

Overzicht

Overweeg een scenario waar de ARP & MAC- adrestabellen leeg zijn tussen host-A en N9K-B, en een ping wordt geïnitieerd 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

Pingel van host-A veroorzaakt host-A om een ARP Verzoek om 9K-B te verzenden. Het ARP-verzoek komt uit Po21 op N9K-A (overstroomd op het VLAN) terwijl ook op Po20 (getunneld via Cisco Fabric Services [CFS]). Hierdoor wordt de MAC-adrestabel op 9K-B correct ingevuld en wordt een ARP-ingang ingevoegd in de ARP-tabel van N9K-B die verwijst naar Po21 (de niet-vPC L2-trunk) voor Host-A's MAC-adres van 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 voor host-A wordt verwijderd uit de MAC-adrestabel van N9K-B. Het MAC-adres kan om verschillende redenen worden verwijderd, zoals MAC-adresveroudering, STP (Spanning Tree Protocol) meldingen van topologiewijziging (TCN’s), het uitvoeren van de duidelijke mac-adrestabel-dynamische opdracht via de opdrachtregelinterface, enzovoort.

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

Merk op dat pings nog steeds succesvol zijn; onze ARP-ingang wijst nu echter naar Po20 (de vPC PL) in plaats van Po21, wat niet het verwachte poortkanaal is aangezien VLAN 150 een niet-VPC VLAN is:

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 ingroeit 9K-A van Host-A en wordt dan getunneld aan 9K-B. Merk op dat 9K-A het ARP-antwoord op het besturingsplane prikt, omdat de peer-gateway vPC domeinverbetering is ingeschakeld. Dit veroorzaakt 9K-A om het pakket namens N9K-B te leiden, alhoewel dit geen vPC VLAN is.

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

U kunt de pakketopname van het controlevliegtuig van de Ethanalyzer van NX-OS gebruiken om aan te tonen dat het controlevliegtuig van 9K-B dit ARP Antwoord nooit inheems ziet.

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

Dit gedrag treedt op wanneer SVI User Defined MAC-adressen niet zijn geconfigureerd op niet-vPC SVI’s, zelfs als ze niet worden gebruikt voor het routeren van nabijheid via vPC. Dit geldt alleen voor de eerste generatie Nexus 9000 switches.

Om rond dit gedrag te werken, verander het MAC-adres van de beïnvloede SVI's.

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.

Nadat de tijdelijke oplossing is toegepast, kunt u de pakketopname van de ethanalyzer-besturingsplane van NX-OS gebruiken om te laten zien hoe 9K-A het ARP-antwoord nooit naar zijn besturingsplane prikt.

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.