Catalyst 9800 ワイヤレス LAN コントローラのトラブルシューティング

はじめに

このドキュメントでは、Catalyst 9800 のトラブルシューティングに活用される Cisco IOS XE のすべての特徴と機能の概要について説明します。

前提条件

要　件

• ワイヤレス LAN コントローラ（WLC）に関する基本知識。
• WLC の使用に関連するユースケースのフローに関する基礎知識。

使用するコンポーネント

このドキュメントでは、9800-CL、9800-L、9800-40、および 9800-80 コントローラについて説明します。主に Cisco IOS® XE バージョン 17.3 に基づきます。

バックグラウンド情報

9800 WLC で実行される Cisco IOS® XE は、基本的に Linux カーネル（binOS）で構成されており、Cisco IOS® およびすべてのワイヤレスプロセスはデーモンとして実装されています。

すべてのプロセスデーモンは、一般的な用語でいうところのコントロールプレーン（CP）の下にバンドルすることができ、Control and Provisioning of Access Points（CAPWAP）、モビリティ、無線リソース管理（RRM）を担当します。 9800 WLC を宛先および送信元とする不正管理、ネットワーク モビリティ サービス プロトコル（NMSP）。

データプレーン（DP）とは、9800 WLC 上でデータを転送するコンポーネントのことです。

コントロールプレーンは、9800 のすべてのバージョン（9800-40、9800-80、9800-CL、および 9800-L）でほぼ共通です。

ただし、データプレーンは、ASR1k と同様のハードウェアである Cisco Quantum Flow Processor（QFP）コンプレックスを使用する 9800-40 および 9800-80 と、Cisco パケットプロセッサ（CPP）のソフトウェア実装を使用する 9800-CL および 9800-L では異なります。

9800-SW は、Catalyst 9k シリーズ スイッチの Doppler チップセットをデータ転送にそのまま活用します。

9800 WLC 内のパケットフロー

パケットが物理ポートから 9800 WLC に入ったときに、制御トラフィックであると判断された場合、対応するコントロール プレーン プロセスにパントされます。

AP 接続の場合、AP から送信されたすべての CAPWAPと DTLS 交換がこれにあたります。クライアント接続の場合、クライアントが実行状態になるまでにクライアントから送信されたすべてのトラフィックがこれにあたります。

さまざまなデーモンが着信トラフィックを処理すると、その結果、クライアントに送信するために 9800 WLC から送信されるリターントラフィック（CAPWAP 応答、dot11、dot1x、DCP 応答）がデータプレーンに差し戻されて、物理ポートに送信されます。

AP 接続、クライアント接続、モビリティ交換を処理する際、データトラフィックの転送を処理できるようにデータプレーンをプログラムする必要があります。

これは、画像に示すプログラミングパス上で複数のコンポーネントが順番にプログラムされている場合に発生します。

Cisco IOS® XE には、パケットが 9800 WLC に入った時点から、処理済みのトラフィックが出ていくまでをトレースする多目的なツールセットが用意されています。

次のセクションでは、これらのツールと、コマンド ライン インターフェイス（CLI）からこれらのツールを呼び出すために使用するコマンドについて説明します。

コントロール プレーン トレース

このセクションでは、9800 WLC 向けのパケットが DP からパントされた後、または物理インターフェイスに送信するために 9800 WLC から送信された応答パケットを DP に差し戻す前に、コントロール プレーン プロセスによって実行される処理を表示するために使用できるコマンドとツールについて説明します。

Syslog

9800 WLC によって生成されるログは、システム全般の正常性を確認する第一の手段となります。

CPU、メモリ、バッファなどのシステムリソースに対して事前定義されたしきい値の違反は、報告されてログに記録されます。

また、サブシステムによって生成されたエラーもログに書き込まれます。ログを表示するには、[トラブルシューティング（Troubleshooting）] > [Syslog] に移動します。

または、次の CLI コマンドを実行します。

# show logging

この出力には、一般的なログと、一部のワイヤレス固有のログが表示されます。ただし、レガシー Cisco IOS® とは異なり、通常、ワイヤレスデバッグがこのログ出力まで進むことはありません。

注：WLC9800 がこれらのログを外部 syslog サーバーにリダイレクトするように設定されている場合は、外部 syslog サーバー上のログも確認する必要があります。

常時トレース

WLC9800 のすべてのコントロール プレーン プロセスは、[通知（Notice）] ログレベルで常に専用バッファに記録されています。これを常時トレースと呼びます。

これは、障害状態の再現を必須とすることなく、発生した障害のコンテキストデータを取得できる独自の機能です。

たとえば、AireOS に精通している場合、クライアント接続のトラブルシューティングを行うには、デバッグを有効にし、クライアント接続の問題の状態を再現して根本原因を特定する必要があります。

常時トレースにより、すでにキャプチャされたトレースにさかのぼって、それが共通の根本原因であるかどうかを特定できます。  生成されるログの量に応じて、数時間から数日までさかのぼることができます。

これで、トレースは個々のプロセスごとにログに記録される一方、クライアント MAC または AP MAC または AP IP アドレスなどの特定のコンテキストについて、それらの全体像を確認することができるようになりました。これを行うには、次のコマンドを実行します。

# show logging profile wireless filter mac  to-file bootflash:

デフォルトでは、このコマンドは 10 分間だけさかのぼってログを生成し、デコードします。次のコマンドにより、さらに過去にさかのぼることができます。

# show logging profile wireless start last  [minutes|hours|days] filter mac  to-file bootflash:

プロセスごとのログを表示するには、次のコマンドを実行します。

# show logging process  to-file bootflash:

注：これらの CLI には、モジュール、ロギングレベル、開始タイムスタンプなど、複数のフィルタリングオプションがあります。これらのオプションを表示したり調べたりするには、次のコマンドを実行します。

# show logging profile wireless ?
# show logging process  ?

条件付きデバッグとラジオアクティブトレース

条件付きデバッグを使用すると、対象条件の特定の機能に対してデバッグレベルのロギングを有効にすることができます。

ラジオアクティブトレースはさらに一歩進んだ機能を提供し、対象条件のプロセスとスレッドにわたるデバッグ情報を条件付きで出力することができます。

これは、基盤アーキテクチャが完全に抽象化されていることを意味します。

注：16.12 では、ラジオアクティブトレースは、AP 無線とイーサネット MAC アドレスを使用した AP 接続、クライアント MAC アドレスを使用したクライアント接続、さらにモビリティピア IP に関するモビリティの問題、および CMX IP アドレスを対象条件とする CMX 接続のトラブルシューティング用にのみ実装されます。

注：条件として MAC アドレスを使用する場合と IP アドレスを使用する場合では、異なる出力が提供されます。これは、同一のネットワークエンティティ（AP またはクライアントまたはモビリティピア）が、プロセスに応じて異なる ID として認識されるためです。

クライアント接続では、トラブルシューティングの例として、クライアント MAC の条件付きデバッグを実行して、コントロールプレーンでのエンドツーエンドのビューを取得します。

Web UI を介したラジオアクティブトレース

[トラブルシューティング（Troubleshooting）] ページのメニューに移動し、[ラジオアクティブトレース（Radioactive Tracing）] を選択します。

[追加（Add）] をクリックして、トラブルシューティングするクライアントまたは AP の MAC アドレスを入力します。  16.12 では、GUI を使用して追加できるのは MAC アドレスのみです。IP アドレスは CLI を使用して追加できます。

追跡する MAC アドレスは複数追加できます。ラジオアクティブトレースを開始する準備ができたら、[開始（Start）] をクリックします。

開始すると、追跡対象の MAC アドレスに関連するコントロールプレーン処理に関するデバッグログが、ディスクに書き込まれます。

トラブルシューティングを行う問題が再現されたら、[停止（Stop）] をクリックします。

デバッグされた MAC アドレスごとに、[生成（Generate）] をクリックして、その MAC アドレスに関するすべてのログの照合を行うログファイルを生成できます。

照合されたログファイルを過去にさかのぼる期間を選択し、[デバイスに適用（Apply to Device）] をクリックします。

ファイル名の横にある小さなアイコンをクリックして、ファイルをダウンロードできるようになります。このファイルはコントローラのブートフラッシュドライブに存在し、CLI を使用してコピーすることもできます。

CLI を介したラジオアクティブトレース

条件付きデバッグを有効にするには、次のコマンドを実行します。

# debug wireless {mac | ip} {aaaa.bbbb.cccc | x.x.x.x } {monitor-time} {N seconds}

現在有効になっている条件を表示するには、次のコマンドを実行します。

# show debugging

これらのデバッグは端末セッションでは出力されませんが、後で取得および分析できるようにデバッグ出力ファイルがフラッシュに保存されます。このファイルは、命名規則 ra_trace_ * を使用して保存されます。

たとえば、MAC アドレスが aaaa.bbbb.cccc の場合、生成されるファイル名は ra_trace_MAC_aaaabbbbcccc_HHMMSS.XXX_timezone_DayWeek_Month_Day_year.log になります。

メリットの 1 つは、同じコマンドを使用して AP 接続の問題（AP 無線 MAC とイーサネット MAC を入力）、クライアント接続の問題（クライアント MAC を入力）、モビリティトンネルの問題（ピア IP を入力）、クライアントローミングの問題（クライアント MAC を入力）をトラブルシューティングできることです。

つまり、debug capwap、debug client、debug mobility などの複数のコマンドを覚える必要がありません。

注：debug wireless コマンドでは、FTP サーバーをポイントし、キーワード internal を使用してさらに詳細なロギングを実行することもできます。いくつかの問題の解決に取り組んでいるため、現時点ではこれは推奨されません。

端末セッションで出力ファイルをデバッグするには、次のコマンドを実行します。

# more bootflash:ra_trace_MAC_*.log 

オフライン分析のためにデバッグ出力を外部サーバーにリダイレクトするには、次のコマンドを実行します。

# copy bootflash:ra_trace_MAC_*.log ftp://username:password@FTPSERVERIP/path/RATRACE_FILENAME.txt

同じデバッグログレベルのより詳細なビューがあります。この詳細ビューを表示するには、次のコマンドを使用します。

# show logging profile wireless internal filter mac  to-file 

特定のコンテキストのデバッグを無効にしたり、設定済みまたはデフォルトのモニター時間が経過する前にデバッグを無効にするには、次のコマンドを実行します。

# no debug wireless mac <aaaa.bbbb.cccc>

注意：条件付きデバッグでは、デバッグレベルのロギングが有効になります。これにより、生成されるログの量が増加します。この機能を実行したままにすると、さかのぼってログを表示できる期間が短くなります。したがって、トラブルシューティング セッションの終了時には、常にデバッグを無効にすることを推奨します。

 すべてのデバッグを無効にするには、次のコマンドを実行します。

# clear platform condition all
# undebug all

プロセスごとの無条件デバッグ

ラジオアクティブトレース用に実装されていないユースケースとプロセスについては、デバッグレベルのトレースを取得できます。特定のプロセスにデバッグレベルを設定するには、次のコマンドを使用します。

# set platform software trace <PROCESS_NAME> wireless chassis active R0 { module_name | all-modules } 

さまざまなモジュールのトレースレベルを確認するには、次のコマンドを実行します。

# show platform software trace level <PROCESS_NAME> chassis active R0

収集されたトレースを表示するには、次のコマンドを実行します。

# show logging process  to-file 

データ プレーン パケット トレース

パケットが最初に 9800 WLC に入ると、データプレーンでいくつかの処理が発生して、トラフィックがコントロールプレーンかデータプレーンかを識別します。

パケットトレース機能は、データプレーンで実行されるこの Cisco IOS® XE の処理の詳細ビューを提供し、パケットをパント、転送、ドロップ、または消費するかを判断します。

WLC 9800 のこの機能は、ASR1k での実装とまったく同じように動作します。

9800 WLC のパケットトレーサは、ASR1K と同じく次の 3 つのレベルの検査を提供します。

• [統計（Statistics）]：ネットワークプロセッサに出入りするパケット数が示されます。
• 要約-
  • 特定の対象条件に一致する有限数のパケットについて収集されます。
  • サマリー出力には、入力インターフェイスと出力インターフェイス、データプレーンによって行われたルックアップの判断が示され、パケットのパント、ドロップ、インジェクション（あれば）も追跡されます。
  • この出力は、データプレーン処理の簡潔なビューを提供します。
• [パスデータ（Path Data）]：DP パケット処理の最も詳細なビューを提供します。有限数のパケットについて収集され、DP パケットをコントロールプレーンのデバッグ、タイムスタンプ、および機能固有のパストレースデータに関連付けるために使用できる条件付きデバッグ ID が含まれます。この詳細ビューには 2 つのオプション機能があります。
  • パケットコピーを使用すると、パケットの各種レイヤ（レイヤ 2、レイヤ 3、レイヤ 4）で入力パケットや出力パケットをコピーできます。
  • Feature Invocation Array（FIA）は、データプレーンによってパケットに対して実行される機能の順序付きリストです。これらの機能は、WLC 9800 のデフォルト設定およびユーザーが有効にした設定から派生したものです。

機能とサブオプションの詳しい説明については、『Cisco IOS XE データパス パケット トレース機能』を参照してください。

AP 接続、クライアント接続などのワイヤレスワークフロー用で、アップリンクを双方向でトレースします。

注意：データプレーン パケット トレーサは CAPWAP の外部ヘッダーのみを解析します。したがって、wireless client mac のような条件では有用な出力が得られません。

 ステップ 1：対象の条件を定義します。

# debug platform condition { interface | mac | ingress | egress | both | ipv4 | ipv6 | mpls | match }

警告：debug platform condition feature と debug platform condition mac aaaa.bbbb.cccc のコマンドはどちらも、コントロール プレーン パケット トレース用であり、データプレーン パケット トレースを返しません。

ステップ 2現在有効になっている条件を表示するには、次のコマンドを実行します。

# show platform conditions

ステップ 3有限数のパケットに対してパケットトレーサを有効にします。このパケット番号は、16 ～ 8192 の範囲の 2 の累乗として定義されます。デフォルトでは、サマリーデータと機能データの両方がキャプチャされます。必要に応じて、summary-only サブオプションを使用すると、サマリービューのみを取得できます。また、FIA トレースを取得したり、パケットサイズをバイト単位で定義したり、パケットのパント、インジェクション、またはドロップをトレースしたりするために使用できるサブオプションもあります。

# debug platform packet-tracer packet <packet-number> {fia-trace}

ステップ 4： （任意）トレースされたパケットをコピーおよびダンプできます。

# debug platform packet-trace copy packet both size 2048 { l2 | l3 | l4 }

ステップ 5条件付きデバッグを有効にします。

# debug platform condition start

ステップ 6パケットトレースが出力を収集しているかどうかを確認するには、統計情報を確認します。

# show platform packet-trace statistics

ステップ 7パケットトレースの出力を表示するには、次のコマンドを実行します。

# show platform packet-tracer summary

 ステップ 8： （任意）Cisco TAC によるオフライン分析のためにパケットダンプをエクスポートできます。

# show platform packet-trace packet all | redirect { bootflash: | tftp: | ftp: } pactrac.txt

Embedded Packet Capture

Embedded Packet Capture（EPC）は、Catalyst 9800 WLC で送受信されるパケットや、Catalyst 9800 WLC を通過するパケットを確認するためのパケットキャプチャ機能です。これらのキャプチャは、Wireshark によるオフライン分析のためにエクスポートできます。

この機能の詳細については、『EPC 設定ガイド』を参照してください。

AireOS がアップリンクスイッチのパケットキャプチャおよびトラフィックミラーリング機能に依存するのに対し、Catalyst 9800 WLC では、ボックス自体で pcap キャプチャを実行できます。

9800 では、このキャプチャをコマンドライン インターフェイス（CLI）とグラフィカル ユーザー インターフェイス（GUI）の両方から設定できます。

GUI から設定するには、[トラブルシューティング（Troubleshooting）] > [パケットキャプチャ（Packet Capture）] > [+追加（+Add）] に移動します。

ステップ 1：パケットキャプチャの名前を定義します。最大 8 文字を使用できます。

ステップ 2必要な場合はフィルタを定義します。

ステップ 3システム CPU にパントされ、データプレーンに戻されたトラフィックを確認する場合は、[コントロールトラフィックのモニター（Monitor Control Traffic）] チェックボックスをオンにします。

ステップ 4バッファサイズを定義します。最大 100 MB を指定できます。

ステップ 5必要に応じて、期間（1 ～ 100 万秒の範囲）またはパケット数（1 ～ 10 万パケットの範囲）のいずれかを使用して、上限を定義します。

ステップ 6左側の列のインターフェイスのリストからインターフェイスを選択し、矢印を選択して右の列に移動します。

ステップ 7[保存してデバイスに適用（Save and Apply to Device）]

ステップ 8キャプチャを開始するには、[開始（Start）] をクリックします。

ステップ 9定義した制限までキャプチャを実行できます。キャプチャを手動で停止するには、[停止（Stop）] を選択します。

ステップ 10停止すると、[エクスポート（Export）] ボタンが使用可能になり、キャプチャファイル（.pcap）を HTTPS、TFTP サーバー、FTP サーバーを介してローカル デスクトップに、またはローカルシステムのハードディスクかフラッシュにダウンロードするオプションをクリックできます。

注：CLI では、「Limit by」など、よりきめ細かいオプションを利用できます。一般的な使用例でのパケットキャプチャには、GUI で十分です。

CLI を使用して設定するには、次の手順を実行します。

monitor capture を作成します。

monitor capture uplink interface <uplink_of_the_9800> both

フィルタを関連付けます。フィルタをインラインで指定することも、ACL またはクラスマップを参照することもできます。

この例では、ACL が 9800 と別の WLC 5520 の 2 つの IP アドレス間のトラフィックを照合します。モビリティのトラブルシューティングの一般的なシナリオは次のとおりです。

conf t

ip access-list extended mobilitywlcs
permit ip host <5520_ip_address> host <9800_ip_address>
     permit ip host <9800_ip_address> host <5520_ip_address>
end

monitor capture uplink access-list mobilitywlcs

キャプチャを循環バッファで実行する場合、問題に気付いてからキャプチャを停止し、保存するまで少し時間がかかります。

たとえば、50 MB バッファに設定したとします。9800 のディスクのうち最大 50 MB が使用されます。問題の発生を予測して数分間のデータをキャプチャするにはかなり大きな容量です。

monitor capture uplink buffer circular size 50

キャプチャの開始.これは、GUI または CLI から実行できます。

monitor capture uplink start

これでキャプチャがアクティブになりました。

必要なデータの収集を許可します。

キャプチャを停止します。これは、GUI または CLI から実行できます。

monitor capture uplink stop

キャプチャは、GUI > [トラブルシューティング（Troubleshooting）] > [パケットキャプチャ（Packet Capture）] > [エクスポート（Export）] から取得できます。

または、CLI からサーバーにアップロードします。FTP 経由の例：

monitor capture uplink export ftp://x.x.x.x/MobilityCAP.pcap

必要なデータが収集されたら、キャプチャを削除します。

no monitor capture uplink

アラーム LED およびクリティカルなプラットフォームのアラーム

すべての 9800 アプライアンス（9800-L、9800-40 および 9800-80）には、前面パネルに ALM LED があります。LED が赤色に点灯した場合は、プラットフォームにクリティカルなアラームが発生していることを意味します。

show facility-alarm status コマンドを使用すると、LED が赤色に点灯する原因となるアラームを確認できます。

WLC#show facility-alarm status
System Totals  Critical: 2  Major: 0  Minor: 0

Source                     Time                   Severity      Description [Index]
------                     ------                 --------      -------------------
TenGigabitEthernet0/1/0    Jul 26 2019 15:14:04   CRITICAL      Physical Port Link Down [1]
TenGigabitEthernet0/1/1    Jul 26 2019 15:14:04   CRITICAL      Physical Port Link Down [1]

更新履歴

改定	発行日	コメント
7.0	24-Apr-2026	同時にトレースできるMACアドレスの最大数に関する注記を追加
6.0	20-Aug-2024	Cisco.comスタイルガイドに適合するようにタイトルサイズを縮小
5.0	29-Mar-2024	廃止によりtrace-on-failureセクションを削除
4.0	12-Jul-2023	再認定
3.0	22-Jun-2022	trace-on-failureに変更します。「最後のxを開始」オプションを追加してロギングプロファイルを表示
2.0	20-Feb-2022	スペリングの軽度の変更とタイトルの変更
1.0	04-Oct-2021	初版