ワイヤレス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 XEプロセスは、専用のスケジューラおよびモニタリングコマンドを使用して、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)の一部として実行され、複数の製品およびテクノロジーで使用されます。

このアーキテクチャでは、異なるハードウェアやソフトウェアの実装間で共通の機能セットを使用できます。たとえば、9800CLと9800-40で同様の機能を異なるスループットスケールで使用できます。

AP ロード バランシング

WLCは、CAPWAP AP加入プロセス中にCPU間でロードバランシングを実行します。主な差別化要因はAPサイトタグ名です。この概念では、各APはクライアントアクティビティとAP自体から発生する、追加された特定のCPU負荷を表します。このバランシングを実行するには、いくつかのメカニズムがあります。

• APがデフォルトタグを使用している場合、すべてのCPU/WNCDにラウンドロビン方式でバランスが取られ、新しいAPの加入は次のWNCDに転送されます。これは最も簡単な方法ですが、影響はほとんどありません。
  • 同じ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へのサイトタグの割り当てが不均衡になるのを防ぐために、管理者が各サイトタグの予期される負荷を事前に定義できるように、17.9.3以降でsite loadコマンドが導入されました。これは、キャンパスのシナリオを処理する場合、または複数のブランチオフィスを扱う場合に特に便利です。各ブランチオフィスは異なる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クライアント数を要約します。

使用率が低くクライアント数が少ない場合の、適切にバランスのとれたコントローラの例：

通常のCPU使用率を示す、より負荷の高いコントローラの別の例を次に示します。

推奨されるAPロードバランシングメカニズム

つまり、さまざまなオプションをまとめると、次のようになります。

• 小規模ネットワーク、高速ローミング不要、コントローラ負荷の40 %未満：デフォルトタグ。
• 高速ローミングが必要な場合(OKC、FT、CCKM)、またはクライアント数が多い場合
  • 単一の建物：サイトタグをCPUと同じ数だけ作成します（プラットフォームによって異なります）。
  • 17.12より前、または500 AP未満：複数の建物、ブランチ、または大規模キャンパス：物理RFロケーションごとに1つの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ビュー機能を利用すると、配信の微調整と可視化に役立ちます。

これにより、View TypeをWNCDに設定するだけで、AP/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 %を超えると予想されます。これは実装の一部であり、問題ではありません。
• ピーク時の使用率と持続的な負荷を区別し、特定のシナリオで予想される結果を特定することが重要です。たとえば、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      

• クライアントのアクティビティが高い時間帯には、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バージョンによって異なります。これは主要なプロセスの一部のリストであり、すべての可能なエントリを対象としているわけではありません。

高CPU保護メカニズム

Catalyst 9800ワイヤレスLANコントローラには、ネットワークまたはワイヤレスクライアントアクティビティに関する広範な保護メカニズムがあり、偶発的または意図的なシナリオによる高CPU使用率を防止します。問題のあるデバイスの封じ込めに役立つ主な機能がいくつかあります。

クライアント除外

これはデフォルトで有効になっており、ワイヤレス保護ポリシーの一部であり、ポリシープロファイルごとに有効または無効にできます。これにより、いくつかの異なる動作の問題を検出し、クライアントをネットワークから削除し、一時的な除外リストに設定できます。クライアントがこの除外状態にある間、APはクライアントと通信しないため、それ以上のアクションを実行できません。

除外タイマーが経過した後（デフォルトでは60秒）、クライアントは再度関連付けを許可されます。

クライアントの除外には、次のようないくつかのトリガーがあります。

• アソシエーションの失敗が繰り返される
• 3つ以上のWebAuth、PSK、または802.1x認証エラー
• 認証タイムアウトが繰り返される（クライアントからの応答がない）
• 別のクライアントにすでに登録されているIPアドレスを再利用しようとする
• ARPフラッドの生成

クライアント除外は、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をプロトコルとして使用すると、ゼロタッチ方式でデバイス間のサービスを検出できますが、それと同時に、適切に設定しないと非常にアクティブになり、負荷が大幅に増大する可能性があります。

mDNSは、フィルタリングを行わずに、次のいくつかの要因によりWNCDのCPU使用率を簡単に上げることができます。

1. mDNSポリシーに無制限の学習が含まれている場合、コントローラはすべてのデバイスから提供されるすべてのサービスを取得します。これにより、数百のエントリを含む非常に大きなサービスリストが作成される可能性があります。
2. フィルタリングなしで設定されたポリシー：これにより、コントローラはこれらの大きなサービスリストを、特定のサービスの提供を要求する各クライアントにプッシュします。
3. 一部の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>