この製品のドキュメントセットは、偏向のない言語を使用するように配慮されています。このドキュメントセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブ ランゲージの取り組みの詳細は、こちらをご覧ください。
シスコは世界中のユーザにそれぞれの言語でサポート コンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版(リンクからアクセス可能)もあわせて参照することを推奨します。
このドキュメントでは、Catalyst 9800ワイヤレスLANコントローラ(WLC)のCPU使用率を監視する方法について説明し、いくつかの設定に関する推奨事項について説明します。
CPUの負荷のトラブルシューティングを詳しく調べる前に、Catalyst 9800ワイヤレスLANコントローラでのCPUの使用方法に関する基本的な知識と、ソフトウェアアーキテクチャに関する詳細な知識が必要です。
一般に、『Catalyst 9800のベストプラクティスに関するドキュメント』では、アプリケーションレベルの問題を防ぐための一連の適切な構成設定を定義しています。たとえば、mDNSのロケーションフィルタリングを使用したり、クライアント除外を常に有効にしたりできます。これらの推奨事項は、ここで説明するトピックとともに適用することをお勧めします。
Catalyst 9800コントローラは、さまざまなネットワーク負荷を対象とし、水平スケーリングに重点を置いた柔軟なプラットフォームとして設計されています。内部開発の名称はeWLCで、eはエラスティックを表します。これは、同じソフトウェアアーキテクチャが小規模な単一のCPU組み込みシステムから複数のCPU/コア大規模アプライアンスに実行できることを示します。
各WLCには2つの異なる側面があります。
簡素化すると、コントローラはコントロールプレーンとデータプレーン間に通信メカニズムを備え、パント、ネットワークからコントロールプレーンへのトラフィックの送信、インジェクション、コントロールプレーンからネットワークへのフレームのプッシュを実行します。
高CPUトラブルシューティング調査の一環として、パントメカニズムを監視し、どのトラフィックがコントロールプレーンに到達していて、高負荷につながる可能性があるかを評価する必要があります。
Catalyst 9800コントローラの場合、これは、パケット転送エンジンを開発するためのソフトウェアフレームワークであるCisco Packet Processor(CPP)の一部として実行され、複数の製品およびテクノロジーで使用されます。
このアーキテクチャでは、異なるハードウェアやソフトウェアの実装間で共通の機能セットを使用できます。たとえば、9800CLと9800-40で同様の機能を異なるスループットスケールで使用できます。
WLCは、CAPWAP AP加入プロセス中にCPU間でロードバランシングを実行します。主な差別化要因はAPサイトタグ名です。この概念では、各APはクライアントアクティビティとAP自体から発生する、追加された特定のCPU負荷を表します。このバランシングを実行するには、いくつかのメカニズムがあります。
たとえば、9800-40を使用して1つの本社と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カウントは固定で、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からWNCDへの割り当てはAP CAPWAP加入プロセス中に適用されるため、すべてのAPが切断されて再加入するネットワーク全体のCAPWAPリセットイベントがない限り、バランシング方式に関係なく、動作中に変更されることはありません。
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使用率を示す、より負荷の高いコントローラの別の例を次に示します。
つまり、さまざまなオプションをまとめると、次のようになります。
この500 APのしきい値は、デフォルトで100単位のブロックにAPをグループ化するため、ロードバランシングメカニズムの適用が有効な場合にマーキングされます。
より高度なAPバランシングを行うシナリオもあり、APがCPU間でどのように分散されるかをきめ細かく制御することが望まれます。たとえば、キーの負荷メトリックがクライアント数である非常に高密度なシナリオでは、システム内に存在するAPの数だけに焦点を当てます。
この状況の良い例は大規模なイベントです。1つの建物が数百のAPを超える数千のクライアントをホストしている場合は、負荷を可能な限り多くのCPUに分散する必要がありますが、同時にローミングを最適化する必要があります。そのため、必要でない限りWNCDを介してローミングしないでください。異なるWNCDまたはサイトタグの複数のAPが同じ物理的な場所に混在するような状況を防ぐ必要があります。
WCAEツールを使用してAP RFビュー機能を利用すると、配信の微調整と可視化に役立ちます。
これにより、View Type
をWNCDに設定するだけで、AP/WNCD分散を確認できます。ここで、各色はWNCD/CPUを表します。また、RSSIフィルタを–85に設定して、コントローラのRRMアルゴリズムによってフィルタリングされる低信号接続を回避することもできます。
前の例では、Ciscolive EMEA 24に対応し、ほとんどの隣接APが同じWNCD内で適切にクラスタ化され、クロスオーバーラップが非常に少ないことがわかります。
同じWNCDに割り当てられているサイトタグは、同じ色になります。
Cisco IOS XEアーキテクチャの概念を覚えておくことが重要です。CPU使用率の主なビューは2つあることに留意してください。1つはCisco IOSのサポート履歴で、もう1つは、すべてのプロセスとコアにわたって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
ここでは、いくつかの重要なポイントを強調します。
show tech wireless
のように非常に大きなCLI出力を収集すると、数百ものCLIコマンドが実行されて非常に大きなテキスト出力が収集されるため、IOSd、smand、pubdのプロセスにピーク負荷が発生する可能性があります。これは問題ではなく、出力が完了した後で負荷が下がります。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
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
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
これは、「Monitoring/System/CPU Utilization
」タブで確認できます。
正確なプロセスリストは、コントローラモデルとCisco IOS XEバージョンによって異なります。これは主要なプロセスの一部のリストであり、すべての可能なエントリを対象としているわけではありません。
プロセス名 |
サービス内容 |
評価 |
wncd_x |
ほとんどのワイヤレス操作を処理します。9800モデルに応じて、1 ~ 8個のインスタンスを作成できます。 |
混雑時に高使用率のピークが見られることがあります。使用率が95 %以上継続しているかどうかを数分間報告します。 |
linux_iosd-imag |
IOSプロセス |
大規模なCLI出力を収集すると、高い使用率が予想される(show tech)。 SNMP操作の数が多すぎたり頻繁すぎたりすると、CPUの使用率が高くなる可能性があります。 |
nginx社 |
Webサーバ |
このプロセスはピークを示す可能性があり、高負荷が続いている場合にのみ報告できます。 |
ucode_pkt_PPE0 |
9800CL/9800Lのデータプレーン |
このコンポーネントを監視するには、 |
エズマン |
インターフェイス用チップセットマネージャ |
この状態でCPUの使用率が高い場合は、ハードウェアの問題か、カーネルソフトウェアの問題が考えられます。これは報告できます。 |
dbm |
データベースマネージャ |
CPUの使用率が高い状態が続いている可能性があります。 |
odm_X |
Operation Data Managerは、複数のプロセスにまたがる統合DBを処理します。 |
負荷の高いシステムでは高いCPU使用率が予想されます。 |
不正 |
不正機能の処理 |
CPUの使用率が高い状態が続いている可能性があります。 |
smand |
Shell Managerは、CLIの解析と、異なるプロセス間のインタラクションを処理します。 |
大規模なCLI出力の処理中は、高いCPU使用率が予想されます。負荷がない状態でCPUの使用率が高い状態が続いていることが報告される場合があります。 |
emd |
Shell Manager.CLIの解析、および異なるプロセス間のインタラクションを処理します。 |
大規模なCLI出力の処理中は、高いCPU使用率が予想されます。負荷がない状態でCPUの使用率が高い状態が続いていることが報告される場合があります。 |
pubd(拡張) |
テレメトリ処理の一部 |
大規模なテレメトリサブスクリプションではCPUの使用率が高くなることが予想されます。負荷がない状態でCPUの使用率が高い状態が続いていることが報告される場合があります。 |
Catalyst 9800ワイヤレスLANコントローラには、ネットワークまたはワイヤレスクライアントアクティビティに関する広範な保護メカニズムがあり、偶発的または意図的なシナリオによる高CPU使用率を防止します。問題のあるデバイスの封じ込めに役立つ主な機能がいくつかあります。
これはデフォルトで有効になっており、ワイヤレス保護ポリシーの一部であり、ポリシープロファイルごとに有効または無効にできます。これにより、いくつかの異なる動作の問題を検出し、クライアントをネットワークから削除し、一時的な除外リストに設定できます。クライアントがこの除外状態にある間、APはクライアントと通信しないため、それ以上のアクションを実行できません。
除外タイマーが経過した後(デフォルトでは60秒)、クライアントは再度関連付けを許可されます。
クライアントの除外には、次のようないくつかのトリガーがあります。
クライアント除外は、CPU高使用率の原因となる可能性がある複数のハイアクティビティタイプから、コントローラ、AP、およびAAAインフラストラクチャ(Radius)を保護します。一般に、トラブルシューティングの演習や互換性の要件で必要な場合を除き、除外方法を無効にすることは推奨されません。
デフォルト設定はほとんどのケースで機能し、一部の例外的なシナリオでのみ、除外時間を長くするか、特定のトリガーを無効にする必要があります。たとえば、一部のレガシークライアントや特殊なクライアント(IOT/医療)では、クライアント側の不具合に簡単にパッチを適用できないため、アソシエーション障害のトリガーを無効にする必要があります
トリガーは、UIのConfiguration/Wireless Protection/Client Exclusion Policiesでカスタマイズできます。
ARP除外トリガーは、グローバルレベルで永続的に有効にするように設計されていますが、各ポリシープロファイルでカスタマイズできます。sh wireless profile policy all
コマンドでステータスをチェックして、次の特定の出力を探すことができます。
ARP Activity Limit
Exclusion : ENABLED
PPS : 100
Burst Interval : 5
これは、コントロールプレーンに送信されるトラフィックが事前に定義されたしきい値セットを超えないようにするための、データプレーンの高度なメカニズムです。この機能はパントポリサーと呼ばれ、ほぼすべてのシナリオにおいてパントポリサーに触れる必要はなく、シスコサポートと協力して作業する場合にのみ行う必要があります。
この保護の利点は、ネットワークで何が行われているか、およびレートが上昇している特定のアクティビティがあるか、または1秒あたりのパケット数が予想外に多い場合に、非常に詳細な情報が得られることです。
これは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を超える大きなリストになる場合があります。
テーブルの出力で、ドロップされたパケットのカラムと、ドロップ数が多いエントリを調べます。この値が0以外であるエントリも一緒にチェックする必要があります。
データ収集を簡素化するには、show platform software punt-policer drop-only
コマンドを使用して、ドロップがあるポリサーエントリだけをフィルタリングします。
この機能は、ARPストームまたは802.11プローブのフラッド(LFTSへのキュー802.11パケットを使用)があるかどうかを特定するのに役立つ可能性があります。LFTSはLinux Forwarding Transport Serviceの略です)。
最近のすべてのメンテナンスリリースで、コントローラにはアクティビティモニタが搭載されており、高いCPU使用率に動的に対応し、AP CAPWAPトンネルがアクティブな状態を維持したまま、持続不可能なプレッシャーにさらされています。 この機能は、WNCDの負荷をチェックし、新しいクライアントアクティビティの抑制を開始して、既存の接続を処理し、CAPWAPの安定性を保護するために十分なリソースが残っていることを確認します。 これはデフォルトで有効になっており、設定オプションはありません。
定義されている保護には3つのレベルがあります。L1では80 %の負荷、L2では85 %の負荷、L3では89 %の負荷で、それぞれ異なる着信プロトコルドロップを保護メカニズムとしてトリガーします。負荷が減少するとすぐに、保護は自動的に削除されます。
正常なネットワークでは、L2またはL3のロードイベントは表示されず、頻繁に発生している場合は調査できます。
モニタするには、図に示すように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は、フィルタリングを行わずに、次のいくつかの要因によりWNCDのCPU使用率を簡単に上げることができます。
次のコマンドを使用して、サービスごとの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設定の推奨事項がいくつかあります。
9800-1(config)# mdns-sd gateway
9800-1(config-mdns-sd)# transport ipv4
デフォルトでは、IPv4トランスポートを使用します。パフォーマンスを向上させるには、IPv6またはIPv4のいずれかを使用することを推奨しますが、両方を使用することはできません。
CPUの負荷が高く、前述のいずれの手順でも問題が解決しない場合は、ケースを通じてCXに連絡し、このデータを最初のステップとして追加してください。
show tech-support wireless
request platform software trace archive last <days> to-file bootflash:<archive file>
改定 | 発行日 | コメント |
---|---|---|
2.0 |
06-Jun-2025
|
外部化に関するシスコのガイドラインに準拠するため、代替テキスト、スタイル要件、機械翻訳、ブランディング要件、およびフォーマットを更新 |
1.0 |
09-May-2024
|
初版 |