简介
本文档介绍Cisco Nexus 9000系列交换机的ARP和MAC地址表中观察到的特定同步行为。
先决条件
要求
要从本文档的讨论中充分受益,读者可以基本了解以下几个关键概念和技术:
-
虚拟端口通道(vPC):熟悉vPC的设置、配置和操作管理,因为它们对于理解所述网络场景必不可少。
-
NX-OS虚拟端口通道对等网关功能:了解vPC设置中对等网关功能的运作方式,包括其在流量转发和冗余机制中的作用。
-
Cisco Nexus操作系统(NX-OS):对NX-OS的工作了解,侧重于其命令行界面和与Nexus 9000系列交换机相关的典型配置。
使用的组件
-
交换机型号:Nexus 3000和Nexus 9000系列交换机(仅限第一代),由于独特的ASIC限制,它们对于说明特定ARP和MAC表行为至关重要。
-
虚拟端口通道(vPC):配置为测试跨链接设备的同步行为。
-
vPC对等网关功能:在vPC域内激活以研究其对ARP和MAC同步的影响。
-
非vPC第2层中继:用于连接Nexus对等设备
-
非vPC交换机虚拟接口(SVI):配置为在未使用用户定义的MAC地址时探索行为,突出显示ARP和MAC地址同步的默认处理。
-
操作系统:NX-OS版本7.0(3)I7(5)。
本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您的网络处于活动状态,请确保您了解所有命令的潜在影响。
背景信息
在复杂的网络环境中,在互连设备之间同步地址解析协议(ARP)和MAC地址表对于确保一致的数据流和网络可靠性至关重要。本指南旨在全面概述这些行为,并通过实际实验观察和配置加以支持,以便有效地排除故障和配置Nexus 9000系列交换机。
本文档中详细介绍的ARP和MAC地址同步问题特定于Cisco Nexus 9000系列交换机的某些配置。这些问题主要在以下两种情况下出现:
1.配置交换机虚拟接口(SVI)时没有用户定义的MAC地址。
2.在vPC域设置中激活虚拟端口通道(vPC)对等网关功能时。
此特定行为非常重要,因为它影响了ARP条目的维护方式,尽管相应的MAC地址条目可能会老化或从MAC地址表中显式清除。这会导致数据包转发的不一致和网络不稳定。
此外,请务必注意,此行为是由仅在第一代Nexus 9000系列交换机中出现的ASIC硬件限制引起的。此限制未扩展到以后引入的Nexus 9300云扩展模型(EX、FX、GX和C版本)。此问题已在Cisco bug IDCSCuh9486中发现并予以编目。
拓扑

概述
请考虑以下网络场景:将VLAN 150配置为非vPC VLAN,并且主机A和Nexus 9000交换机B(N9K-B)之间的ARP和MAC地址表最初都是空的,然后从Host-A向N9K-B发起ping。
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
此ping会提示主机A发送一个针对N9K-B的ARP请求。此请求在Nexus 9000交换机A(N9K-A)上的端口通道21(Po21)外广播,该端口通道负责VLAN泛洪。同时,该请求也通过思科交换矩阵服务(CFS)跨端口通道20(Po20)进行隧道传输。 作为直接结果,N9K-B上的MAC地址表更新为包括主机A的正确条目,并且N9K-B的ARP表中也建立了一个ARP条目,指向Po21(非vPC第2层中继)作为主机A的MAC地址(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
当从N9K-B的MAC地址表中删除主机A的MAC地址时,可以看到此问题。此删除可能出于各种原因,包括MAC地址的自然老化过程、生成树协议(STP)的接收、拓扑更改通知(TCN)或手动干预(如执行clearmac address-table dynamic命令)。
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
尽管进行了这些删除,但值得注意的是ping流量仍然成功。但是,N9K-B上主机A的ARP条目意外指向端口通道20(Po20—vPC对等链路),而不是端口通道21(Po21),后者是指定的非vPC第2层中继。尽管VLAN 150配置为非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.
您可以在两台Nexus 9000交换机上使用show ip arp internal event-history event命令来演示数据包通过思科交换矩阵服务(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
您还可以在9K-B上使用debug ip arp系列调试命令来详细描述此行为:
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
来自主机A的ARP应答首先到达Nexus 9000交换机A(N9K-A),然后通过隧道连接到Nexus 9000交换机B(N9K-B)。 特别要注意的是,N9K-A利用对等网关vPC域增强功能将ARP应答转发到其控制平面。此配置使N9K-A能够处理N9K-B的数据包的路由,在非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
要验证ARP应答的行为,可使用NX-OS上的Ethanalyzer功能。此工具确认N9K-B的控制平面不会直接观察到此ARP应答,突出说明在vPC配置中专门处理ARP流量。
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>
警告:根据事件和环境的顺序,从N9K-B到主机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
结论和解决方法
观察到的行为(其中ARP条目错误地引用了vPC对等链路,而不是预期的非vPC中继)通常在特定情况下发生:如果未在非vPC交换机虚拟接口(SVI)上配置用户定义MAC地址,即使这些SVI不用于在vPC上路由邻接。
此行为仅适用于第一代Nexus 9000交换机。
为缓解此问题,建议手动配置受影响的SVI的MAC地址。更改MAC地址可以防止ARP错误定向,确保网络按预期运行,在非vPC场景中不依赖vPC对等链路。
解决方法示例如下:
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
注意:由于硬件限制,一次只能为每个设备配置16个用户定义的MAC地址。Cisco Nexus 9000系列NX-OS接口配置指南中记录了此信息,因为交换机限制为16个用户定义的MAC地址(MEv6/静态)。 超出此限制进行配置可能会导致Cisco Bug ID CSCux中记录的问题84428 
在应用该解决方案后,NX-OS上的Ethanalyzer功能可用于验证Nexus 9000交换机A(N9K-A)是否不再将ARP应答转发到其控制平面,从而确认正确处理网络中的ARP响应。
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
相关信息
有关第2层非vPC中继、路由邻接和SVI用户定义MAC要求的详细信息,请参阅创建虚拟端口通道路由拓扑文档。