2022年7月25日 Leave a Comment

「Wireless 9800 WLC の KPI」ブログ（パート 3）

2 min read

鈴木美香

この記事は、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」を使用すると、クライアント除外ポリシーとステータスのリストを確認できます。

一時的な状態のクライアントをチェックする。この例では、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 のモニタリング」をご覧ください

Authors

鈴木美香

テクニカルソリューションズアーキテクト

システムズエンジニアリングエンタープライズネットワーキング

Tags:

コメントを書く

「Wireless 9800 WLC の KPI」ブログ（パート 3）

クライアントのチェック

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

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

Authors

鈴木 美香

テクニカルソリューションズアーキテクト

システムズエンジニアリングエンタープライズネットワーキング

鈴木美香