この記事は、Enterprise Wireless Escalation Business Unit の Engineering Technical Leader である Luis Alvarez によるブログ「Wireless Catalyst 9800 WLC KPIs, Part 2
」（2022/6/21）の抄訳です。
3 部構成の「Wireless Catalyst 9800 WLC の KPI」シリーズのパート 2
前回のブログ Wireless Catalyst 9800 WLC の KPI（パート 1）では、WLC のチェックと、他のデバイスとの接続のチェックについて説明しました。
今回のテーマは、アクセスポイント（AP）と無線周波数（RF）の主なパフォーマンス評価指標です。AP と RF の正常性を測定するためのアプローチとコマンドを紹介します。
KPI 領域：
- WLC のチェック
- 他のデバイスとの接続
- AP のチェック
- RF のチェック
- クライアントのチェック
- パケット損失
AP のチェック
まずは AP の正常性に注目してみましょう。最初のステップとして、WLC に接続されている AP の総数をチェックし、想定される数と一致していることを確認します。コマンドとして「show ap sum | i Number of APs」を使用します。AP の数が正しくない場合は、不足している AP、切断が発生した理由、それらの AP がコントローラに再接続できなかった理由を特定する必要があります。原因を調べるための出発点として、イーサネット MAC アドレスと IP アドレスが記載された、正常動作シナリオにおける AP の全リストを出力しておくと便利です (「show ap summary」)。
Gladius1#show ap sum
Load for five secs: 0%/0%; one minute: 0%; five minutes: 0%
Time source is NTP, 19:18:03.363 CEST Wed May 25 2022
Number of APs: 8
AP Name Slots AP Model Ethernet MAC Radio MAC Location Country IP Address State
---------------------------------------------------------------------------------------------------------------------------------------------
AP3800-r2sw1-te1-0-8 2 AIR-AP3802I-E-K9 0042.68a0.fc4a 0062.ecf3.8310 default location DE 192.168.127.108 Registered
9130i-r2sw1-te2016 3 C9130AXI-E 04eb.409e.14c0 04eb.409f.0c60 default location DE 192.168.25.133 Registered
9130i-r2sw1-te2015 3 C9130AXI-E 04eb.409e.1724 04eb.409f.1f80 default location DE 192.168.25.122 Registered
9130i-r3-sw2-g1-0-10 3 C9130AXI-B 04eb.409e.1d28 04eb.409f.4fa0 default location US 192.168.127.113 Registered
AP1562-r3-sw-3-gi1-0-3 2 AIR-AP1562E-E-K9 0062.ec80.8c8c 2c33.1192.3e40 default location DE 192.168.127.106 Registered
SS-I-1 2 C9115AXI-B 7069.5a74.7a50 7069.5a78.7780 default location US 192.168.127.97 Registered
ap3800i-r2-sw1-te1-0-5 2 AIR-AP3802I-E-K9 0042.68c5.bdf0 cc16.7e5f.f000 default location CH 192.168.127.109 Registered
9120i-r4-sw2-te1-0-39 2 C9120AXI-E d4e8.8019.60e8 d4e8.801a.3340 default location DE 192.168.127.114 Registered
AP の数をチェックして、すべての AP のイーサネット MAC アドレスとIP アドレスのリストを用意する。
正常動作シナリオと正常動作以外のシナリオの出力を比較すると、不足しているデバイスとその場所をすばやく特定できます。
WLC に接続されている AP の数が想定どおりである場合でも、それらの AP が安定しているかどうかをチェックする必要があります。WLC には、稼働時間（再起動）のチェックや Capwap トンネル信頼性の検証を簡単に実行できるコマンドが用意されています。コマンドとして「show ap uptime | ex ____([0-9])+ day」を使用します。「exclude」キーワードを指定すると、過去 1 日以内に再起動または切断された AP を特定しやすくなります。
Gladius2#sh ap uptime
Number of APs: 8
AP Name Ethernet MAC Radio MAC AP Up Time Association Up Time
---------------------------------------------------------------------------------------------------------------------------------
AP3800-r2sw1-te1-0-8 0042.68a0.fc4a 0062.ecf3.8310 26 days 0 hour 57 minutes 41 seconds 15 days 1 hour 50 minutes 4 seconds
9130i-r2sw1-te2015 04eb.409e.1724 04eb.409f.1f80 9 days 3 hours 26 minutes 48 seconds 9 days 3 hours 24 minutes 24 seconds
9130i-r2sw1-te2016 04eb.409e.14c0 04eb.409f.0c60 9 days 1 hour 39 minutes 29 seconds 9 days 1 hour 26 minutes 47 seconds
9120i-r4-sw2-te1-0-39 d4e8.8019.60e8 d4e8.801a.3340 8 days 1 hour 36 minutes 57 seconds 8 days 1 hour 33 minutes 49 seconds
SS-I-1 7069.5a74.7a50 7069.5a78.7780 26 days 0 hour 54 minutes 57 seconds 22 minutes 15 seconds
ap3800i-r2-sw1-te1-0-5 0042.68c5.bdf0 cc16.7e5f.f000 26 days 0 hour 46 minutes 12 seconds 22 minutes 13 seconds
9130i-r3-sw2-g1-0-10 04eb.409e.1d28 04eb.409f.4fa0 22 minutes 21 seconds 19 minutes 39 seconds
稼動時間とアソシエーションの稼動時間をチェックする。この場合、SS-I-1 と ap3800i-r2-sw1-te1-0-5 で切断が発生し、9130i-r3-sw2-g1-0-10 で再起動が発生していることがわかる。
上記のコマンドでは、AP で予期しない再起動が発生したかどうかを確認できます。複数の AP で同時に再起動が発生したかどうかも確認できます。再起動したそれらの AP が同じ場所にあるか、同じスイッチに接続されている場合、その場所やそのスイッチのネットワークまたは電源に問題がある可能性があります。同様に、AP の切断が発生している場合、「アソシエーションの稼動時間」を比較することで、それらの間のパターンを見つけ出し、トンネルの予期しないティアダウンが発生しているかどうかと、発生している場合はそれがいつ発生したのかを特定できます。特定の構成が変更された場合、たとえば新しいタグが適用されたときなど、AP は CAPWAP トンネルをつなぎ直すことに注意してください。
「AP の稼動時間」が想定よりも短く、一般的な再起動によるものではない場合は、WLC で AP クラッシュが報告されているかどうかを確認し、関連するレポートファイルについてブートフラッシュの内容を調べます。コマンドとして「show ap crash」または「dir bootflash: | i crash」を使用します。
Gladius1#show ap crash-file
File Location: BOOTFLASH
AP Name Crash File Radio Slot 0 Radio Slot 1
-------------------------------------------------------------------------------------------------
ap3800i-r2-sw1-te0-1 ap3800i-r2-sw1-te0-1_0062ecaade80.crash
Gladius1#dir bootflash: | i crash
54 -rw- 50476 May 9 2022 13:07:34 +02:00 ap3800i-r2-sw1-te0-1_0062ecaade80.crash
66 -rw- 120276 Jan 26 2022 11:46:55 +01:00 AP9120-2-r3-sw2-Gi1-0-39_d4e88019f140.crash
28 -rw- 93952 Nov 2 2021 13:02:21 +01:00 SS-E-2_00eeab18c160.crash
12 -rw- 42975 Oct 27 2021 15:01:44 +02:00 9115i-r4-sw2-te1-0-38_f80f6f154ce0.crash
42 -rw- 42235 May 15 2021 14:24:59 +02:00 9115i-r3-sw2-te1-0-38_f80f6f154960.crash
41 -rw- 26063 Mar 30 2021 13:06:45 +02:00 9115i-r3-sw2-te1-0-38_f80f6f154c80.crash
AP のクラッシュをチェックする。同じ AP で複数のクラッシュが発生しているか、定期的にクラッシュが発生しているかどうかを確認する。
ブートフラッシュの内容を定期的に確認して、新しいクラッシュを特定することをお勧めします。新しいクラッシュが発生している場合は、そのクラッシュをダウンロードして、根本原因分析のために TAC にご提供ください。最後に、古いクラッシュを削除して、ファイルシステムをクリーンな状態に保ちます。
AP の切断が確認された場合は、最もよく発生している終了イベントは何か、その時点の AP の状態はどうだったのかを体系的に分析します。そうすることで、問題の全体像を把握できます。コマンドとして「show wireless stats ap session termination」を使用します。
Gladius1#show wireless stats ap session termination
Event Previous State Occurance Count
-----------------------------------------------------------------------------
DTLS session closed JOINED 6
Heartbeat timer expiry JOINED 2
Reset by API IMAGE_DOWNLOAD 1
Image download status IMAGE_DOWNLOAD 6
Reset by API RUN 3
DTLS session closed RUN 17
Heartbeat timer expiry RUN 6
件数が最も多いイベントをチェックする。AP が RUN 状態の場合、切断の発生は、一貫したパケット損失に起因する可能性がある。
その後、AP 履歴コマンドで詳細をドリルダウンし、具体的な AP ごとに詳細な情報を取得します。AP 履歴を切断でフィルタリングすると、同時に複数の AP の切断が発生しているかどうかと、各 AP の切断の理由を確認できます。コマンド出力を分析することで、同一の AP で複数回の切断が発生しているかどうかと、切断の周期も把握できます。コマンドとして「show wireless stats ap history | i Disjoined」を使用します。
Gladius1#show wireless stats ap history | i Disjoined
ap3800i-r2-sw1-te0-1 0042.68a0.ee78 Disjoined 05/24/22 12:27:39 NA DTLS close alert from peer
ap3800i-r2-sw1-te0-1 0042.68a0.ee78 Disjoined 05/24/22 12:24:26 NA DTLS close alert from peer
ap3800i-r2-sw1-te0-1 0042.68a0.ee78 Disjoined 05/24/22 12:17:47 NA DTLS close alert from peer
ap3800i-r2-sw1-te0-1 0042.68a0.ee78 Disjoined 05/24/22 11:41:17 NA DTLS close alert from peer
ap3800i-r2-sw1-te0-1 0042.68a0.ee78 Disjoined 05/24/22 11:38:04 NA DTLS close alert from peer
ap3800i-r2-sw1-te0-1 0042.68a0.ee78 Disjoined 05/24/22 10:18:04 NA DTLS close alert from peer
ap3800i-r2-sw1-te0-1 0042.68a0.ee78 Disjoined 05/09/22 13:02:28 NA Heart beat timer expiry
ap3800i-r2-sw1-te0-1 0042.68a0.ee78 Disjoined 05/09/22 10:49:34 NA Heart beat timer expiry
ap3800i-r2-sw1-te0-1 0042.68a0.ee78 Disjoined 05/05/22 19:53:31 NA Failure decoding wtp descriptor
ap3800i-r3-sw2-Gi1-0-37 0042.68a1.03d2 Disjoined 05/12/22 12:02:38 NA DTLS close alert from peer
ap3800i-r3-sw2-Gi1-0-37 0042.68a1.03d2 Disjoined 05/12/22 11:57:43 NA Wtp reset config cmd sent
ap3800i-r3-sw2-Gi1-0-37 0042.68a1.03d2 Disjoined 05/10/22 10:54:49 NA DTLS close alert from peer
タイムスタンプと切断の理由をチェックする。同一の AP で複数回の切断が発生しているかどうか、それが同時または定期的に発生しているかを特定する。
重要なチェックがもう 1 つあります。それは、AP タグの割り当てを確認することです。タグによって、各 AP で構成される SSID、AP モード、RF プロファイル、ポリシーが決まります。AP に想定どおりのタグがあり、タグの割り当てに正しい方法が使用されていることを確認します。同じ場所の AP に付けられているタグを比較したり、動作している AP と動作していない AP を比較したりすることで、タグの不適切な割り当てを特定できる可能性があります。コマンドとして「sh ap tag summary」を使用します。
また、タグが誤って構成されたことを示す AP がないかどうかも確認する必要があります。タグが誤って構成されている原因として、存在しないまたは削除されたパラメーター（ポリシープロファイル、RF プロファイルなど）が使用されている、または構成の組み合わせが正しくないなどが考えられます。構成が間違っているとマークされた AP は、BSSID をブロードキャストしません。コマンドとして「sh ap tag summary | i Yes」を使用します。
Gladius1#sh ap tag summary
Number of APs: 4
AP Name AP Mac Site Tag Name Policy Tag Name RF Tag Name Misconfigured Tag Source
---------------------------------------------------------------------------------------------------------------
HG-2 0cd0.f894.0f40 default-site-tag default-policy-tag default-rf-tag No Default
AP1832I 80e8.6fd8.6330 site2 flex-vlan4 rf-hig No Location
ap1700i f44e.0578.a560 site2 default-policy-tag default-rf-tag Yes Static
AP9120 d4e8.8019.6100 default-site-tag LOCAL_VLAN169 default-rf-tag No Filter
誤って構成されているタグ、正しいタグソース、および同じ拠点内の AP の同じタグ割り当てをチェックする。
AP が稼働していて構成に問題がない場合でも、さらにチェックを行って、クライアントが未接続で正常に動作しない可能性がある AP を特定することができます。正常に動作している AP でも、チェックするとクライアントなしと表示される場合があるため、注意が必要です。ネットワークに関する知識を活用しながら、同じエリア内の他の AP で見られるクライアントの数を参考にして、問題が発生している可能性のある AP を切り分けることができます。これらの AP については、radioが機能していること、AP が正しい BSSID をブロードキャストしていることを確認してから、それらの AP を一定期間モニタリングします。モニタリング期間後も AP でクライアントなしと表示される場合は、AP radioまたは WLC との CAPWAP 接続をリセットし、状況が回復するかどうかをテストします。コマンドとして「show ap sum sort descending client-count | i __0__」を使用します。
Gladius1#show ap sum sort descending client-count | i __0__
--------------------------------------------------------------------------------------
AP-name AP-mac Client count Data Usage Through-Put Admin-State
--------------------------------------------------------------------------------------
9120i d4e8.801a.3340 0 1407172 515 Enabled
AP1562 2c33.1192.3e40 0 4189901 69 Disabled
AP3800 0062.ecf3.8310 0 48548613 473 Disabled
クライアントの数がゼロで状態が Enabled の AP がないかチェックする。
問題の特定に役立つ AP の KPI の一例として、ランダムな AP 切断に直面した顧客のケースを紹介します。「show AP uptime」を分析して、頻繁に切断されている AP を確認したところ、影響を受けた AP の一覧が得られました。顧客 のAP の命名規則と「show ap cdp neighbors」の出力を組み合わせて確認できたので、すべての AP が同じ場所にあり、1 つのスイッチに接続されていることがわかりました。それらの AP で切断が発生していた理由から、AP が接続をクローズしたことが原因であると判明したのです。AP のログをチェックすると、CAPWAP パケットの再送信が複数回発生していることを確認できました。次に、AP から WLC への ping をテストしたところ、パケット損失が確認されました。AP からゲートウェイに ping を実行したときにも、同じパケット損失を確認できました。ping テストでは、AP とゲートウェイ間のスイッチに接続の問題があることが明確に示されていたのです。
RF のチェック
周波数帯ごとの AP のチャネル割り当て、チャネル幅、送信電力、radioの状態をモニタリングできます。その情報に基づいて、同一チャネル干渉を回避するためにチャネルが均等に分散されているかどうかを確認するとともに、多数の AP で最大送信電力が使用されているかどうかを特定します。最大送信電力が使用されている場合は、カバレッジに問題がある可能性があります。また、radioが動作せず、ダウンとマークされている AP があるかどうかも確認できます。この検証は、新しい 9136 AP の 24GHz、5 GHz 、および 6GHz に対して行う必要があります。コマンドとして「show ap dot11 24ghz/5 GHz /6ghz summary」を使用します。BSS カラーリングをサポートする 11ax AP がある場合は、「extended」キーワードを追加すると、各 AP に割り当てられた BSS カラーを確認できます。
Gladius1#sh ap dot11 5ghz summary
AP Name Mac Address Slot Admin State Oper State Width Txpwr Channel Mode
-------------------------------------------------------------------------------------------------
9130E 0c75.bdb5.71e0 1 Enabled Up 20 *2/8 (21 dBm) (100)* Local
9130E 0c75.bdb5.71e0 2 Disabled Down 20 *1/8 (15 dBm) (36)* Local
AP9120A d4e8.8019.f140 1 Enabled Up 20 *2/8 (19 dBm) (40)* Local
AP9120B d4e8.801a.3400 1 Enabled Up 20 7/8 (4 dBm) (40) Local
Txpwr 1、不均等なチャネル分布、radioのダウン、予期しない静的チャネル割り当てがあるかどうかをチェックする。
次の統計では、各radioで発生したチャネル変更の数を確認できます。5 GHz の場合、レーダーが同じチャネルで検出されたために AP がチャネルを変更しているかどうかを調査できます（DFS イベント）。チャネルの変更が何度も発生し、その数が増えている場合は、クライアントの接続に影響している可能性があります。チャネルを変更すると、AP のradioがリセットされ、すべてのクライアントが切断されます。5 GHz で DFS チャネルへのチャネル変更が発生すると、その間クライアントはその AP に接続できないため、AP のradioはビーコンを送信する前に 60 秒間チャネルをモニタリングする必要があります。チャネル変更が過度に発生している場合は、RF または RRM に問題があることを示している可能性があり、調査が必要です。コマンドとして「show ap auto-rf dot11 24ghz/5 GHz | i Channel changes due to radar|AP Name|Channel Change Count」を使用します。
Gladius1#sh ap auto-rf dot11 5ghz | i Channel changes due to radar|AP Name|Channel Change Count
AP Name : 9130E-r3-sw2-g1014
Channel changes due to radar : 0
Channel Change Count : 2
AP Name : 9130E-r3-sw2-g1014
Channel changes due to radar : 0
AP Name : AP9120-2-r3-sw2-Gi1-0-39
Channel changes due to radar : 3
Channel Change Count : 10
AP Name : AP9120-r3-sw3-Gi1-0-47
Channel changes due to radar : 0
Channel Change Count : 62
多数のチャネル変更や DFS イベントによる変更があるかチェックする。
もう 1 つチェックできる項目は、radioごとの負荷またはチャネル使用率です。Catalyst 9800 WLC では、チャネル使用率とクライアント数が表示されるため、負荷の高い AP を特定できます。クライアントの数が少ないのに負荷が高い AP が見つかった場合は、それらの AP に注目して、その AP が送受信しているトラフィックが原因なのか、同一チャネル干渉が原因なのかを確認します。負荷に関する情報を見ると、最も負荷が高い AP と、より高い密度が必要である可能性がある領域を特定することもできます。コマンドとして「show ap dot11 24ghz/5 GHz /6ghz load-info」を使用します。
Gladius1#sh ap dot11 5ghz load-info
AP Name Radio MAC Slot Channel Utilization (%) Clients
-----------------------------------------------------------------------------
9130E 0c75.bdb5.71e0 1 2 0
9130E 0c75.bdb5.71e0 2 0 0
AP9120A d4e8.8019.f140 1 11 5
AP9120B d4e8.801a.3400 1 11 0
チャネル使用率が高いものや、クライアントの数がゼロでチャネル使用率が発生しているもの（同一チャネル干渉）があるかどうかをチェックする。AP9120A と 9120B は両方とも同じチャネル 40 にあるため、同一チャネル干渉が見られる。
RF のこれらの KPI をチェックして特定できた問題の例として、クライアントのパフォーマンスの問題が発生していた顧客のケースを紹介します。調査したところ、接続されているクライアントがほとんど、またはまったくない場合でも、5 GHz のradio負荷が非常に高いことがわかりました。さらに調査すると、その負荷はデータの送受信によるものではなく、同一チャネル干渉によるものでした。負荷が高い AP に割り当てられたチャネル数を分析すると、RF プロファイルの設定の問題により、これらの AP に割り当てられたチャネルは 4 つだけであったことがわかりました。RF プロファイルにチャネルを追加すると、使用率が低下し、それ以上のパフォーマンスの問題は報告されなくなりました。
Wireless Config Analyzer Express（WCAE）ツール（https://developer.cisco.com/docs/wireless-troubleshooting-tools/#wireless-config-analyzer-express）を使用すると、より詳細な RF 分析を実行できます。
WCAE では、チャネルの分布、送信電力、各 AP の RF メトリックなどの詳細情報が表示されます。
利用可能な手法とコマンドを使用して、WLC AP と RF に問題があるかどうかをプロアクティブに特定できます。次回のブログでは、クライアント接続と WLC ドロップパケットをチェックする際に役立つ、9800 WLC の KPI を紹介します。
KPI および自動化スクリプトに使用するコマンドのリスト
以下のドキュメントには、すべてのコマンドを自動的に収集するスクリプトへのリンクも掲載されています。このスクリプトはプラットフォームとリリースに基づいてコマンドを収集し、ファイルに保存して、そのファイルをエクスポートします。このスクリプトは「ゲストシェル」機能を使用しており、現時点では物理 WLC 9800-40/80 および 9800-L でのみ使用できます。
このドキュメントでは、定期的にログを収集する EEM スクリプトの例も紹介しています。結論としては、EEM と「ゲストシェル」スクリプトを使用すると、9800 WLC の KPI を収集して Catalyst 9800 WLC の基準を作成できます。
これらの KPI をモニタリングするために使用するコマンドのリストについては、
「Wireless Catalyst 9800 の KPI のモニタリング
Authors
