ワイヤレスLANコントローラのCPU負荷のトラブルシューティング
はじめに
このドキュメントでは、Catalyst 9800ワイヤレスLANコントローラ(WLC)のCPU使用率を監視する方法について説明し、いくつかの推奨設定をカバーしています。
CPU使用率の理解
CPUの負荷のトラブルシューティングを行う前に、Catalyst 9800ワイヤレスLANコントローラでのCPUの使用方法に関する基本的な知識と、ソフトウェアアーキテクチャに関する詳細を理解しておく必要があります。
一般的に、『Catalyst 9800のベストプラクティス』ドキュメントでは、アプリケーションレベルの問題を防ぐための一連の設定を定義しています。たとえば、mDNSのロケーションフィルタリングを使用したり、クライアント除外を常に有効にしたりします。これらの推奨事項は、ここで説明するトピックとともに適用することをお勧めします。
プラットフォーム基本
Catalyst 9800コントローラは、さまざまなネットワーク負荷に対応する柔軟なプラットフォームとして設計されており、水平スケーリングに重点を置いています。内部開発の名称はeWLCで、エラスティックは「e」です。これは、同じソフトウェアアーキテクチャが小さな単一のCPU組み込みシステムから複数のCPU/コア大規模アプライアンスまで実行されることを示します。
各WLCには、次の2つの別個の側面があります。
- コントロールプレーン：CLI、UI、Netconfなどのすべての管理インタラクション、およびクライアントとAPのすべてのオンボーディングプロセスを処理します。
- データプレーン：実際のパケット転送とCAPWAPのカプセル化解除、AVCポリシーの適用などの機能を担当します。
コントロール プレーン
- ほとんどのCisco IOS®プロセスは、専用のスケジューラとモニタリングコマンドを備えたBinOS（Linuxカーネル）下で動作します。
- Wireless Network Control Daemon（WNCD；無線ネットワーク制御デーモン）と呼ばれる一連の主要なプロセスがあり、それぞれがローカルのインメモリデータベースを持ち、無線アクティビティのほとんどを処理します。各CPUはWNCDを所有し、使用可能なすべてのCPUコアに負荷を分散して各システムに供給します
- WNCD間の負荷分散は、AP加入時に完了します。APがコントローラへのCAPWAP加入を実行すると、使用可能なすべてのCPUリソースが適切に使用されるように、内部ロードバランサが一連の可能なルールを使用してAPを分散します。
- Cisco IOS® コードはIOSdと呼ばれる独自のプロセスで実行され、CPUスケジューラを備えています。これは、CLI、SNMP、マルチキャスト、ルーティングなどの特定の機能を処理します。
簡素化すると、コントローラはコントロールプレーンとデータプレーン間に通信メカニズムを備え、パント、ネットワークからコントロールプレーンへのトラフィックの送信、インジェクション、およびコントロールプレーンからネットワークへのフレームのプッシュを実行します。
高CPUトラブルシューティング調査の一環として、パントメカニズムを監視し、どのトラフィックがコントロールプレーンに到達していて、高負荷の原因となる可能性があるかを評価する必要があります。
データ プレーン
Catalyst 9800コントローラの場合、これはCisco Packet Processor(CPP)の一部として実行されます。CPPは、複数の製品およびテクノロジーで使用されるパケット転送エンジンを開発するためのソフトウェアフレームワークです。
このアーキテクチャにより、異なるハードウェアやソフトウェアの実装間で共通の機能セットを使用できます。たとえば、異なるスループットスケールで9800CLと9800-40で同様の機能を使用できます。
AP ロード バランシング
WLCは、CAPWAP AP加入プロセス中にCPU間でロードバランシングを実行します。主な差別化要因はAPサイトタグ名です。各APは、クライアントアクティビティとAP自体から発生する、追加された特定のCPU負荷を表すという概念です。このバランシングを実行するには、いくつかのメカニズムがあります。
- APがデフォルトタグを使用している場合、すべてのCPU/WNCDでラウンドロビン方式でバランスをとり、次のWNCDに向かう新しいAPの各加入に対応します。これは最も簡単な方法ですが、次のようないくつかの影響があります。
- 同じRFローミングドメイン内のAPは追加のプロセス間通信を含む頻繁なWNCD間ローミングを行うため、これは最適なシナリオではありません。インスタンス間のローミングは少し遅くなります。
- FlexConnect（リモート）サイトタグでは、PMKキー配布を使用できません。これは、Flexモードで高速ローミングを完了できず、OKC/FTローミングモードに影響を与えることを意味します。
一般に、デフォルトタグは負荷の低いシナリオ（たとえば、9800プラットフォームのAPとクライアントの負荷の40 %未満）で使用でき、FlexConnectの導入では高速ローミングが要件でない場合にのみ使用できます。
- APにカスタムサイトタグがある場合、APが初めてサイトタグ名に属する場合は、サイトタグがコントローラに加入すると、サイトタグが特定のWNCDインスタンスに割り当てられます。同じタグを持つ後続の追加AP加入はすべて、同じWNCDに割り当てられます。これにより、同じサイトタグ内のAP間のローミングが1つのWCNDコンテキストで実行されます。これにより、CPU使用率を抑えながら、より最適なフローが提供されます。WNCD間のローミングは、WNCD内のローミングのように最適ではないだけでなく、サポートされています。
- デフォルトのロードバランシング決定：タグがWNCDに割り当てられると、ロードバランサはその時点でサイトタグ数が最も少ないインスタンスを選択します。サイトタグが持つことができる合計負荷は不明です。最適でないバランシングシナリオにつながる可能性があります。これは、APが加入する順序、定義されているサイトタグの数、およびAPカウントがそれらにまたがる非対称であるかどうかによって異なります。
- スタティックロードバランシング：WNCDへのサイトタグの割り当てが不均衡になるのを防ぐために、site loadコマンドがバージョン17.9.3以降で導入されています。これにより、管理者は各サイトタグの予想される負荷を事前に定義できます。これは、キャンパスのシナリオや複数のブランチオフィスを処理する際に役立ちます。各オフィスは異なるAP数にマッピングされ、負荷がWNCD全体に均等に分散されます。
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と同じ数のサイトタグを作成する方が簡単です（たとえば、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から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クライアント数を要約します。
これは、使用率が低く、クライアント数が少ない場合に、適切にバランスのとれたコントローラの例です。
もう1つの例は、通常のCPU使用率を示す、より負荷の高いコントローラの場合です。
推奨されるAPロードバランシングメカニズム
つまり、さまざまなオプションをまとめると、次のようになります。
- 小規模ネットワーク、高速ローミング不要、コントローラ負荷の40 %未満：デフォルトタグ。
- 高速ローミングが必要な場合(OKC、FT、CCKM)、またはクライアント数が多い場合
- 単一の建物：サイトタグをCPUと同じ数だけ作成します（プラットフォームによって異なります）。
- 17.12より前、または500 AP未満：複数の建物、ブランチ、または大規模キャンパス：物理RFロケーションごとにsite-tagを作成し、サイトごとにloadコマンドを設定します。
- 17.12以降で500を超えるAPがある場合：RFロードバランシングを使用します。
この500 APのしきい値は、デフォルトで100単位のブロックにAPをグループ化するため、ロードバランシングメカニズムの適用が有効な場合にマークされます。
AP WNCD配信の可視化
高度なAPバランシングを適用できるシナリオもあり、APがCPU間でどのように分散されるかをきめ細かく制御できることが望まれます。たとえば、キーの負荷メトリックがクライアント数と、システムに存在するAPの数を重視する高密度シナリオです。
この状況の良い例は、1つの建物が数百の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使用率の主なビューは2つあることを念頭に置いてください。1つはCisco IOSのサポート履歴で、もう1つは、すべてのプロセスとコアにわたってCPUを包括的に把握できる機能です。
通常は、Cisco IOS XEのすべてのプロセスの詳細情報を収集するために、show processes cpu platform sorted コマンドを実行できます。
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のような非常に大きな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
- 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
- プロセスのCPU使用率が90 %を超える状態が15分以上続いている場合は、その状況を調査する必要があります。
- 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は、複数のプロセスにまたがる統合DBを処理 |
負荷の高いシステムでは高いCPU使用率が予想されます。 |
| 不正 |
不正機能の処理 |
CPUの使用率が高い状態が続いている可能性があります。 |
| smand |
Shell Managerは、CLIの解析と、異なるプロセス間のインタラクションを処理します。 |
大規模なCLI出力を処理する場合、高いCPU使用率が予想されます。負荷がない状態でCPUの使用率が高い状態が続いていることが報告される場合があります。 |
| emd |
Shell Manager:CLIの解析と異なるプロセス間でのインタラクションを処理します。 |
大規模なCLI出力を処理する場合、高いCPU使用率が予想されます。負荷がない状態でCPUの使用率が高い状態が続いていることが報告される場合があります。 |
| pubd（拡張） |
テレメトリ処理の一部 |
大規模なテレメトリサブスクリプションではCPUの使用率が高くなることが予想されます。負荷がない状態でCPUの使用率が高い状態が続いていることが報告される場合があります。 |
高CPU保護メカニズム
Catalyst 9800ワイヤレスLANコントローラには、偶発的または意図的なシナリオによる高CPU使用率を防ぐために、ネットワークまたはワイヤレスクライアントアクティビティに関する広範な保護メカニズムがあります。問題のあるデバイスの封じ込めに役立つ主な機能がいくつかあります。
クライアント除外
これはデフォルトで有効になっており、ワイヤレス保護ポリシーの一部であり、ポリシープロファイルごとに有効または無効にできます。これにより、いくつかの異なる動作の問題を検出し、クライアントをネットワークから削除し、一時的な除外リストに設定できます。クライアントがこの除外状態にある間、APはクライアントと通信しないため、それ以上のアクションを実行できません。
除外タイマーが経過した後（デフォルトでは60秒）、クライアントは再度関連付けを許可されます。
クライアントの除外には、次のようないくつかのトリガーがあります。
- ARPフラッドの生成
- アソシエーションの失敗が繰り返される
- 3つ以上のWebAuth、PSK、または802.1x認証エラー
- 認証タイムアウトが繰り返される（クライアントからの応答がない）
- 別のクライアントにすでに登録されているIPアドレスを再利用しようとする
クライアント除外は、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の安定性を保護するために十分なリソースが使用可能であることを確認するために、新しいクライアントアクティビティの抑制を開始します。 これはデフォルトで有効になっており、設定オプションはありません。
定義されている保護には、L1（80 %の負荷）、L2（85 %の負荷）、L3（89 %の負荷）の3つのレベルがあります。それぞれが異なる着信プロトコルドロップを保護メカニズムとしてトリガーします。この保護は、負荷が減少するとすぐに自動的に解除されます。
正常なネットワークでは、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をプロトコルとして使用すると、ゼロタッチ方式でデバイス間のサービスを検出できますが、同時に非常にアクティブになり、正しく設定しないと負荷が著しく増大する可能性があります。
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
|
初版 |
フィードバック