「Wireless 9800 WLC の KPI」ブログ(パート 3)

この記事は、Enterprise Wireless Escalation Business Unit の Engineering Technical Leader である Luis Alvarez によるブログ「Wireless 9800 WLC KPI Blog – Part 3」(2022/6/6)の抄訳です。

 

3 部構成の「Wireless Catalyst 9800 WLC KPI」シリーズのパート 3

以前のブログ「Wireless Catalyst 9800 WLC の KPI(パート 1)」と「Wireless Catalyst 9800 WLC の KPI(パート 2)」では、WLC のチェックおよび他のデバイスとの接続のチェックを行う方法と、AP と RF の正常性ステータスをチェックする方法を紹介しました。

今回のブログでは、クライアント分析、WLC のパケットドロップ、および WLC の CPU によって処理されるパケットのパフォーマンス評価指標に焦点を当てます。クライアントの接続の正常性と WLC の転送パフォーマンスを測定するための体系的な手順と WLC から収集できる出力を紹介します。

KPI 領域:

  • WLC のチェック
  • 他のデバイスとの接続
  • AP のチェック
  • RF のチェック
  • クライアントのチェック
  • パケットドロップ

 

クライアントのチェック

AP と RF の正常性を確認したら、次はクライアント接続に注目します。「show wireless summary」を使用すると、接続しているクライアントの総数を確認できます。さらに、除外されたクライアント、無効化されたクライアント、フォーリンクライアント、アンカークライアントがあるかどうかを調べることができます。このコマンドを定期的に実行して、モニタリングを続けましょう。クライアントの数が、導入環境で想定される値の範囲内であるかどうかをチェックします。また、いずれかの値に大幅な変化があるかどうかも確認します。このコマンドでは、AP の数、動作モード、radio、およびそれらのステータスも示されます。

Gladius1#sh wireless summary
Max APs supported          : 2000
Max clients supported      : 32000
Access Point Summary
Total    Up    Down
-----------------------------------------
802.11 2.4GHz             1     1       0
802.11 5GHz               4     3       1
802.11 dual-band          2     2       0
802.11 rx-dual-band       0     0       0
Client Serving(2.4GHz)    3     3       0
Client Serving(5GHz)      4     3       1
Monitor                   0     0       0
Sensor                    0     0       0
Client Summary
Total Clients : 6
Excluded      : 0
Disabled      : 0
Foreign       : 0
Anchor        : 0
Local         : 6

クライアントの総数、除外されたクライアントの数、radio がダウンしている AP の数をチェックする。

除外されたクライアントが見つかった場合は、さらに掘り下げてその理由を特定する必要があります。除外されたクライアントに設定不備があるかどうか、または他の理由があるかどうかを判断します。クライアントが除外される理由としては、パスワードの誤り、IP アドレスが他のクライアントの IP アドレスと一致している、複数のアソシエーションエラーなどが考えられます。コマンド「sh wireless wps summary」を使用すると、クライアント除外ポリシーとステータスのリストを確認できます。

クライアントステートマシンのさまざまな状態ごとに、接続しているクライアント数の内訳を確認できます。認証中、IP 学習、モビリティ、Webauth 保留中などの一時的な状態でスタックしているクライアントが膨大にある場合、この内訳を確認することでクライアントを絞り込むことができます。コマンドとして「show wireless stats client detail | i Authenticating            :|Mobility              :|IP Learn              :|Webauth Pending                    :|Run                    :|Delete-in-Progress     :」を使用します。

Gladius1#show wireless stats client detail | i Authenticating
:|Mobility     :|IP Learn     :|Webauth Pending        :|Run
:|Delete-in-Progress   :
Authenticating         : 0
Mobility               : 0
IP Learn               : 1
Webauth Pending        : 0
Run                    : 5
Delete-in-Progress     : 0

一時的な状態のクライアントをチェックする。この例では、1 つのクライアントが IP 学習状態にあることがわかる。

一時的な状態にあるクライアントの数が減少していない場合は、さらに調査を行う必要があります。大半のクライアントが長期間にわたり同じ一時的状態である場合も、さらなる調査が必要です。

一例として、多数のクライアントが「IP 学習」でスタックしていることがあります。その場合、DHCP サーバーのステータスと、WLC と DHCP サーバー間の接続を確認する必要があります。固定 IP アドレスが許可されているシナリオでは、ARP 転送も確認します。

もう 1 つの例は、「Webauth 保留中」でスタックしているクライアントの数が多い場合です。その原因はいくつか考えられます。1 つは、Web ページのリダイレクトを受信していないか、そのリダイレクトにクライアントがアクセスできないことが考えられます。もう 1 つの原因として考えられるのは、ゲスト SSID の Web ログインを実行するときに認証が失敗したことです。

最後の例は、多くのクライアントが「認証中」でスタックしている場合です。dot1x SSID に接続しているクライアントで認証の問題が発生している場合は、Radius サーバーを確認します。問題が特定の Radius サーバーで発生しているのか、複数のサーバーで同時に発生しているのかを判断する必要があります。以下のセクションでは、Radius サーバーのステータスを確認する方法について説明します。

クライアントの削除理由を確認し、カウンタが増加している予期しない理由を特定することもできます。「Idle timeout」や「Session timeout」はクライアント切断の予期される理由ですが、「DOT11 denied data rates」や「MIC validation failed」は予期しないものであり、場合によってはさらに分析が必要になります。コマンドとして「show wireless stats client delete reasons | e :_0」を使用します。

Gladius1#show wireless stats client delete reasons | e :_0
Total client delete reasons
---------------------------
Controller deletes
---------------------------
Due to mobility failure                                         : 1
DOT11 denied data rates                                         : 5781192
L2-AUTH connection timeout                                      : 2
IP-LEARN connection timeout                                     : 968
Mobility peer delete                                            : 134
----------------------------
Informational Delete Reason
-----------------------------
AP down/disjoin                                                 : 690
Session timeout                                                 : 661
-----------------------------
Client initiate delete
-----------------------------
AP Deletes
-----------------------------
AP initiated delete for DHCP timeout                            : 1
AP initiated delete for reassociation timeout                   : 266

カウントが多く、増加している予期しない削除理由をチェックする。この例では「denied data rates」が該当する。

私たちは世界最大級のワイヤレスイベントで、削除理由(ヒット数がゼロのものを除く)をモニタリングしました。そして、増え続けていた削除理由を特定できました。ALWAYS-ON トレース機能を使用した結果、削除されたクライアントはすべて特定の SSID に接続していたことがわかりました。さらに SSID の設定を確認して、切断の原因となっている設定ミスも特定できました。設定を修正すると、予期しない理由でクライアントが削除されることはなくなりました。問題をプロアクティブに特定し、根本原因を突き止めて修正できたのです。何よりも、ユーザから苦情が寄せられる前に、トラブルシューティング プロセスを始めることができました。

WLC には定義済みの起こり得る障害のリストもあり、この場合もカウンタが表示されます。カウンタをチェックして潜在的な問題を特定し、プロアクティブに問題を検出できます。コマンドとして「show wireless stats trace-on-failure | ex :_0」を使用します。

Gladius1#show wireless stats trace-on-failure | ex :_0
----------------------------------------------------------
Wireless Trace On Failure Statistics
----------------------------------------------------------
006. Export client MM....................................: 1
018. Capwap configuration status failure.................: 46136
020. Client association failure..........................: 5
021. Client MAB authentication failure...................: 5781677
023. Client stage timeout................................: 1642
025. Client mobility clean up............................: 1
027. DTLS handshake failure..............................: 2
030. DTLS no configuration packet drop...................: 5
032. DTLS invalid hello packet drop......................: 168
034. SANET AUTHC failure.................................: 6

カウントが多く、増加している障害をチェックする。この例ではMAB authentication failure」が該当する。

dot1x および Radius サーバーを使用している場合は、Radius サーバーのステータスをモニタリングする必要があります。IOS-XE は、デッドタイムとデッド条件を使用して Radius サーバーのステータスを判別しています。これらのパラメータにより、WLCは認証要求に応答していない Radius サーバーを識別し、セカンダリ Radius サーバーへの切り替えを実行できます。デッド条件が満たされると、サーバーはデッドであると宣言されます。デッド条件では、試行の失敗回数と、サーバーからの応答がない時間を指定します。サーバーがデッドと宣言されるには、両方の基準が満たされる必要があります。サーバーは、デッドタイムが期限切れになるまでデッドステータスのままになります。

現時点でデッドになっているサーバーがあるかどうか、サーバーがデッドと宣言された回数をチェックしてください。これにより、Radius または WLC からの接続の喪失または誤動作によって特定の Radius サーバーで発生している問題を診断できます。コマンドとして「show aaa servers | i Platform Dead: total|RADIUS: id」を使用します。

Gladius1#show aaa servers | i Platform Dead: total|RADIUS: id
RADIUS: id 1, priority 1, host 192.168.0.98, auth-port 1645, acct-port 1646, hostname ISE
SMD Platform Dead: total time 301s, count 2
Platform Dead: total time 179s, count 10UP
RADIUS: id 2, priority 2, host 192.168.0.99, auth-port 1812, acct-port 1813, hostname ISE3
SMD Platform Dead: total time 0s, count 0
Platform Dead: total time 0s, count 0

デッドタイムとデッド回数をチェックして、問題のある Radius サーバーを特定する。

Radius ステータスは WNCD ごとに表示されます。同じ Radius サーバーが、一部の WNCD ではデッドとしてマークされ、別の WNCD では稼働中としてマークされている可能性があります。各 AP は 1 つの WNCD に属します。WNCD ごとに割り当てられた AP をチェックするには、コマンド「show wireless load-balance ap affinity WNCD <0-7>」を使用します。特定の 1 つの WNCD の AP に接続しているクライアントが Radius 要求を送信し、その要求に応答がない場合、その WNCD の Radius ステータスは DEAD になります。それと同時に、他の WNCD のクライアントは Radius 要求を送信したり、応答を取得したりすることはできません。

Radius が DEAD としてマークされている場合、Radius サーバーが到達可能かどうか、認証要求とアカウンティング要求に応答しているかどうかをチェックする必要があります。Radius 統計を見ると、認証またはアカウンティングの応答が欠落しているかどうか、応答するまでの平均時間、アクセスの拒否と受け入れの数、遅延の分布を特定できます。コマンドとして「show radius statistics」を使用します。

Gladius1#show radius statistics
Auth.      Acct.       Both
Maximum inQ length:         NA         NA          1
Maximum waitQ length:         NA         NA         14
Maximum doneQ length:         NA         NA          1
Total responses seen:        279          0        279
Packets with responses:        279          0        279
Packets without responses:          0        396        396
Access Rejects           :          2
Access Accepts           :         20
Average response delay(ms):         10          0         10
Maximum response delay(ms):        173          0        173
Number of Radius timeouts:          0       4542       4542
Duplicate ID detects:          0          0          0
Buffer Allocation Failures:          0          0          0
Maximum Buffer Size (bytes):        764        780        780
Malformed Responses        :          0          0          0
Bad Authenticators         :          0          0          0
Unknown Responses          :          0          0          0
Source Port Range: (2 ports only)
1645 - 1646
Last used Source Port/Identifier:
1645/0
1646/3
Elapsed time since counters last cleared: 3w3d20h41m
Radius Latency Distribution:
<= 2ms :        181          0
3-5ms  :         32          0
5-10ms :         13          0
10-20ms:         14          0
20-50ms:         17          0
50-100m:         20          0
100ms :          2          0

応答のない要求、タイムアウト、高遅延をチェックする。

以前あるお客様の dot1x クライアントの接続の問題をトラブルシューティングしたとき、障害の原因として Radius サーバーがデッドとマークされていることを突き止めたことがありました。出力を確認すると、Radius は認証に応答していましたが、アカウンティングパケットに応答しなくなっていたことがわかりました。影響を最小限に抑えるための回避策として、Radius 管理者がサーバーのアカウンティングの問題をトラブルシューティングしている間、アカウンティングリストを無効にして WLC がアカウンティングパケットを送信しないようにしました。

パケットドロップと WLCのCPUによって処理されるパケットのチェック

次に、いずれかの WLC コンポーネントのオーバーサブスクリプションが原因で拡張性の問題が発生しているかどうかをチェックします。まず、物理インターフェイスで送受信されるトラフィックの量を調べます。そして、ブロードキャスト/マルチキャストおよび入出力ドロップの数を確認します。トラフィックの基準がある場合は、トラフィックの量を基準と比較すると、不一致を見つけることができます。コマンドとして「show int po1 | i line protocol|put rate|drops|broadcast」を使用します。Po1 は、設定した物理インターフェイスまたは論理インターフェイスに置き換えてください。

Gladius1#show int po1 | i line protocol|put rate|drops|broadcast
Port-channel1 is up, line protocol is up
Input queue: 0/375/0/0 (size/max/drops/flushes); Total output drops: 0
5 minute input rate 39000 bits/sec, 42 packets/sec
5 minute output rate 14000 bits/sec, 12 packets/sec
Received 9389675 broadcasts (34521510 multicasts)
Output 45735 broadcasts (1075205 multicasts)
0 unknown protocol drops

トラフィックの入出力、ドロップ、およびブロードキャスト 送信/受信 の量をチェックする。

WLC によってドロップされたパケットと、ドロップの原因を確認できます。ドロップをモニタリングするときは、大量のパケットドロップの原因をチェックすることが重要です。その後、それらのドロップカウンタの増加速度を確認します。時刻基準を使用して同じ出力を数回収集する必要があります。「terminal exec prompt timestamp」を有効にするか、「show clock」を収集すると、時刻基準を取得できます。これらの時刻基準の出力は、影響のあるドロップを切り分けるうえで重要になります。コマンドとして「show platform hardware chassis active qfp statistics drop」を使用します。

Gladius1#show platform hardware chassis active qfp statistics drop
Last clearing of QFP drops statistics : never
-------------------------------------------------------------------------
Global Drop Stats                         Packets                  Octets
-------------------------------------------------------------------------
CGACLDrop                                      31                    7812
Disabled                                      635                  105934
InvL2Hdr                                      701                  206223
IpFormatErr                                    68                    4488
Ipv4NoAdj                                   67749                 6910538
Ipv4NoRoute                                     6                     376
Ipv6NoRoute                                  1096                   61376
Ipv6mcNoRoute                               77683                 9477326
SWPortMacConflict                           50316                 5874782
SwitchL2mLookupMiss                         17568                 6681680
TailDrop                                    54199                29501684
UnconfiguredIpv4Fia                             3                     242
UnconfiguredIpv6Fia                       1564372               186850863
WlsCapwapError                               1018                  233293
WlsCapwapReassFragConsume                    1064                 1231968
WlsClientError                            3116                  112631

パケット数が多いドロップの原因、およびフラグメンテーション/リアセンブルドロップの原因をチェックする。

もう 1 つ必要なチェックは、処理のために WLC のCPUに送信されたパケットの数を分析することです。各々の理由でCPU処理されたパケット数をモニタリングし、異常な量になっていないかチェックします。CPU処理されたパケットが増加している場合、CPU 使用率の高いイベントと関連があると考えられます。コマンドとして「show platform hardware chassis active qfp feature wireless punt statistics」を使用します。

Gladius1#show platform hardware chassis active qfp feature wireless punt statistics
CPP Wireless Punt stats:
App Tag                                   Packet Count
-------                                   ------------
CAPWAP_PKT_TYPE_DOT11_PROBE_REQ           986190
CAPWAP_PKT_TYPE_DOT11_MGMT                10031
CAPWAP_PKT_TYPE_DOT11_IAPP                2975298
CAPWAP_PKT_TYPE_DOT11_DOT1X               24901
CAPWAP_PKT_TYPE_CAPWAP_KEEPALIVE          228099
CAPWAP_PKT_TYPE_CAPWAP_CNTRL              1628480
CAPWAP_PKT_TYPE_CAPWAP_DATA_PAT           33
CAPWAP_PKT_TYPE_MOBILITY_CNTRL            58091
SISF_PKT_TYPE_ARP                         218545290
SISF_PKT_TYPE_DHCP                        15455
SISF_PKT_TYPE_DHCP6                       7772
SISF_PKT_TYPE_IPV6_ND                     199108
SISF_PKT_TYPE_DATA_GLEAN                  7
SISF_PKT_TYPE_DATA_GLEAN_V6               100

CPU処理のパケットの数が多く、増加しているかどうかをチェックする。

また、バッファ障害が発生しているかどうかを特定し、最大値に達しているバッファのサイズを確認することもできます。コマンドとして「show buffers | i buffers|failures」を使用します。

Gladius1#show buffers | i buffers|failures
Small buffers, 104 bytes (total 1200, permanent 1200):
0 failures (0 no memory)
Middle buffers, 600 bytes (total 900, permanent 900):
35 failures (35 no memory)
Big buffers, 1536 bytes (total 900, permanent 900, peak 901 @ 2w6d):
0 failures (0 no memory)
VeryBig buffers, 4520 bytes (total 100, permanent 100, peak 101 @ 2w6d):
0 failures (0 no memory)
Large buffers, 5024 bytes (total 100, permanent 100, peak 101 @ 2w6d):
0 failures (0 no memory)
VeryLarge buffers, 8304 bytes (total 100, permanent 100):
0 failures (0 no memory)
Huge buffers, 18024 bytes (total 20, permanent 20, peak 21 @ 2w6d):
0 failures (0 no memory)

バッファ障害をチェックし、バッファサイズを特定する。

最後のチェックは、データプレーンの使用率です。トラフィックの量あるいは特定機能の有効化が原因で、 WLC にデータプレーンのパフォーマンスの問題が発生しているかどうかを確認します。WLC のチェックで紹介したコマンド「show platform hardware chassis active qfp datapath utilization | i Load」を使用します。

これらの KPI のおかげで、あるお客様の問題を特定できました。お客様は、CPU 処理される ARP パケットの数が定期的に大きく増加することを観察していました。CPU 処理された ARP のカウンタをモニタリングし、コントロールプレーンでパケットキャプチャを収集したことで、それらの ARP が、悪意のある ARP スキャンを実行している特定の MAC アドレスから送信されたことを特定できました。

Catalyst 9800 WLC のパフォーマンス評価指標(KPI)の説明は以上です。

KPI および自動化スクリプトに使用するコマンドのリスト

以下のドキュメントには、すべてのコマンドを自動的に収集するスクリプトへのリンクも掲載されています。このスクリプトはプラットフォームとリリースに基づいてコマンドを収集し、ファイルに保存して、そのファイルをエクスポートします。このスクリプトは「ゲストシェル」機能を使用しており、現時点では物理アプライアンスの WLC 9800-40/80 および 9800-L でのみ使用できます。

このドキュメントでは、定期的にログを収集する EEM スクリプトの例も紹介しています。結論としては、EEM と「ゲストシェル」スクリプトを使用すると、9800 WLC の KPI を収集して Catalyst 9800 WLC の基準を作成できます。

 

これらの KPI をモニタリングするために使用するコマンドのリストについては、

Wireless Catalyst 9800 KPI のモニタリングをご覧ください

 

鈴木 美香

2001 年シスコシステムズに入社。関西エリアの顧客担当SEを長く経験した後、現在は無線 LAN 専任の SE として、アクセスポイントや無線 LAN コントローラ、運用管理ソリューション、ロケーション分析まで、幅広い無線 LAN 製品のプリセールスおよびパートナー様のサポートに従事。プライベートでは、毎週末に演劇やダンス、バレエを見に行くのを楽しみにしています。