验证Nexus 9000系列ARP和MAC表同步行为

简介

本文档介绍Cisco Nexus 9000系列交换机的ARP和MAC地址表中观察到的特定同步行为。 

先决条件

要求

要从本文档的讨论中充分受益，读者可以基本了解以下几个关键概念和技术：

1. 虚拟端口通道(vPC):熟悉vPC的设置、配置和操作管理，因为它们对于理解所述网络场景必不可少。

2. NX-OS虚拟端口通道对等网关功能：了解vPC设置中对等网关功能的运作方式，包括其在流量转发和冗余机制中的作用。

3. 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要求的详细信息，请参阅创建虚拟端口通道路由拓扑文档。