Introduction
This document describes the ARP and MAC Table behavior that can occur between Nexus 9000 devices that share a non-vPC Layer 2 trunk.
Background Information
This behavior only occurs when SVIs do not use user-defined MAC addresses, and the vPC peer-gateway feature is configured under the vPC domain. Additionally, it may only be seen when the ARP table remains populated, while the MAC Address table does not have a MAC entry for a given host.
The behavior described in this document is an ASIC limitation of first-generation Nexus switches and does not affect Nexus 9300 Cloud Scale (EX/FX/GX/C) switches and later and has been documented as part of Cisco bug ID CSCuh94866.
Requirements
General knowledge of Virtual Port Channel (vPC), NXOS Virtual Port Channel peer gateway feature, and the Nexus Operating System (NXOS).
Components Used
The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, ensure that you understand the potential impact of any command.
- Nexus 3000s/Nexus 9000s (First Generation only)
- Virtual Port Channel Feature (vPC)
- vPC Peer-Gateway Feature
- Non-vPC Layer 2 (L2) Trunk
- Non-vPC SVIs
- NX-OS 7.0(3)I7(5)
Topology

Overview
Consider a scenario where the ARP & MAC Address tables are empty between Host-A and N9K-B, and a ping is initiated from Host-A to 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
The ping from Host-A causes Host-A to send an ARP Request for 9K-B. The ARP Request egresses out of Po21 on N9K-A (flooded on the VLAN) while also on Po20 (tunneled via Cisco Fabric Services [CFS]). As a result, the MAC address table on 9K-B gets populated correctly, and an ARP entry is inserted into the ARP table of N9K-B which points to Po21 (the non-vPC L2 trunk) for Host-A's MAC Address of 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
The problem can be seen when the MAC Address for Host-A is removed from N9K-B's MAC address table. The MAC Address could be removed for various reasons, such as MAC address aging, Spanning Tree Protocol (STP) Topology Change Notifications (TCNs), running the clear mac address-table dynamic command via the command line interface, and so on.
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
Notice that pings are still successful; however, our ARP entry now points to Po20 (the vPC PL) instead of Po21, which is not the expected port-channel as VLAN 150 is a non-VPC VLAN:
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.
You can use the show ip arp internal event-history event command on both Nexus 9000 switches to demonstrate that packets get tunneled 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
You can also use the debug ip arp series of debug commands on 9K-B to detail this behavior as well:
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
The ARP Reply ingresses 9K-A from Host-A and is then tunneled to 9K-B. Notice that 9K-A punts the ARP Reply to the control plane, as the peer-gateway vPC domain enhancement has been enabled. This causes 9K-A to route the packet on behalf of N9K-B, even though this is a non-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
You can use NX-OS' Ethanalyzer control plane packet capture feature to show that the control plane of 9K-B never sees this ARP Reply natively.
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>
Caution: Depending on the sequence of events and circumstances, you could experience packet loss from N9K-B to 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
This behavior occurs when SVI User Defined MAC Addresses are not configured on non-vPC SVIs even when they are not used for routing adjacencies over vPC. This behavior only applies to First Generation Nexus 9000 switches.
To work around this behavior, change the MAC Address of the SVIs impacted.
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
Note: Due to a hardware limitation, you can only have 16 User Defined MAC Addresses Configured per device at a time. This is documented within the Cisco Nexus 9000 Series NX-OS Interfaces Configuration Guide.
After the workaround is applied, you can use NX-OS' Ethanalyzer control plane packet capture feature to show how 9K-A never punts the ARP Reply to its 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
Related Information
Reference the Create Topologies for Routing over Virtual Port Channel document for more information about Layer 2 non-vPC trunks, routing adjacencies, and SVI User Defined MAC requirements.