排除無線LAN控制器CPU負載故障

簡介

本文說明如何監控Catalyst 9800無線LAN控制器上的CPU使用率，另外還介紹了幾個配置建議。

瞭解CPU使用率

在深入瞭解CPU負載疑難排解之前，您需要瞭解Catalyst 9800無線LAN控制器中如何使用CPU的基礎知識，以及有關軟體架構的一些詳細資訊。

通常，Catalyst 9800最佳實踐文檔定義了一組可以防止應用程式級問題的良好配置設定。例如，對mDNS使用位置過濾，或確保始終啟用客戶端排除。建議您將這些建議與此處公開的主題一起應用。

平台基礎知識

Catalyst 9800控制器設計為靈活的平台，針對不同的網路負載，專注於水準擴展。內部開發命名為eWLC和e for elastic，表示同一軟體架構能夠從小型單CPU嵌入式系統運行到多個CPU/核心大型裝置。

每個WLC有兩個截然不同的側面：

• 控制平面：處理所有管理互動（如CLI、UI、Netconf），以及客戶端和AP的所有入網過程。
• 資料平面：負責實際資料包轉發、解封CAPWAP、AVC策略實施等功能。

控制平面

• 大多數Cisco IOS XE進程在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。這可確保在同一個站點標籤中的AP間進行漫遊，這發生在同一個WCND上下文中，從而提供更加最佳化的流量，同時降低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 support tool並載入繁忙時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均衡，最好對如何在CPU間分配AP進行精細控制。例如，非常高密度的方案，其中關鍵負載指標是客戶端數量，而僅僅關注系統中存在的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 sorted來收集整個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版本而異。這是一些關鍵進程的清單，並不涵蓋所有可能的條目。

高CPU保護機制

Catalyst 9800無線LAN控制器具有廣泛的網路或無線客戶端活動保護機制，可防止意外或故意情形引起的高CPU。有幾個關鍵功能旨在幫助您遏制有問題的裝置：

客戶端排除

預設情況下，這是啟用的，並且是無線保護策略的一部分，可以按照策略配置檔案啟用或禁用它。這可以檢測幾種不同的行為問題，從網路中移除客戶端，並將其設定為臨時排除清單。當客戶端處於此排除狀態時，AP不會與其通訊，從而阻止任何進一步的操作。

排除計時器通過後（預設情況下為60秒），允許客戶端再次關聯。

有多個觸發客戶端排除的觸發器：

• 反複的關聯失敗
• 3個或多個webauth、PSK或802.1x驗證錯誤
• 重複的身份驗證超時（沒有來自客戶端的響應）
• 正在嘗試重複使用已註冊到其他客戶端的IP地址
• 生成ARP泛洪

客戶端排除功能可保護控制器、AP和AAA基礎設施(Radius)免受可能導致高CPU的多個高活動型別的影響。一般來說，不建議禁用任何排除方法，除非出於故障排除練習或相容性要求的需要。

預設設定適用於幾乎所有情況，並且僅在某些特殊情況下才需要增加排除時間或禁用某些特定觸發器。例如，某些傳統或專用客戶端(IOT/Medical)需要禁用關聯故障觸發器，因為客戶端缺陷不能輕易打補丁

您可以在UI中自定義觸發器：配置/無線保護/客戶端排除策略：

ARP排除觸發器設計為在全域性級別永久啟用，但可以在每個策略配置檔案中自定義。您可以使用命令look for this specific outputsh wireless profile policy all（查詢此特定輸出）檢查狀態：

ARP Activity Limit
  Exclusion                          : ENABLED
  PPS                                : 100
  Burst Interval                     : 5

針對資料流量的控制平面保護

這是資料平面中的一種高級機制，用於確保傳送到控制平面的流量不超過預定義的閾值集。此功能稱為Punt Policers，在幾乎所有情況下，都不需要觸碰它們，即使如此，也只能在與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利用率，這有以下幾個因素：

1. mDNS策略具有無限制學習，控制器獲取所有裝置提供的所有服務。這可能會導致服務清單非常大，包含數百個條目。
2. 未篩選的策略集：這會導致控制器將這些大型服務清單推送到詢問誰提供給定服務的每個客戶端。
3. 某些mDNS特定的服務由所有無線客戶端提供，導致更高的服務數量和活動，而作業系統版本對此有所差異。

您可以使用以下命令檢查每個服務的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聯絡，並將此資料新增為起點：

• 基礎資料，包括無線接入點/控制器配置以及網路和RF操作值：

show tech-support wireless 

• 存檔所有控制器跟蹤。這是一個類似黑盒概念的大檔案，可以使用以下命令進行收集：

request platform software trace archive last <days> to-file bootflash:<archive file>