本文檔介紹每種故障型別,以及當您看到此故障時的過程。
在思科以應用為中心的基礎設施(ACI)交換矩陣的正常操作期間,管理員可以看到特定型別的資料包丟棄的故障。
在Cisco ACI中,所有故障均在託管對象(MO)下引發。 例如,錯誤F11245 - ingress drop packets rate(l2IngrPktsAg15min:dropRate)與MO l2IngrPktsAg15min中的引數dropRate有關。
本節介紹與丟棄資料包故障相關的託管對象(MO)的一些示例。
| 範例 | 說明 | 示例參數 | MO示例 出現哪些故障 |
|
| l2IngrPkts | l2IngrPkts5min l2IngrPkts15min l2IngrPkts1h 等等。 |
這表示每個期間每個VLAN的輸入資料包統計資訊。 |
dropRate floodRate multicastRate unicastRate |
vlanCktEp(VLAN) |
| l2IngrPktsAg | l2IngrPktsAg15min l2IngrPktsAg1h l2IngrPktsAg1d 等等。 |
這表示每個EPG、BD、VRF等的入口資料包統計資訊。例如,EPG統計資訊表示屬於EPG的VLAN統計資訊的聚合。 |
dropRate floodRate multicastRate unicastRate |
fvAEPg(EPG) fvAp(應用配置檔案) fvBD(BD) l3extOut(L3OUT) |
| eqptIngrDropPkts | eqptIngrDropPkts15min eqptIngrDropPkts1h eqptIngrDropPkts1d 等等。 |
這表示每個期間每個介面的入口丟棄資料包統計資訊。 |
*1 forwardingRate *1 errorRate *1 bufferRate |
l1PhysIf(物理埠) pcAggrIf(埠通道) |
*1:由於若干Nexus 9000平台中的ASIC限制,eqptIngrDropPkts中的這些計數器可能會被錯誤地引發,因為SUP_REDIRECT資料包被記錄為轉發丟棄。另請參閱思科錯誤ID CSCvo68407
和思科錯誤ID CSCvn72699
瞭解更多詳情和固定版本。
在ACI模式下運行的Nexus 9000交換機上,ASIC上有三個主要硬體計數器用於輸入介面丟棄原因。
l2IngrPkts和l2IngrPktsAg中的dropRate包括那些計數器。eqptIngrDropPkts的表中的三個引數(forwardingRate、errorRate、bufferRate)代表每個三個介面計數器。
轉發丟棄是在ASIC的查詢塊(LU)上丟棄的資料包。在LU塊中,基於資料包報頭資訊做出資料包轉發決策。如果決定捨棄封包,則會計算轉送捨棄。發生這種情況的原因有很多。主要包括:
由於缺少允許通訊的合約而丟棄此項。
當封包進入光纖時,交換器會檢視來源和目的地EPG以瞭解是否有允許此通訊的合約。如果來源和目的地位於不同的EPG中,且兩者之間沒有允許此封包型別的協定,則交換器會捨棄封包,並將其標籤為SECURITY_GROUP_DENY。這將增加Forward Drop計數器。
由於VLAN不當而丟棄的。
封包進入交換矩陣時,交換器會檢視封包,確定連線埠上的組態是否允許此封包。 例如,幀以802.1Q標籤10進入交換矩陣。如果交換機在埠上具有VLAN 10,則它會檢查內容,並根據目標MAC做出轉發決策。但是,如果VLAN 10不在埠上,則會將其丟棄並將其標籤為VLAN_XLATE_MISS。這將增加Forward Drop計數器。
XLATE或Translate的原因是,在ACI中,枝葉交換機採用具有802.1Q封裝的幀,並將其轉換為新的VLAN,用於交換矩陣內的VXLAN和其他規範化。如果該幀帶有未部署的VLAN,則轉換將失敗。
因為sup-tcam而下降。
aci交換機中的sup-tcam包含要在正常L2/L3轉發決策之上應用的特殊規則。sup-tcam中的規則是內建的,不可由使用者配置。Sup-tcam規則的目標主要是處理一些異常或控制平面流量,而不是由使用者檢查或監控。當封包符合sup-tcam規則且規則為捨棄封包時,捨棄的封包會計為ACL_DROP,並遞增Forward Drop計數器。發生這種情況時,通常意味著資料包將根據基本的ACI轉發主體轉發。
即使丟棄名稱是ACL_DROP,此ACL也不與可以在獨立NX-OS裝置或任何其他路由/交換裝置上配置的正常訪問控制清單相同。
這不是下降。
即使已正確處理並轉發到CPU,Sup重定向的資料包(例如CDP/LLDP/UDLD/BFD等)也可以計為轉發丟棄。
這是因為基於雲規模ASIC(EX/FX/FX2/FX3/GX/GX2)的ACI N9k交換機的ASIC實施限制。
當交換機在一個前面板介面上收到無效幀時,該幀會作為錯誤被丟棄。 示例包括具有FCS或CRC錯誤的幀。在檢視上行鏈路/下行鏈路枝葉埠或主幹埠時,最好使用show interface檢查FCS/CRC錯誤。但是,在正常操作下,預期會看到錯誤資料包在枝葉的上行/下行鏈路埠上增加,或者主幹埠,因為此計數器還包括系統修剪的幀,並且預期不會從介面傳送出去。
範例:路由資料包、相同介面廣播/泛洪幀的TTL故障。
當交換器收到訊框時,沒有緩衝區信用可用於輸入或輸出,該訊框可能會被緩衝區捨棄。 這通常提示網路中的某個位置存在擁塞。顯示錯誤的鏈路可能已滿,或者包含目的地的鏈路可能擁塞。
將安全殼層(SSH)連線到其中一個APIC並運行這些命令。
apic1# moquery -c l2IngrPktsAg15min
這提供了此類l2IngrPktsAg15min的所有對象例項。
以下是具有用於查詢特定對象的過濾器的示例。在本示例中,過濾器將只顯示屬性dn包含tn-TENANT1/ap-APP1/epg-EPG1的對象。
此外,此示例使用egrep僅顯示所需的屬性。
示例輸出1:租戶TENANT1、應用配置檔案APP1、epg1的EPG計數器對象(l2IngrPktsAg15min)。
apic1# moquery -c l2IngrPktsAg15min -f 'l2.IngrPktsAg15min.dn*"tn-TENANT1/ap-APP1/epg-EPG1"' | egrep 'dn|drop[P,R]|rep'
dn : uni/tn-TENANT1/ap-APP1/epg-EPG1/CDl2IngrPktsAg15min dropPer : 30 <--- number of drop packet in the current periodic interval (600sec) dropRate : 0.050000 <--- drop packet rate = dropPer(30) / periodic interval(600s) repIntvEnd : 2017-03-03T15:39:59.181-08:00 <--- periodic interval = repIntvEnd - repIntvStart repIntvStart : 2017-03-03T15:29:58.016-08:00 = 15:39 - 15:29
= 10 min = 600 sec
或者,如果您知道對象dn,則可以使用其他選項-d而不是-c來獲取特定對象。
示例輸出2:租戶TENANT1、應用配置檔案APP1、epg2的EPG計數器對象(l2IngrPktsAg15min)。
apic1# moquery -d uni/tn-TENANT1/ap-APP1/epg-EPG2/CDl2IngrPktsAg15min | egrep 'dn|drop[P,R]|rep' dn : uni/tn-jw1/BD-jw1/CDl2IngrPktsAg15min dropPer : 30 dropRate : 0.050000 repIntvEnd : 2017-03-03T15:54:58.021-08:00 repIntvStart : 2017-03-03T15:44:58.020-08:00
如果您看到故障,或希望使用CLI檢查交換機埠上的丟包情況,最好通過檢視硬體中的平台計數器來完成。大多數但並非所有計數器均使用show interface顯示。 3個主要捨棄原因只能使用平台計數器檢視。 若要檢視這些專案,請執行以下步驟:
通過SSH連線到枝葉並運行這些命令。
ACI-LEAF# vsh_lc
module-1# show platform internal counters port <X>
*其中X表示埠號
ethernet 1/31的輸出示例:
ACI-LEAF# vsh_lc
vsh_lc
module-1#
module-1# show platform internal counters port 31
Stats for port 31
(note: forward drops includes sup redirected packets too)
IF LPort Input Output
Packets Bytes Packets Bytes
eth-1/31 31 Total 400719 286628225 2302918 463380330
Unicast 306610 269471065 453831 40294786
Multicast 0 0 1849091 423087288
Flood 56783 8427482 0 0
Total Drops 37327 0
Buffer 0 0
Error 0 0
Forward 37327
LB 0
AFD RED 0
----- snip -----
對於盒式骨幹(N9K-C9336PQ),它與枝葉完全相同。
對於模組化主幹(N9K-C9504等),必須先連線特定的線卡,然後才能檢視平台計數器。 使用SSH連線到脊柱並運行以下命令:
ACI-SPINE# vsh
ACI-SPINE#連接模組<X>
module-2# show platform internal counters port <Y>。
*其中X表示要檢視的線卡的模組編號
Y表示埠號
ethernet 2/1的輸出示例:
ACI-SPINE# vsh Cisco iNX-OS Debug Shell This shell can only be used for internal commands and exists for legacy reasons. User can use ibash infrastructure as this can be deprecated. ACI-SPINE#
ACI-SPINE# attach module 2 Attaching to module 2 ... To exit type 'exit', to abort type '$.' Last login: Mon Feb 27 18:47:13 UTC 2017 from sup01-ins on pts/1 No directory, logging in with HOME=/ Bad terminal type: "xterm-256color". can assume vt100. module-2#
module-2# show platform internal counters port 1 Stats for port 1 (note: forward drops includes sup redirected packets too) IF LPort Input Output Packets Bytes Packets Bytes eth-2/1 1 Total 85632884 32811563575 126611414 25868913406 Unicast 81449096 32273734109 104024872 23037696345 Multicast 3759719 487617769 22586542 2831217061 Flood 0 0 0 0 Total Drops 0 0 Buffer 0 0 Error 0 0 Forward 0 LB 0 AFD RED 0 ----- snip -----
說明:
發生此故障的常見原因之一是第2層資料包因轉發丟棄原因而被丟棄。原因有很多,但最常見的是:
在某些平台上(請參閱Cisco錯誤ID CSCvo68407),存在需要重新導向到CPU(例如CDP/LLDP/UDLD/BFD等)的第2層封包以轉送捨棄方式記錄以及複製到CPU的限制。這是因為這些模型中使用的ASIC存在限制。
解析度:
所描述的丟棄僅是無關緊要的,因此,最佳實踐建議是增加故障的閾值,如「狀態閾值」部分所示。為此,請參閱統計閾值中的說明。
說明:
當資料包在帶有原因緩衝區的埠上丟棄時,此故障可能會增加。如前所述,當介面在入口或出口方向發生擁塞時,通常會發生這種情況。
解析度:
此故障表示環境中由於擁塞而實際丟棄的資料包。丟棄的資料包可能導致在ACI交換矩陣中運行的應用程式出現問題。網路管理員可以隔離資料包流,並確定擁塞是由意外的資料流、低效的負載平衡等引起的,還是由這些埠上的預期利用率引起的。
此故障由幾種情況引起。最常見的是:
說明1 — 主幹丟棄
如果脊柱介面上出現此故障,可能是由於流向未知端點的流量。當ARP或IP資料包轉發到脊柱進行代理查詢時,且結構中的端點未知時,將生成一個特殊的聚合資料包,並將其傳送到相應BD(內部)組播組地址上的所有枝葉。這將觸發來自橋接域(BD)中每個枝葉的ARP請求以發現終端。 由於限制,枝葉接收的收集資料包也再次反射回交換矩陣,並在連線到枝葉的主幹鏈路上觸發轉發丟棄。此方案中的轉發丟棄僅在第1代主乾硬體上遞增。
決議1
由於已知問題是由向ACI交換矩陣傳送不必要數量的未知單播流量導致的,因此需要確定導致此問題的裝置,並檢視是否可以阻止此問題。這通常是因為裝置出於監控目的掃描或探測子網上的IP地址。為了找出傳送此流量的IP,請將SSH連線到主幹介面的枝葉,枝葉上會顯示此故障。
您可以在此處運行此命令來檢視觸發收集資料包的源IP地址(sip):
ACI-LEAF# show ip arp internal event-history event | grep glean | grep sip | more
[116] TID 11304:arp_handle_inband_glean:3035: log_collect_arp_glean;sip = 192.168.21.150;dip = 192.168.20.100;info = Received glean packet is an IP packet
[116] TID 11304:arp_handle_inband_glean:3035: log_collect_arp_glean;sip = 192.168.21.150;dip = 192.168.20.100;info = Received glean packet is an IP packet
在此範例輸出中,收集封包由192.168.21.150觸發,建議檢視此問題是否可以緩解。
說明2 — 枝葉丟棄
如果在枝葉介面上看到此故障,最可能的原因是由於前面提到的SECURITY_GROUP_DENY丟棄。
決議2
ACI枝葉會保留由於違規而被拒絕的資料包日誌。此日誌不會捕獲所有日誌以保護CPU資源,但是,它仍會提供大量日誌。
要獲取所需的日誌,如果出現故障的介面是port-channel的一部分,則需要對port-channel使用此命令和grep。否則,可能會損壞物理介面。
根據合約刪除的數量,此日誌可以快速滾動更新。
ACI-LEAF# show logging ip access-list internal packet-log deny | grep port-channel2 | more [ Sun Feb 19 14:16:12 2017 503637 usecs]: CName: jr:sb(VXLAN: 2129921), VlanType: FD_VLAN, Vlan-Id: 59, SMac: 0x8c604f0288fc, DMac:0x0022bdf819ff, SIP: 192.168.21.150, DIP: 192.168.20.3, SPort: 0, DPort: 0, Src Intf: port-channel2, Pr oto: 1, PktLen: 98 [ Sun Feb 19 14:16:12 2017 502547 usecs]: CName: jr:sb(VXLAN: 2129921), VlanType: FD_VLAN, Vlan-Id: 59, SMac: 0x8c604f0288fc, DMac:0x0022bdf819ff, SIP: 192.168.21.150, DIP: 192.168.20.3, SPort: 0, DPort: 0, Src Intf: port-channel2, Pr oto: 1, PktLen: 98
在這種情況下,192.168.21.150正在嘗試將ICMP訊息(IP通訊協定編號1)傳送到192.168.20.3。但是,2個EPG之間沒有允許ICMP的合約,因此捨棄該封包。如果應允許ICMP,則可以在兩個EPG之間新增合約。
本節介紹如何更改可能引發丟棄計數器錯誤的統計資訊對象的閾值。
每個對象的統計資訊閾值(例如,l2IngrPkts、eqptIngrDropPkts)通過監控策略針對各種對象進行配置。
如開始處的表中所述,eqptIngrDropPkts在(例如)l1PhysIf對象下通過監控策略進行監控。
這個有兩部分。
+訪問策略(連線外部裝置的埠)。也稱為前面板埠)。
+交換矩陣策略(枝葉和主幹之間的埠)。也稱為交換矩陣埠)。

每個埠對象(l1PhysIf、pcAggrIf)都可以通過介面策略組分配其自己的監控策略,如上圖所示。
預設情況下,APIC GUI中的Fabric > Access Policies和Fabric > Fabric Policies下都有一個預設監控策略。這些預設監控策略分別分配給所有埠。Access Policies下的預設監控策略用於前面板埠,Fabric Policies下的預設監控策略用於交換矩陣埠。
除非要求更改每個埠的閾值,否則可以直接修改每個部分的預設監控策略,以將更改應用於所有前面板埠和/或交換矩陣埠。
以下範例會在光纖連線埠(光纖策略)上變更eqptIngrDropPkts中轉捨棄的閾值。 在Fabric > Access Policies下對前面板埠執行相同操作。
1.導航到交換矩陣>交換矩陣策略>監控策略。
2.按一下右鍵並選擇建立監視策略。
(如果閾值更改可應用於所有交換矩陣埠,請導航到default,而不是建立一個新埠。)
3.展開新的監控策略或預設,然後導航至統計資訊收集策略。
4.按一下右窗格上Monitoring Object的鉛筆圖示,選擇Layer 1 Physical Interface Configuration(l1.PhysIf)。
(使用預設策略時,可以跳過步驟4。)
5.從右側窗格的Monitoring Object(監控對象)下拉選單,選擇Layer 1 Physical Interface Configuration(l1.PhysIf)和Stats Type,然後選擇Ingress Drop Packets。

6.單擊Config Thresholds旁邊的+。

7.編輯Threshold for Forwarding Drop。

8.建議禁用遞增閾值,以配置嚴重、重大、次要和警告的轉發丟棄率。

9.將此新監控策略應用於所需埠的介面策略組。不要忘記在交換矩陣策略中相應地配置介面配置檔案、交換機配置檔案等。
(使用預設策略時,可以跳過步驟9。)

10.如果這是用於前面板埠(訪問策略),請對聚合介面(pc.AggrIf)執行與第1層物理介面配置(l1.PhysIf)相反的相同操作,以便此新的監控策略可應用於埠通道以及物理埠。
(使用預設策略時,可以跳過步驟10。)
有多個部分。

正如上一幅圖片所描述的,l2IngrPktsAg在許多對象下受到監控。此圖片只顯示一些示例,但並不顯示l2IngrPktsAg的所有對象。但是,統計資訊的閾值是通過監控策略以及l1PhysIf或pcAggrIf下的eqptIngrDropPkts配置的。
可以為每個對象(EPG(fvAEPg)、網橋域(fvBD)等)分配自己的監控策略,如上圖所示。
預設情況下,租戶下的所有對象均使用Tenant > Common > Monitoring Policies > default下的預設監控策略,除非另外配置。
除非要求更改每個元件的閾值,否則可以直接修改租戶common下的預設監視策略,以將更改應用於所有相關元件。
以下範例會在橋接網域的l2IngrPktsAg15min中變更輸入捨棄封包速率的閾值。
1.導航到租戶>(租戶名稱)>監視策略。
(如果使用預設監控策略,或者需要在租戶間應用新的監控策略,則租戶需要通用)
2.按一下右鍵並選擇建立監視策略。
(如果閾值更改可應用於所有元件,請導航到default,而不是建立新元件。)
3.展開新的監控策略或預設,然後導航至統計資訊收集策略。
4.按一下右窗格上Monitoring Object的鉛筆圖示,選擇Bridge Domain(fv.BD)。
(使用預設策略時,可以跳過步驟4。)
5.從右側窗格的Monitoring Object下拉選單中選擇Bridge Domain(fv.BD)和Stats Type,然後選擇Aggregated ingress packets。

6.單擊Config Thresholds旁邊的+。

7.編輯Threshold for Forwarding Drop。

8.建議禁用遞增閾值,以配置嚴重、重大、次要和警告的轉發丟棄率。

9.將此新監控策略應用於需要更改閾值的網橋域。
(使用預設策略時,可以跳過步驟9。)

| 修訂 | 發佈日期 | 意見 |
|---|---|---|
7.0 |
08-Jun-2026
|
已更新簡介、機器翻譯、樣式要求和格式。 |
6.0 |
18-May-2024
|
更新文章內容,瞭解最新型號的交換機 |
5.0 |
30-Apr-2024
|
已更新文章描述、替代文字、機器翻譯、樣式要求和格式。 |
4.0 |
04-Apr-2023
|
-FX模型註解 |
3.0 |
11-Oct-2021
|
已更新錯誤部分下的內容。 |
1.0 |
10-Apr-2017
|
初始版本 |