驗證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 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的正確條目，並且ARP條目也在N9K-B的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
---------+-----------------+--------+---------+------+----+------------------
<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

儘管有這些刪除，值得注意的是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命令來演示資料包透過Cisco交換矩陣服務(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 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要求的詳細資訊，請參閱建立用於透過虛擬埠通道進行路由的拓撲文檔。