ARP資料包風暴是否會影響Nexus 7000平台上的BFD會話

簡介

本檔案介紹ARP封包風暴對在Nexus 7000交換器上執行的控制平面通訊協定（例如BFD、OSPF和其他通訊協定）的影響。

作者：Nishad Mohiuddin、Nikolay Kartashev、思科TAC工程師。

問：由於Cisco NX-OS可以將BFD操作分發到支援BFD的相容模組，因此ARP資料包風暴是否會對Nexus 7000平台上的BFD會話產生任何影響？

答：一般來說，ARP資料包風暴可能會對在Nexus 7000交換機上運行的BFD會話的穩定性產生負面影響。具體症狀取決於ARP資料包風暴事件的長度和規模。以下是Cisco TAC實驗室網路的測試結果。

實驗室設定詳細資訊

以下實驗設定旨在測試ARP流量量對Nexus 7000交換機CPU的影響。

這裡，N7k-A用作被測裝置(DUT)。DUT是具有以下硬體配置的Nexus 7009交換機

N7k-A# show module 
Mod Ports Module-Type Model Status
--- ----- ----------------------------------- ------------------ ----------
1 0 Supervisor module-1X N7K-SUP1 active *
2 0 Supervisor module-1X N7K-SUP1 ha-standby
3 32 10 Gbps Ethernet Module N7K-M132XP-12 ok
4 32 10 Gbps Ethernet Module N7K-M132XP-12 ok
N7k-A#

N7k-A連線了以下裝置

• N7k-B是VPC對等體，連線到介面Ethernet 3/15
• ASR1k是連線到介面Ethernet 3/14的第3層鄰居
• N7k-C是第3層鄰居，連線到介面Ethernet 4/10
• IXIA流量發生器位於vlan 6中，連線到配置為第2層接入埠的乙太網介面3/10

DUT有三個BFD會話，一個位於插槽4中面向N7k-C的線卡上，兩個位於插槽3中面向N7k-B和ASR1k的線卡上

N7k-A# show bfd neighbors

OurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int
10.80.6.173 10.80.6.174 1090519061/4105 Up 4951(3) Up Eth3/14

10.80.1.162 10.80.1.161 1090519054/1090519044 Up 4203(3) Up Eth4/10

10.80.1.61 10.80.1.62 1090519060/1090519059 Up 5921(3) Up Vlan6

N7k-A#

DUT還有三個OSPF會話：一個位於插槽4中的線卡上，指向N7k-C；兩個位於插槽3中的線卡上，指向N7k-B和ASR1k。 

N7k-A# show ip ospf neighbors
 OSPF Process ID 1 
 Total number of neighbors: 3
 Neighbor ID Pri State Up Time Address Interface
 10.80.0.2 1 FULL/ - 00:13:26 10.80.1.62 Vlan6 
 10.80.4.25 1 FULL/DR 00:12:40 10.80.6.174 Eth3/14 
 10.80.0.3 1 FULL/DR 20:15:07 10.80.1.161 Eth4/10 
N7k-A#

OSPF已向BFD註冊

router ospf 1
 bfd
 router-id 10.80.0.1

此外，N7k-A上的ARP表包含所有三個BFD/OSPF鄰居的條目

N7k-A# show ip arp

Address Age MAC Address Interface
10.80.1.62 00:13:30 4055.390f.48c1 Vlan6 
10.80.6.174 00:12:46 88f0.774b.0700 Ethernet3/14
10.80.1.161 00:15:13 6c9c.ed44.6841 Ethernet4/10 
N7k-A#

ARP風暴開始

IXIA Traffic Generator用於模擬網路的不穩定部分，導致大量的ARP流量傳送到DUT，如下圖所示

以下輸出顯示IXIA流量發生器所連線的介面Ethernet 3/10上的輸入流量增加。這些是vlan 6中接收的廣播ARP資料包

N7k-A# show interface Ethernet3/10 | grep "30 seconds input rate"
  30 seconds input rate 3102999976 bits/sec, 6062053 packets/sec
N7k-A#

由於在此案例中，每個廣播ARP資料包的副本都傳送到N7k-A上的CPU，因此我們看到CoPP中模組3上的違規位元組數增加

N7k-A# show policy-map interface control-plane class copp-system-p-class-normal
Control Plane

 service-policy input: copp-system-p-policy-strict

 class-map copp-system-p-class-normal (match-any)
 match access-group name copp-system-p-acl-mac-dot1x
 match protocol arp
 set cos 1
 police cir 680 kbps , bc 250 ms 
 module 3 :
 conformed 2295040 bytes; action: transmit 
 violated 20569190016 bytes; action: drop 

 module 4 :
 conformed 128 bytes; action: transmit 
 violated 0 bytes; action: drop 

N7k-A# 

附註：請註意,由於廣播ARP風暴的源僅連線到模組3上的介面，因此插槽4中的模組上沒有發生衝突的位元組

在ARP風暴開始時，上述輸出通常是指示網路出現問題的第一個（也是唯一）訊號。在大多數情況下，這些標記不會引起網路運營商的注意，或者被他們忽略，並會快速發展到導致重大連線問題的情況。

ARP風暴開始影響控制平面 

預設情況下，Nexus 7000平台上的ARP超時值配置為25分鐘或1500秒。Nexus交換機必須定期刷新本地ARP快取條目，以保持其下一跳第3層鄰居的最新IP到MAC解析。

以下是ARP快取條目過期後DUT上ARP快取表的輸出。

N7k-A# show ip arp

Address Age MAC Address Interface 
10.80.1.62 00:00:06 INCOMPLETE Vlan6 
10.80.6.174 00:00:10 INCOMPLETE Ethernet3/14 
10.80.1.161 00:12:59 6c9c.ed44.6841 Ethernet4/10 
N7k-A# 

請注意，插槽3中連線到線路卡的裝置的ARP快取條目顯示INCOMPLETE狀態，而插槽4中連線到線路卡的交換機N7k-C的條目正在按預期成功刷新。

以下DUT日誌消息指示對控制平面級別的影響

N7k-A# show logging log
...
2016 Nov 16 22:12:55 N7k-A %BFD-5-SESSION_STATE_DOWN: BFD session 1090519060 to neighbor 10.80.1.62 on interface Vlan6 has gone down. Reason: 0x3.
2016 Nov 16 22:12:55 N7k-A %OSPF-5-ADJCHANGE: ospf-1 [10600] Nbr 10.80.1.62 on Vlan6 went DOWN
2016 Nov 16 22:12:55 N7k-A %BFD-5-SESSION_REMOVED: BFD session to neighbor 10.80.1.62 on interface Vlan6 has been removed
2016 Nov 16 22:12:56 N7k-A %OSPF-5-ADJCHANGE: ospf-1 [10600] Nbr 10.80.1.62 on Vlan6 went EXSTART
2016 Nov 16 22:13:40 N7k-A %OSPF-5-ADJCHANGE: ospf-1 [10600] Nbr 10.80.6.174 on Ethernet3/14 went DOWN
2016 Nov 16 22:13:40 N7k-A %BFD-5-SESSION_STATE_DOWN: BFD session 1090519061 to neighbor 10.80.6.174 on interface Eth3/14 has gone down. Reason: 0x3.
2016 Nov 16 22:13:40 N7k-A %OSPF-5-ADJCHANGE: ospf-1 [10600] Nbr 10.80.6.174 on Ethernet3/14 went EXSTART
2016 Nov 16 22:13:46 N7k-A %BFD-5-SESSION_REMOVED: BFD session to neighbor 10.80.6.174 on interface Eth3/14 has been removed
2016 Nov 16 22:15:45 N7k-A %OSPF-5-ADJCHANGE: ospf-1 [10600] Nbr 10.80.6.174 on Ethernet3/14 went INIT
...
N7k-A# 

請注意，在此輸出中，OSPF在DOWN到EXSTART狀態之間切換，然後返回INIT狀態。發生這種情況的原因是OSPF在EXSTART狀態期間使用單播交換字首。由於ARP資料包風暴發生時插槽3中的模組上的ARP解析不完整，因此路由交換始終未完成，導致OSPF鄰接關係無法形成。

附註:下一躍點的ARP到IP到MAC的解析與BFD操作一樣，依賴於單播。假設我們可以得出BFD需要解析ARP才能正常運行。

以下輸出確認了ARP資料包風暴對插槽3中模組上的BFD和OSPF會話的影響。與此BFD和OSPF會話相反，插槽4中模組上的BFD和OSPF會話已建立並保持穩定。

N7k-A# show bfd neighbors

OurAddr NeighAddr LD/RD RH/RS Holdown(mult) State Int
10.80.1.162 10.80.1.161 1090519054/1090519044 Up 5764(3) Up Eth4/10 

N7k-A#


N7k-A# show ip ospf neighbors 
 OSPF Process ID 1 
 Total number of neighbors: 3
 Neighbor ID Pri State Up Time Address Interface
 10.80.0.2 1 EXSTART/ - 00:02:54 10.80.1.62 Vlan6 
 10.80.4.25 1 INIT/DR 00:00:05 10.80.6.174 Eth3/14 
 10.80.0.3 1 FULL/DR 20:29:28 10.80.1.161 Eth4/10
N7k-A# 

當ARP資料包風暴停止時會發生什麼？ 

 當ARP資料包風暴停止時，將自動進行以下恢復，網路開始融合，並處於ARP廣播風暴之前所處於的穩定狀態。

1. 在N7k-A上解析ARP快取條目
2. 重新建立插槽3中模組上的BFD會話
3. 重新建立插槽3中模組上的OSPF會話

結論

即使Cisco NX-OS可以將BFD操作分發到支援BFD的相容模組，但到達交換機CPU的較長ARP流量在Nexus 7000平台上刷新本地ARP快取條目所剩時間將導致BFD會話和向BFD註冊的任何客戶端協定不穩定。

這可以歸因於BFD操作，它要求對單播的下一跳進行ARP解析。如果沒有及時刷新下一躍點的ARP快取條目，BFD會話將失敗。