Inleiding
Dit document beschrijft een gedrag tussen de ARP- en MAC-tabel die kan voorkomen tussen twee Nexus 9000-apparaten met een niet-vPC Layer 2-trunk tussen de twee waarbij de ARP-tabel ingevuld blijft terwijl de MAC-adrestabel leeg zal lijken voor een bepaalde host. Dit gedrag zal alleen optreden wanneer SVI’s geen door de gebruiker gedefinieerde MAC-adressen gebruiken en de functie voor de peer-gateway voor vPC is geconfigureerd onder het vPC-domein.
Vereisten
Algemene kennis van vPC, peer-gateway en NX-OS.
Gebruikte componenten
Nexus 3000s/Nexus 9000s
vPC
vPC peer-gateway
Non-vPC L2 Trunk-software
Niet-vPC SVI’s
Geen specifieke NX-OS-versie vereist
Topologie

De Nexus 9000s in deze setup wordt uitgevoerd met NX-OS 7.0(3)I7(5).
Overzicht
Overweeg een scenario waar ARP & MAC- Adrestabellen leeg tussen host-A en N9K-B zijn, en ping wordt geïnitieerd van host-A aan 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 gastheer-A zal de gastheer veroorzaken 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 CFS). De MAC-adrestabel op 9K-B wordt correct ingevuld en een ARP-ingang wordt 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 worden verwijderd als gevolg van verschillende redenen, zoals: MAC-veroudering, STP-TCN's, opschonen via CLI, etc.
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
Bericht dat pings nog succesvol zijn; onze ARP-vermelding verwijst nu 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.
Korte gebeurtenishistoriën op beide N9Ks om aan te tonen dat pakketten worden getunneld via 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
Debugs op 9K-B die door dit gedrag ook lopen
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 ingresses 9K-A van Host-A dan wordt het getunneld aan 9K-B
Je kunt zien dat 9K-A dit doorgeeft aan de SUP omdat je een peer-gateway ingeschakeld hebt en 9K-A gelooft dat het moet leiden namens N9K-B hoewel dit een niet-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
Merk op dat 9K-B dit ARP Antwoord nooit native 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 is het gevolg van SVI User Defined MAC-adressen die niet aanwezig zijn in de configuratie voor niet-vPC SVI's, zelfs wanneer ze niet worden gebruikt voor het routeren van nabijheid via vPC.
Workaround is het MAC-adres van de SVI's die het gedrag vertonen, te wijzigen
N9K-A(config)# int vlan 150
N9K-A(config-if)# mac-address 0000.aaaa.0030
N9K-A(config-if)# end
N9K-B(config)# int vlan 150
N9K-B(config-if)# mac-address 0000.bbbb.0030
N9K-B(config-if)# end
Opmerking: mogelijk hebt u maar 16 door de gebruiker gedefinieerde MAC-adressen per apparaat tegelijk geconfigureerd als gevolg van een hardwarebeperking. Dit is gedocumenteerd in de Nexus 9000 Interface Config Guide
9K-A straalt nooit het ARP antwoord op de SUP na de SVI MAC-wijziging en daarom wordt het niet getunneld via CFS
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
Zie Routing over vPC-topologieën voor informatie over L2 niet-vPC-trunks, routingnabijheid en SVI-gebruikersgedefinieerde MAC-vereiste.