排除無線LAN控制器CPU負載故障
簡介
本檔案介紹如何監控Catalyst 9800無線LAN控制器上的CPU使用率，並涵蓋幾個組態建議。
瞭解CPU使用率
深入瞭解CPU負載疑難排解之前，必須瞭解Catalyst 9800無線LAN控制器中如何使用CPU的基礎知識以及一些有關軟體架構的詳細資訊。
通常，Catalyst 9800最佳實踐文檔定義了一組可以防止應用程式級問題的配置設定。例如，對mDNS使用位置過濾或確保始終啟用客戶端排除。建議您將這些建議與此處公開的主題一起應用。
平台基礎知識
Catalyst 9800控制器設計為針對不同網路負載的靈活平台，專注於水準擴展。內部開發命名為eWLC，其中「e」表示彈性，表示從小型單CPU嵌入式系統到多台CPU/核心大型裝置運行相同的軟體架構。
每個WLC有兩個截然不同的端：
- 控制平面：處理所有管理互動（如CLI、UI、Netconf），以及客戶端和AP的所有入網過程。
- 資料平面：負責CAPWAP、AVC策略實施等功能的實際資料包轉發和解除封裝。
控制平面
- 大多數Cisco IOS®進程在BinOS（Linux核心）下運行，帶有其自己的專用排程程式和監控命令。
- 有一組稱為無線網路控制守護程式(WNCD)的關鍵進程，每個進程都有一個本地記憶體資料庫，用於處理大多數無線活動。每個CPU都擁有一個WNCD，用於將負載分佈到每個系統的所有可用CPU核心
- 在AP加入過程中完成了WNCD間的負載分配。當AP執行到控制器的CAPWAP連線時，內部負載平衡器使用一組可能的規則分配AP，以確保正確使用所有可用的CPU資源。
- Cisco IOS® 代碼在它自己的名為IOSd的進程中運行，並且具有CPU排程程式。這涉及特定的功能，例如CLI、SNMP、多點傳送和路由。
在簡化檢視中，控制器具有控制平面和資料平面之間的通訊機制，推送、將流量從網路傳送到控制平面、注入、以及將幀從控制平面推入網路。
作為可能的高CPU故障排除調查的一部分，您必須監控分流機制以評估哪些流量到達控制平面並可能導致高負載。
資料平面
對於Catalyst 9800控制器，這是作為思科資料包處理器(CPP)的一部分運行的，思科資料包處理器(CPP)是一個軟體框架，用於開發用於多種產品和技術的資料包轉發引擎。
該體系結構允許跨不同的硬體或軟體實施使用通用功能集。例如，它允許9800CL與9800-40在不同吞吐量級別提供類似功能。
AP負載平衡
在CAPWAP AP加入過程中，WLC在CPU之間執行負載均衡，關鍵區別在於AP站點標籤名稱。其思想是每個AP代表一個特定的CPU負載，該負載來自其客戶端活動和AP本身。有多種機制來執行此平衡：
- 如果AP使用預設標籤，則它會以循環方式在所有CPU/WNCD之間保持平衡，每個新AP加入將進入下一個WNCD。不過，這是最簡單的方法，它有一些含義：
- 這是次佳方案，因為同一RF漫遊域中的AP頻繁進行WNCD間漫遊，涉及額外的進程間通訊。跨例項漫遊的速度會減慢，但幅度很小。
- 對於FlexConnect（遠端）站點標籤，無可用的PMK金鑰分發。這意味著您無法完成Flex模式的快速漫遊，影響OKC/FT漫遊模式。
通常，預設標籤可用於較低負載方案（例如，低於9800平台的40%的AP和客戶端負載），並且僅在不需要快速漫遊時用於FlexConnect部署。
- 如果AP具有自定義站點標籤，則當AP屬於該站點標籤名稱時，該站點標籤將分配給特定WNCD例項。具有相同標籤的所有後續附加AP連線都分配到同一個WNCD。這可確保在同一個WCND上下文中發生在同一個站點標籤中的AP間漫遊。這樣可以提供更最佳化的流量，同時降低CPU使用率。支援在WNCD間漫遊，這在WNCD內漫遊中並不理想。
- 預設負載平衡決策：將標籤分配給WNCD時，負載均衡器選擇當時站點標籤計數最低的例項。站點標籤可以具有的總負載未知，這可能會導致出現次優平衡情況。這取決於AP加入的順序、已定義的站點標籤數以及它們之間的AP計數是否不對稱。
- 靜態負載平衡：為了防止向WNCD分配不平衡的站點標籤，17.9.3版及更高版本中引入了site load命令。這樣，管理員可以預定義每個站點標籤的預期負載。這在處理園區場景或多個分支機構（每個分支機構都對映到不同的AP計數）以確保負載在WNCD中均勻分佈時很有用。
如果您使用9800-40處理一個總部，加上5個具有不同AP數量的分支機構，則配置可能如下所示：
wireless tag site office-main
load 120
wireless tag site branch-1
load 10
wireless tag site branch-2
load 12
wireless tag site branch-3
load 45
wireless tag site branch-4
load 80
wireless tag site branch-5
load 5
在此場景中，您不希望主辦公室標籤與branch-3和branch-4位於同一WNCD上。共有6個站點標籤，並且平台有5個WNCD，負載最高的站點標籤可能位於同一CPU上。通過運行load命令，您可以建立可預測的AP負載平衡拓撲。
load命令是預期的大小。它不需要與AP計數完全匹配，但是，它通常設定為可以加入的預期AP。
- 在單個控制器處理大型建築的情況下，為該特定平台建立與WNCD相同的站點標籤會更容易（例如，C9800-40有5個，C9800-80有8個）。 將同一區域或漫遊域中的AP分配到同一站點標籤，以最大程度減少WNCD間通訊。
- RF負載平衡：這使用RRM的RF鄰居關係來平衡WNCD例項上的AP，並根據AP彼此的接近程度建立子組。必須在AP已啟動並運行一段時間後完成該設定，並且無需配置任何靜態負載平衡設定。可從17.12及更高版本獲得此功能。
如何確定存在多少個WNCD
對於硬體平台，WNCD計數是固定的：9800-40有5,9800-80有8。對於9800CL（虛擬），WNCD的數量取決於初始部署期間使用的虛擬機器模板。
通常，如果要確定系統中正在運行的WNCD數量，可以在所有控制器型別中運行此命令：
9800-40#show processes cpu platform sorted | count wncd
Number of lines which match regexp = 5
在9800-CL的情況下，可以運行show platform software system all 命令來收集虛擬平台上的詳細資訊：
9800cl-1#show platform software system all
Controller Details:
=================
VM Template: small
Throughput Profile: low
AP Scale: 1000
Client Scale: 10000
WNCD instances: 1
監控AP負載平衡
在AP CAPWAP加入過程中應用AP到WNCD分配，並且無論使用何種平衡方法，在操作過程中都不會更改。除非存在網路範圍的CAPWAP重置事件，其中所有AP都斷開並重新連線。
運行CLI show wireless loadbalance tag affinity命令可讓您輕鬆檢視所有WNCD例項中AP負載平衡的當前狀態：
98001#show wireless loadbalance tag affinity
Tag Tag type No of AP's Joined Load Config Wncd Instance
---------------------------------------------------------------------------------------------
Branch-tag SITE TAG 10 0 0
Main-tag SITE TAG 200 0 1
default-site-tag SITE TAG 1 NA 2
如果要將AP分佈與客戶端計數和CPU負載相關聯，可以使用WCAE支援工具，並在繁忙時間載入show tech wireless。該工具彙總了從與其關聯的每個AP獲取的WNCD客戶端計數。
以下是使用率低且使用者端計數小時適當平衡的控制器範例：
另一個範例是負載較重的控制器，顯示一般CPU使用率：
什麼是推薦的AP負載均衡機制
簡而言之，您可以總結中的不同選項：
- 小型網路，無需快速漫遊，控制器負載不到40%:預設標籤。
- 如果需要快速漫遊(OKC、FT、CCKM)或大型客戶端計數：
- 單棟建築：建立與CPU相同的站點標籤（取決於平台）。
- 在17.12之前，或低於500個AP計數：多幢建築、分支機構或大型園區：為每個物理RF位置建立一個站點標籤，並為每個站點配置load命令。
- 超過500個AP的17.12及更高版本：使用RF負載平衡。
此500個AP閾值用於標籤應用負載均衡機制的有效時間，因為預設情況下，它將AP分組為100個單元的塊。
AP WNCD分佈視覺化
在一些情況下，您可以應用高級AP平衡，最好對AP在CPU中的分佈方式進行精細控制。例如，在高密度的場景中，關鍵負載指標是客戶端計數而不是關注系統中存在的AP數量。
這種情形的一個典型例子是大型事件，在該事件中，一個建築物可以託管數百個AP上的數千個客戶端，並且您需要將負載分配到儘可能多的CPU上，但同時最佳化漫遊。除非有需要，否則請勿在WNCD上漫遊。您想要防止不同WNCD/站點標籤中的多個AP在同一物理位置混合的情況。
為了幫助微調並提供分佈的視覺化，您可以使用WCAE工具並利用AP RF檢視功能：
這允許您檢視AP/WNCD分佈，只需將View Type設定為WNCD。每種顏色代表一個WNCD/CPU，您可以將RSSI過濾器設定為–85以避免低訊號連線。這些也由控制器中的RRM演算法過濾。
在上一個與Ciscolive EMEA 24對應的示例中，您可以看到大多數相鄰的AP聚集在同一個WNCD上，交叉重疊非常有限。分配給同一WNCD的站點標籤收到相同的顏色。
監控控制平面CPU使用情況
請務必牢記Cisco IOS XE架構的概念，並牢記CPU使用情況的兩個主要檢視。一個來自歷史上的Cisco IOS支援，另一個主要支援在所有進程和核心中全面瞭解CPU。
通常，您可以運行命令show processes cpu platform 進行排序，以收集所有Cisco IOS XE中進程的詳細資訊：
9800cl-1#show processes cpu platform sorted
CPU utilization for five seconds: 8%, one minute: 14%, five minutes: 11%
Core 0: CPU utilization for five seconds: 6%, one minute: 11%, five minutes: 5%
Core 1: CPU utilization for five seconds: 2%, one minute: 8%, five minutes: 5%
Core 2: CPU utilization for five seconds: 4%, one minute: 12%, five minutes: 12%
Core 3: CPU utilization for five seconds: 19%, one minute: 23%, five minutes: 24%
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19953 19514 44% 44% 44% S 190880 ucode_pkt_PPE0
28947 8857 3% 10% 4% S 1268696 linux_iosd-imag
19503 19034 3% 3% 3% S 247332 fman_fp_image
30839 2 0% 0% 0% I 0 kworker/0:0
30330 30319 0% 0% 0% S 5660 nginx
30329 30319 0% 1% 0% S 20136 nginx
30319 30224 0% 0% 0% S 12480 nginx
30263 1 0% 0% 0% S 4024 rotee
30224 8413 0% 0% 0% S 4600 pman
30106 2 0% 0% 0% I 0 kworker/u11:0
30002 2 0% 0% 0% S 0 SarIosdMond
29918 29917 0% 0% 0% S 1648 inet_gethost
需要強調幾個要點：
- 過程ucode_pkt_PPE0處理9800L和9800CL平台上的資料平面。預計其利用率將始終很高，甚至高於100%。這是執行的一部分，不構成問題。
- 區分峰值使用與持續負載並隔離給定場景中的預期情況非常重要。例如，收集非常大的CLI輸出(如show tech wireless)可能會在IOSd、smand和pubd進程上生成峰值負載，因為使用數百個CLI命令來收集非常大的文本輸出。這不是問題，輸出完成後，負載會減少。
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19371 19355 62% 83% 20% R 128120 smand
27624 27617 53% 59% 59% S 1120656 pubd
4192 4123 11% 5% 4% S 1485604 linux_iosd-imag
- 在高客戶端活動時間內，WNCD核心的利用率有望達到峰值。可以看到80%的峰值而沒有任何功能影響，並且它們通常不會造成問題。
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
21094 21086 25% 25% 25% S 978116 wncd_0
21757 21743 21% 20% 20% R 1146384 wncd_4
22480 22465 18% 18% 18% S 1152496 wncd_7
22015 21998 18% 17% 17% S 840720 wncd_5
21209 21201 16% 18% 18% S 779292 wncd_1
21528 21520 14% 15% 14% S 926528 wncd_3
- 必須調查超過90%的進程超過15分鐘的持續高CPU使用率。
- 可以通過運行show processes cpu sorted 命令監控IOSd CPU利用率。這與Cisco IOS XE清單的linux_iosd-imag進程部分中的活動相對應。
9800cl-1#show processes cpu sorted
CPU utilization for five seconds: 2%/0%; one minute: 3%; five minutes: 3%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
215 81 88 920 1.51% 0.12% 0.02% 1 SSH Process
673 164441 7262624 22 0.07% 0.00% 0.00% 0 SBC main process
137 2264141 225095413 10 0.07% 0.04% 0.05% 0 L2 LISP Punt Pro
133 534184 21515771 24 0.07% 0.04% 0.04% 0 IOSXE-RP Punt Se
474 1184139 56733445 20 0.07% 0.03% 0.00% 0 MMA DB TIMER
5 0 1 0 0.00% 0.00% 0.00% 0 CTS SGACL db cor
6 0 1 0 0.00% 0.00% 0.00% 0 Retransmission o
2 198433 726367 273 0.00% 0.00% 0.00% 0 Load Meter
7 0 1 0 0.00% 0.00% 0.00% 0 IPC ISSU Dispatc
10 3254791 586076 5553 0.00% 0.11% 0.07% 0 Check heaps
4 57 15 3800 0.00% 0.00% 0.00% 0 RF Slave Main Th
8 0 1 0 0.00% 0.00% 0.00% 0 EDDRI_MAIN
- 您可以使用9800 GUI快速檢視IOSd負載、每個核心使用率以及資料平面負載：
在Monitoring/System/CPU Utilization頁籤上提供此功能。
每個流程是什麼
程式清單會因控制器機型和Cisco IOS XE版本而異。這是一些關鍵進程的清單，並不涵蓋所有可能的條目。
| 進程名稱 |
它做什麼 |
評估 |
| wncd_x |
處理大多數無線操作。根據9800型號，可以有1到8個例項。 |
繁忙時段出現高使用率峰值。報告利用率是否停滯了95%或更長時間，持續數分鐘。 |
| linux_iosd-imag |
Cisco IOS程式 |
如果收集大量CLI輸出(show tech)，期望能看到高利用率。 大或過於頻繁的SNMP操作可能導致高CPU。 |
| nginx |
Web伺服器 |
此過程可以顯示峰值，並且只能在持續的高負載上報告。 |
| ucode_pkt_PPE0 |
9800CL/9800L資料平面 |
運行命令show platform hardware chassis active qfp datapath utilization以監控此元件。 |
| 伊斯曼 |
用於介面的晶片集管理器 |
持續的高的CPU指示硬體問題或可能的核心軟體問題（可以報告）。 |
| dbm |
資料庫管理器 |
這裡可以報告持續的高的CPU。 |
| odm_X |
Operation Data Manager跨進程處理統一資料庫 |
載入的系統應使用高CPU。 |
| rogued |
處理欺詐功能 |
這裡可以報告持續的高的CPU。 |
| smand |
Shell管理器負責CLI解析和不同進程間的互動。 |
處理大型CLI輸出時預期的CPU使用率高。可以報告無負載情況下持續的高的CPU。 |
| EMD |
Shell管理器 — 處理CLI解析和不同進程之間的互動 |
處理大型CLI輸出時預期的CPU使用率高。可以報告無負載時持續的高的CPU。 |
| 已發佈 |
遙測處理的一部分 |
對於大型遙測訂用而言，CPU預計較高。可以報告無負載時持續的高的CPU。 |
高CPU保護機制
Catalyst 9800無線LAN控制器具有廣泛的網路或無線客戶端活動保護機制，可防止意外或有意的情況導致高CPU。有幾個關鍵功能旨在幫助控制有問題的裝置：
客戶端排除
預設情況下，這是啟用的，並且是無線保護策略的一部分，可以按照策略配置檔案啟用或禁用它。這可以檢測幾種不同的行為問題，從網路中移除客戶端，並將其設定為臨時排除清單。當客戶端處於此排除狀態時，AP不會與其通訊，從而阻止任何進一步的操作。
排除計時器通過後（預設情況下為60秒），允許客戶端再次關聯。
有多個觸發客戶端排除的觸發器：
- 生成ARP泛洪
- 反複的關聯失敗
- 3個或多個webauth、PSK或802.1x驗證錯誤
- 重複的身份驗證超時（沒有來自客戶端的響應）
- 正在嘗試重複使用已註冊到其他客戶端的IP地址
客戶端排除功能可保護控制器、AP和AAA基礎設施(Radius)免受可能導致高CPU的多個高活動型別的影響。除非是故障排除練習或相容性要求所要求，否則不建議禁用任何排除方法。
預設設定幾乎適用於所有情況，且只有某些特殊情況需要增加排除時間或停用某些特定觸發器。 例如，某些傳統或專用客戶端(IOT/Medical)必須禁用關聯失敗觸發器，因為客戶端缺陷無法輕易打補丁
您可以在UI中自定義觸發器：配置/無線保護/客戶端排除策略：
ARP排除觸發器設計為在全域性級別永久啟用，但可以在每個策略配置檔案上自定義該觸發器。您可以通過運行sh wireless profile policy all命令檢查狀態，並查詢以下特定輸出：
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
針對資料流量的控制平面保護
這是資料平面中的一種高級機制，用於確保傳送到控制平面的流量不超過預定義的閾值集。此功能稱為Punt策略器，在幾乎所有情況下，都不需要觸控它們，即使如此，也只能在使用Cisco支援時使用。
這種保護的優點是它提供對網路的詳細瞭解，以及是否存在任何具有增加速率或每秒意想不到的高資料包的特定活動。
這僅通過CLI顯示，因為它們通常是無需修改的高級功能的一部分。
要接收所有列印策略的檢視，請執行以下操作：
9800-l#show platform software punt-policer
Per Punt-Cause Policer Configuration and Packet Counters
Punt Config Rate(pps) Conform Packets Dropped Packets Config Burst(pkts) Config Alert
Cause Description Normal High Normal High Normal High Normal High Normal High
-------------------------------------------------------------------------------------------------------------------------------------------------------------
2 IPv4 Options 874 655 0 0 0 0 874 655 Off Off
3 Layer2 control and legacy 8738 2185 33 0 0 0 8738 2185 Off Off
4 PPP Control 437 1000 0 0 0 0 437 1000 Off Off
5 CLNS IS-IS Control 8738 2185 0 0 0 0 8738 2185 Off Off
6 HDLC keepalives 437 1000 0 0 0 0 437 1000 Off Off
7 ARP request or response 437 1000 0 330176 0 0 437 1000 Off Off
8 Reverse ARP request or repso 437 1000 0 24 0 0 437 1000 Off Off
9 Frame-relay LMI Control 437 1000 0 0 0 0 437 1000 Off Off
10 Incomplete adjacency 437 1000 0 0 0 0 437 1000 Off Off
11 For-us data 40000 5000 442919246 203771 0 0 40000 5000 Off Off
12 Mcast Directly Connected Sou 437 1000 0 0 0 0 437 1000 Off Off
視軟體版本而定，此清單可能包含超過160個專案。 在表輸出中，檢查丟棄的資料包列以及在高丟棄計數中具有非零值的任何條目。為簡化資料收集，可以運行show platform software punt-policer drop-only命令以僅過濾帶有丟棄的策略器條目。
此功能可用於識別是否存在ARP風暴或802.11探測泛洪（它們使用到LFTS的隊列802.11資料包，而LFTS代表Linux轉發傳輸服務）。
無線通話許可控制
在所有最近的維護版本中，控制器具有活動監視器以動態響應高CPU，並確保AP CAPWAP隧道在不可持續的壓力下保持活動狀態。此功能檢查WNCD負載並開始限制新客戶端活動，以確保有足夠的資源可用於處理現有連線並保護CAPWAP穩定性。預設情況下啟用此功能，並且它沒有配置選項。
定義了三種保護級別：L1為80%負載，L2為85%負載，L3為89%。每個觸發不同傳入協定的資料包都作為保護機制丟棄。一旦負載降低，保護就會自動刪除。
在正常運行的網路中，您無法看到第2層或第3層負載事件，如果它們經常發生，可以進行調查。
要監控，請運行命令wireless stats cac:
9800-l# show wireless stats cac
WIRESLESS CAC STATISTICS
---------------------------------------------
L1 CPU Threshold: 80 L2 CPU Threshold: 85 L3 CPU Threshold: 89
Total Number of CAC throttle due to IP Learn: 0
Total Number of CAC throttle due to AAA: 0
Total Number of CAC throttle due to Mobility Discovery: 0
Total Number of CAC throttle due to IPC: 0
CPU Throttle Stats
L1-Assoc-Drop: 0 L2-Assoc-Drop: 0 L3-Assoc-Drop: 0
L1-Reassoc-Drop: 0 L2-Reassoc-Drop: 0 L3-Reassoc-Drop: 0
L1-Probe-Drop: 12231 L2-Probe-Drop: 11608 L3-Probe-Drop: 93240
L1-RFID-Drop: 0 L2-RFID-Drop: 0 L3-RFID-Drop: 0
L1-MDNS-Drop: 0 L2-MDNS-Drop: 0 L3-MDNS-Drop: 0
mDNS保護
mDNS作為一種協定允許使用零接觸方法來發現裝置間的服務，但同時，它可能非常活躍，並且如果配置不正確會顯著增加負載。
mDNS無需任何過濾，可以很容易地提高WNCD CPU利用率，這有以下幾個因素：
- mDNS策略具有無限制學習，控制器獲取所有裝置提供的所有服務。這可能導致包含數百個條目的大型服務清單。
- 未過濾的策略設定會導致控制器將這些大型服務清單推送到詢問誰提供給定服務的每個客戶端。
- 某些特定於mDNS的服務由所有無線客戶端提供，導致更高的服務計數和活動，而此情況與OS版本有所不同。
您可以通過運行以下命令檢查每個服務的mDNS清單大小：
9800-l# show mdns-sd service statistics
Service Name Service Count
-----------------------------------------------------------------------------
_ipp._tcp.local 84
_ipps._tcp.local 52
_raop._tcp.local 950
_airplay._tcp.local 988
_printer._tcp.local 13
_googlerpc._tcp.local 12
_googlecast._tcp.local 70
_googlezone._tcp.local 37
_home-sharing._tcp.local 7
_cups._sub._ipp._tcp.local 26
這可以提供有關任何給定查詢可獲取的大小的想法。它本身並不表示問題，而只是一種監控被跟蹤對象的方法。有一些重要的mDNS配置建議：
- 將mDNS傳輸設定為單一協定：
9800-1(config)# mdns-sd gateway
9800-1(config-mdns-sd)# transport ipv4
預設情況下，它使用IPv4傳輸。出於效能考慮，建議使用IPv6或IPv4，但不要同時使用兩者。
- 請始終在mDNS服務策略中設定位置篩選器，以避免未繫結的查詢/響應。通常，建議使用site-tag，但是其他選項也可以使用，具體取決於您的需要。
我需要更多幫助
如果您看到高CPU負載，並且沒有以上步驟提供幫助，請通過案例與客戶體驗(CX)聯絡，並將此資料新增為起點：
- 基礎資料，包括AP/控制器配置、網路和RF操作值：
show tech-support wireless
- 存檔所有控制器跟蹤。這是一個類似黑盒概念的大檔案，可以通過運行以下命令來收集：
request platform software trace archive last <days> to-file bootflash:<archive file>
修訂記錄
| 修訂 | 發佈日期 | 意見 |
|---|---|---|
3.0 |
03-Aug-2026
|
已更新簡介、拼寫、語法、插入水平線以分隔各個部分/可讀性、修復CCW錯誤。 |
2.0 |
06-Jun-2025
|
更新替代文字、樣式要求、機器翻譯、品牌要求和格式，以遵守思科外部化指南 |
1.0 |
09-May-2024
|
初始版本 |
意見