验证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版本）。此问题已在思科漏洞IDCSCuh94866下被识别并归类。

拓扑

概述

请考虑以下网络场景：将VLAN 150配置为非vPC VLAN，并且Host-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泛洪。同时，该请求还通过跨端口通道20 (Po20)的思科交换矩阵服务(CFS)进行隧道传输。直接结果是，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

当主机A的MAC地址从N9K-B的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/static)。配置超出此限制可能导致思科漏洞ID CSCux84428中记录的问题

在应用此解决方法后，可以使用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要求的详细信息，请参阅创建虚拟端口信道路由的拓扑文档。