Wireless Catalyst 9800 WLC の KPI（パート 1）
この記事は、Enterprise Wireless Escalation Business Unit の Engineering Technical Leader である Luis Alvarez によるブログ「Wireless Catalyst 9800 WLC KPIs, Part 1
」（2022/6/13）の抄訳です。
3 部構成の「Wireless Catalyst 9800 WLC の KPI」シリーズのパート 1
重要なワイヤレスインフラの運営では、プロアクティブに行動し、エンドクライアントのエクスペリエンスに影響を与えかねない問題を事前に突き止めることが重要です。そのような問題の特定には、Wireless Catalyst 9800 WLC の KPI が役立ちます。
このブログでは、世界最大級のワイヤレスイベントで NOC のサポートをシスコが担当した際に、私が用いた体系的なアプローチとコマンドのリストを紹介します。ここでの鍵は、Catalyst 9800 WLC の主なパフォーマンス評価指標（KPI）をモニタリングする方法を常に注視することです。
KPI の出力を定期的に収集することで、ネットワークが正常に機能している場合の基準を作成できるからです。基準があると、後で新しい出力と以前に収集した出力とを比較して、誤差を見つけやすくなります。
私は WLC の KPI を 6 つの領域に分類しました。
- WLC のチェック
- 他のデバイスとの接続
- AP のチェック
- RF のチェック
- クライアントのチェック
- パケットドロップ
KPI は、この 6 つの領域の問題を特定するのに効果的です。このブログでは、「WLC のチェック」と「他のデバイスとの接続」について説明します。また、「AP のチェック」、「RF のチェック」、「クライアントのチェック」、「パケットドロップ」について紹介するブログ記事をこの後 2 回に分けてお届けします。
WLC のチェック
WLC は最も重要な部分なので、私はたいてい最初に WLC をチェックしています。コントローラに問題が見つかった場合、 AP とクライアントの問題としてすぐに連鎖するからです。そこで重要になるのが、トップダウンで基準を設けたチェック体制です。
WLC の正常性状態を確認しながら、まずは WLC で想定どおりのバージョンが実行されていることと、インストールモードであることを確認します。インストールモードであれば、コントローラの起動時間が短くなり、メモリ消費量も少なくなります。確認が完了したら、WLC の稼働時間をチェックして、再起動が発生したかどうかを調べます。コマンドとして「show version | i uptime|Installation mode|Cisco IOS Software」を使用します。
Gladius1#show version | i uptime|Installation mode|Cisco IOS Software
Cisco IOS Software [Amsterdam], C9800 Software (C9800_IOSXE-K9), Version 17.3.5a, RELEASE SOFTWARE (fc2)
Gladius1 uptime is 2 weeks, 5 days, 21 hours, 30 minutes
Installation mode is INSTALL
想定どおりのリリースかどうか、稼働時間はどうか、WLC がインストールモードで実行されているかどうかをチェックする。
重要な導入環境では Catalyst 9800 WLC を高可用性構成で導入することを強くお勧めしていますが、その場合は、まず HA ペアスタックが形成されていてスタンバイホット状態であることを確認する必要があります。次に、スタックの稼働時間と各メンバーの稼働時間をチェックします。その後、アクティブとスタンバイのスイッチオーバーの数を特定します。コマンドとして「show redundancy | i ptime|Location|Current Software state|Switchovers」を使用します。
Gladius1#show redundancy | i ptime|Location|Current Software state|Switchovers
Available system uptime = 2 weeks, 1 day, 2 hours, 48 minutes
Switchovers system experienced = 1
Active Location = slot 1
Current Software state = ACTIVE
Uptime in current state = 7 hours, 10 minutes
Standby Location = slot 2
Current Software state = STANDBY HOT
Uptime in current state = 7 hours, 4 minutes
スタックの稼働時間、スイッチオーバーの数、メンバーの稼働時間をチェックする。スイッチオーバーは 7 時間前に発生。Slot1 が新しくアクティブになり、Slot2 が再起動した。
HA 導入環境では、RMI 機能を使用することをお勧めします。そうすることで、ワイヤレス管理インターフェイス（WMI）と冗長ポート（RP）を介してアクティブとスタンバイをモニタリングできます。その後、デフォルトゲートウェイのチェックを有効にして、アクティブとスタンバイの両方がゲートウェイに到達できることを確認する必要があります。『9800 高可用性導入ガイド』はこちらでご覧いただけます。
次のステップは、WLC のクラッシュが発生しているかどうかを確認することです。クラッシュが発生した時刻が、スイッチオーバーや予期しない再起動が発生した時刻と一致するかどうかを確認します。WLC がクラッシュすると、コアダンプかシステムレポートが生成されます。これらのファイルは、9800-40/80 の場合は WLC のハードディスクに、9800-L/CL の場合はブートフラッシュに保存されます。コマンドとして「dir harddisk:/core/ | i core|system-report」、「dir stby-harddisk:/core/| i core|system-report」を使用します。9800-L/CL の場合は、harddisk を bootflash に置き換えてください。
Gladius1#dir harddisk:/core/ | i core|system-report
Directory of harddisk:/core/
3661831 -rw- 11260562 Mar 25 2022 22:07:12 +01:00 Gladius1_1_RP_0_wncd_16574_20220325-220708-CET.core.gz
3661830 -rw- 48528 Mar 25 2022 21:57:20 +01:00 Gladius1_1_RP_0-system-report_20220325-215658-CET-info.txt
3661829 -rw- 126548098 Mar 25 2022 21:57:10 +01:00 Gladius1_1_RP_0-system-report_20220325-215658-CET.tar.gz
3661828 -rw- 57191 Mar 9 2021 16:21:48 +01:00 Gladius1_1_RP_0-system-report_20210309-161907-CET-info.txt
3661827 -rw- 504311304 Mar 9 2021 16:20:51 +01:00 Gladius1_1_RP_0-system-report_20210309-161907-CET.tar.gz
3661826 -rw- 11714625 Nov 19 2020 10:35:54 +01:00 Gladius1_1_RP_0_wncd_30240_20201119-103550-CET.core.gz
core と system report をチェックする。wncd プロセスで 2 回の core reportが発生し、2 回の system report が発生している。
コアダンプがある場合は、ファイル名を確認すると、影響を受けたプロセスを特定できます。たとえば、WLC_1_RP_0_wncd_16574_20220325-220708-CET.core.gz のクラッシュは「wncd」プロセスで発生しており、WLC_1_RP_0_dbm_14119_20201104-092800-CET.core.gz のクラッシュは「dbm」プロセスで発生しています。TAC ケースを作成して、クラッシュの根本原因を特定します。
クラッシュや予期しない再起動を確認したら、次は WLC の CPU 使用率とメモリ使用量を調べます。CPU をモニタリングするには、コマンドを数回実行する必要があります。CPU 使用率が（一時的なスパイクではなく）一貫して 80% を超えているプロセスがあるかどうかをチェックします。sorted キーワードを付けてコマンドを実行することをお勧めします。これにより CPU 使用率の高いプロセスをすぐに特定できるからです。WNCD プロセスで一貫して CPU 使用率が高く、それが原因で AP の切断につながっているケースが確認されています。しかし、リリース 17.3.5 と 17.6.3 では、CPU 使用率が高い場合に AP CAPWAP 接続を保護する目的で、追加のハードニングが実施されています。コマンドとして「show processes cpu platform sorted | ex 0% 0% 0%」を使用します。
Gladius1#show processes cpu platform sorted | ex 0% 0% 0%
CPU utilization for five seconds: 14%, one minute: 16%, five minutes: 16%
Core 0: CPU utilization for five seconds: 10%, one minute: 7%, five minutes: 11%
Core 1: CPU utilization for five seconds: 6%, one minute: 28%, five minutes: 12%
Core 2: CPU utilization for five seconds: 48%, one minute: 55%, five minutes: 68%
Core 3: CPU utilization for five seconds: 20%, one minute: 8%, five minutes: 11%
Core 4: CPU utilization for five seconds: 38%, one minute: 13%, five minutes: 17%
Core 5: CPU utilization for five seconds: 14%, one minute: 11%, five minutes: 13%
Core 6: CPU utilization for five seconds: 9%, one minute: 20%, five minutes: 23%
Core 7: CPU utilization for five seconds: 5%, one minute: 8%, five minutes: 18%
Core 8: CPU utilization for five seconds: 7%, one minute: 50%, five minutes: 34%
Core 9: CPU utilization for five seconds: 100%, one minute: 58%, five minutes: 27%
Core 10: CPU utilization for five seconds: 27%, one minute: 17%, five minutes: 25%
Pid PPid 5Sec 1Min 5Min Status Size Name
--------------------------------------------------------------------------------
19056 19037 99% 99% 99% R 7525896 wncd_0
21922 21913 96% 97% 99% R 127488 smand
19460 19451 37% 34% 33% R 6363828 wncd_2
19604 19596 18% 19% 18% R 4556132 wncd_3
コアごと、プロセスごとの CPU 使用率をチェックする。プロセス wncd_0 と smand の CPU 使用率が 100% 近くになっている。
Catalyst 9800-CL および 9800-L プラットフォームは、データ転送に CPU コアを使用します。そのため、ucode_pkt_PPE0 の CPU 使用率が高くなることが予想されます。これらのプラットフォームでデータプレーンのパフォーマンスを評価するには、コマンドとして「show platform hardware chassis active qfp datapath utilization | i Load」を使用します。
Gladius1#show platform hardware chassis active qfp datapath utilization | i load
CPP 0: Subdev 0 5 secs 1 min 5 min 60 min
Processing: Load (pct) 4 3 4 3
Check datapath load %
メモリ使用量をチェックしながら、デバイス使用率が高すぎるかどうかをモニタリングする必要があります。次に、メモリを保持しているプロセスがメモリを解放しない状況（リーク）が発生しているかどうかを特定します。
コマンドとして「show platform resources」（ベーシック）、「show process memory platform sorted」、「show processes memory platform accounting」（アドバンスド）を使用します。
Gladius1#show platform resources
**State Acronym: H - Healthy, W - Warning, C - Critical
Resource Usage Max Warning Critical State
-----------------------------------------------------------------------------
RP0 (ok, active) H
Control Processor 0.79% 100% 80% 90% H
DRAM 4839MB(15%) 31670MB 88% 93% H
harddisk 0MB(0%) 0MB 80% 85% H
ESP0(ok, active) H
QFP H
TCAM 68cells(0%) 1048576cells 65% 85% H
DRAM 420162KB(20%) 2097152KB 85% 95% H
IRAM 13738KB(10%) 131072KB 85% 95% H
CPU Utilization 0.00% 100% 90% 95% H
メトリックの状態が正常であることを確認する。制御プロセッサとメモリ使用量を確認する。
Gladius1#show processes memory platform sorted
System memory: 15869340K total, 6152000K used, 9717340K free,
Lowest: 9717340K
Pid Text Data Stack Dynamic RSS Name
----------------------------------------------------------------------
3546 367768 1404580 136 488 1404580 linux_iosd-imag
23602 22335 449968 136 1052 449968 ucode_pkt_PPE0
24525 847 437624 136 46628 437624 wncd_0
24004 160 373176 3956 6400 373176 wncmgrd
26358 128 344868 136 136628 344868 mobilityd
使用可能な空きメモリを確認する。多くのメモリを保持しているプロセスを特定する。
Gladius1#show processes memory platform accounting
Hourly Stats
process callsite_ID(bytes) max_diff_bytes callsite_ID(calls) max_diff_calls tracekey timestamp(UTC)
---------------------------------------------------------------------------------------------------------------------------------------------
cpp_cp_svr_fp_0 2887897091 7243446 2887897092 1133 1#e4bd31e0c668be2b8786dec9fcc99486 2022-05-25 14:04
ndbmand_rp_0 3571094529 5453112 3570931712 1119 1#00c5632bf072231d06cf80b8ccc37392 2022-05-09 21:52
wncd_4_rp_0 2556049411 3059712 3028615169 227 1#9f4792f37292983824f5bb97d7e2167c 2022-05-10 14:54
wncd_0_rp_0 2556049411 1990656 3028615168 680 1#9f4792f37292983824f5bb97d7e2167c 2022-05-25 11:05
wncd_2_rp_0 2556049411 1953792 3028615169 682 1#9f4792f37292983824f5bb97d7e2167c 2022-05-13 14:01
smand_rp_0 2887895047 1491984 3028615168 89 1#eaf6dd665e73b1edeee32fb9c5ac8639 2022-05-10 14:54
メモリ使用量が上位のプロセスとコール数を確認する。統計は時間、日、週、月単位。
コントローラの最後の正常性チェックとして、ハードウェアの検証を行います。電源、ファン、SFP、温度のステータスをチェックします（物理 WLC の場合のみ）。また、ライセンスのステータスと適切な数のライセンスが使用されていることを確認します。コマンドとして「show platform」、「show inventory」、「show environment」、「show license summary | i Status」を使用します。
Gladius1#show platform
Chassis type: C9800-40-K9
Slot Type State Insert time (ago)
--------- ------------------- --------------------- -----------------
0 C9800-40-K9 ok 2w5d
0/0 BUILT-IN-4X10G/1G ok 2w5d
R0 C9800-40-K9 ok, active 2w5d
F0 C9800-40-K9 ok, active 2w5d
P0 C9800-AC-750W-R ok 2w5d
P1 Unknown empty never
P2 C9800-40-K9-FAN ok 2w5d
Slot CPLD Version Firmware Version
--------- ------------------- ---------------------------------------
0 19030712 16.10(2r)
R0 19030712 16.10(2r)
F0 19030712 16.10(2r)
Gladius1#show inventory
NAME: "Chassis 1", DESCR: "Cisco C9800-40-K9 Chassis"
PID: C9800-40-K9 , VID: V03 , SN: TTM242504SR
NAME: "Chassis 1 Power Supply Module 0", DESCR: "Cisco Catalyst 9800-40 750W AC Power Supply Reverse Air"
PID: C9800-AC-750W-R , VID: V01 , SN: ART2418F0GJ
NAME: "Chassis 1 Fan Tray", DESCR: "Cisco C9800-40-K9 Fan Tray"
PID: C9800-40-K9-FAN , VID: , SN:
NAME: "module 0", DESCR: "Cisco C9800-40-K9 Modular Interface Processor"
PID: C9800-40-K9 , VID: , SN:
NAME: "SPA subslot 0/0", DESCR: "4-port 10G/1G multirate Ethernet Port Adapter"
PID: BUILT-IN-4X10G/1G , VID: N/A , SN: JAE87654321
NAME: "subslot 0/0 transceiver 0", DESCR: "10GE LR"
PID: SFP-10G-LR , VID: V02 , SN: AVD2141KCFB
NAME: "module R0", DESCR: "Cisco C9800-40-K9 Route Processor"
PID: C9800-40-K9 , VID: V03 , SN: TTM242504SR
NAME: "module F0", DESCR: "Cisco C9800-40-K9 Embedded Services Processor"
PID: C9800-40-K9 , VID: , SN:
NAME: "Crypto Asic F0/0", DESCR: "Asic 0 of module F0"
PID: NOT , VID: V01 , SN: JAE242711XF
Gladius1#show environment
Number of Critical alarms: 0
Number of Major alarms: 0
Number of Minor alarms: 0
電源、ファンのステータス、SFP、SPA、アラームをチェックする。
Catalyst 9800 WLC の KPI は問題を特定するのに役立ちますが、その例として、2 つの WLC 間で発生した顧客向けの高可用性セットアップの問題を紹介します。両方の WLC のバージョンと、インストールされているハードウェアを確認することで、SPA アダプタに差異があることが判明し、それが原因で WLC が HA としてペアリングされないことがわかりました。
他のデバイスとの接続のチェック
WLC の正常性に加えて、WLC の接続のステータスも確認します。最も重要な接続は、WLC 間ローミング用の他の WLC とのモビリティ、モニタリングと自動化用の DNAC/PI を使用したテレメトリ、ロケーションサービス用の DNA-Spaces/CMX を使用した Nmsp です。これらの接続が確立され、正常に機能していることを確認する必要があります。
他の WLC とのモビリティトンネルが稼働しており、正しい暗号化と MTU を使用していることを確認します。また、クライアントが他の WLC にローミングまたはアンカーリングできることも確認します。トンネルがダウンしている場合、問題が制御トンネル（UDP ポート 16666）、データトンネル（UDP ポート 16667）、またはその両方で発生しているかどうかを確認します。コマンドとして「show wireless mobility sum」を使用します。
Gladius1#sh wireless mobility summary
Wireless Management VLAN: 25
Wireless Management IP Address: 192.168.25.25
Mobility Control Message DSCP Value: 48
Mobility Keepalive Interval/Count: 10/3
Mobility Group Name: eWLC3
Mobility Multicast Ipv4 address: 0.0.0.0
Mobility MAC Address: 001e.f62a.46ff
Mobility Domain Identifier: 0x2e47
Controllers configured in the Mobility Domain:
IP Public Ip MAC Address Group Name Multicast IPv4 Multicast IPv6 Status PMTU
-----------------------------------------------------------------------------
192.168.25.25 N/A 001e.f62a.46ff eWLC3 0.0.0.0 :: N/A N/A
192.168.5.35 192.168.5.35 00b0.e1f2.f480 3500-2 0.0.0.0 :: Up 1385
192.168.25.23 192.168.25.23 706d.1535.6b0b DAO2 0.0.0.0 :: Control And Data Path Down
192.168.25.33 192.168.25.33 f4bd.9e57.ff6b 5500 0.0.0.0 :: Up 1005
モビリティがダウンしていないか、PMTU が低くなっていないかどうかチェックする。
アシュアランスまたはプロビジョニング用の DNAC がある場合は、DNAC Netconf 接続が確立されていることを確認します。その後、WLC、AP、およびクライアントのテレメトリ統計が更新されていることを DNAC で確認します。コマンドとして「show telemetry internal connection」を使用します。17.7 より後のリリースでは、このコマンドは「show telemetry connection all」に置き換えられています。
Gladius2#show telemetry internal connection
Load for five secs: 29%/5%; one minute: 4%; five minutes: 2%
Time source is NTP, 10:21:45.942 CET Wed Nov 4 2020
Telemetry connections
Index Peer Address Port VRF Source Address State
----- -------------------------- ----- --- -------------------------- -------
1 192.168.0.105 25103 0 192.168.25.42 Active
テレメトリの状態をチェックする。
ロケーションに DNA Spaces を使用している場合は、まず、Nmsp の接続状態と送受信されたパケット数を確認します。次に、WLC プローブデータベース内のクライアントのリストを確認します。最後に、DNA Spaces でクライアントのロケーションが更新されたことを確認します。コマンドとして「show nmsp status」を使用します。
Gladius1#show nmsp status
NMSP Status
-----------
DNA Spaces/CMX IP Address Active Tx Echo Resp Rx Echo Req Tx Data Rx Data Transport
------------------------------------------------------------------------------------------------------
192.168.0.65 Active 693870 693870 16833737 181084 TLS
192.168.0.66 Inactive 21 21 222 7 TLS
非アクティブ状態のサーバー、エコー 送信/受信間の不一致がないかチェックする。
これらのチェックにより、9800 WLC の正常性と、CMX/DNA Spaces などの他のデバイス、他の WLC、DNAC との接続をプロアクティブにモニタリングできます。次のブログでは、AP と RF をモニタリングするための KPI を紹介します。
KPI および自動化スクリプトに使用するコマンドのリスト
以下のドキュメントには、すべてのコマンドを自動的に収集するスクリプトへのリンクも掲載されています。このスクリプトはプラットフォームとリリースに基づいてコマンドを収集し、ファイルに保存して、そのファイルをエクスポートします。このスクリプトは「ゲストシェル」機能を使用しており、現時点では物理 WLC 9800-40/80 および 9800-L でのみ使用できます。
このドキュメントでは、定期的にログを収集する EEM スクリプトの例も紹介しています。結論としては、EEM と「ゲストシェル」スクリプトを使用すると、9800 WLC の KPI を収集して Catalyst 9800 WLC の基準を作成できます。
これらの KPI をモニタリングするために使用するコマンドのリストについては、
「Wireless Catalyst 9800 の KPI のモニタリング
をご覧ください
Tags:
- Catalyst 9800
- Cisco Catalyst 9800
- KPI
- Wireless Catalyst 9800 WLC の KPI
- 「Wireless Catalyst 9800 WLC の KPI」シリーズ
