内容

はじめに

前提条件

要件

使用するコンポーネント

背景説明

9800 WLC内のパケットフロー

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

Syslog

常時トレース

障害時のトレース

条件付きデバッグとRadioActiveトレース

Web UIによる放射性トレース

CLIによる放射性トレース

プロセス単位の非条件付きデバッグ

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

Embedded Packet Capture

アラームLEDと重要なプラットフォームアラーム

はじめに

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

前提条件

要件

- ワイヤレスLANコントローラ(WLC)に関する基礎知識。

- WLCの使用に関連するユースケースフローに関する基本的な知識。

使用するコンポーネント

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

背景説明

9800 WLC上で稼働するCisco IOS® XEは、基本的にCisco IOS®を搭載したLinuxカーネル(binOS)と、デーモンとして実装されたすべてのワイヤレスプロセスで構成されています。

すべてのプロセスデーモンは、一般的な用語であるコントロールプレーン(CP)にバンドルでき、アクセスポイントの制御とプロビジョニング(CAPWAP)、モビリティ、Radio Resource Management(RRM)を担当します。不正管理、9800 WLCを宛先とするNetwork Mobility Service(NMSP)プロトコル。

データプレーン(DP)とは、9800 WLCでデータを転送するコンポーネントを指します。

9800のすべてのイテレーション(9800-40、9800-80、9800-CL、9800-SW、9800-L)で、コントロールプレーンはかなり一般的なままです。

ただし、データプレーンは、ASR1kと同様のハードウェアQuantum Flow Processor(QFP)コンプレックスを使用する9800-40および9800-80によって異なり、9800-CLおよび9800-LではCisco Packet Processor(CPP)のソフトウェア実装が使用されます。

9800-SWは、Catalyst 9kシリーズスイッチのドップラーチップセットを使用してデータ転送を行います。

9800 WLC内のパケットフロー

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

APへの加入の場合、これはAPから送信されるすべてのcapwapとdtlsの交換です。クライアントが参加する場合、クライアントがRUN状態になるまでクライアントから発信されるすべてのトラフィックがPUNTパスに従います。

さまざまなデーモンが着信トラフィックを処理すると、結果としてクライアントに送信される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  ?

障害時のトレース

一般的に知られている障害状態のスナップショットを迅速に取得するために、障害発生時のトレース機能を使用できます。これにより、特定の時点におけるシステム上のすべてのトレースが解析され、事前定義された障害条件に一致し、要約ビューと統計情報が表示されます。

要約ビューを表示するには、次のコマンドを実行します

# show logging profile wireless trace-on-failure summary

定義済みの障害状態と、これらの状態に対応する統計情報を表示するには、次のコマンドを実行します

# show wireless stats trace-on-failure

障害が判明したら、障害のコンテキストに固有のトレースを収集するために、次のコマンドを実行します

# show logging profile wireless filter uuid  to-file bootflash:tof-FILENAME.txt

これらは、ターミナルセッションで表示したり、コマンドを使用してオフラインで分析するためにエクスポートしたりできます

# more bootflash:tof-FILENAME.txt

OR

# copy bootflash:tof-FILENAME.txt { tftp: | ftp: | scp: | https: } tof-FILENAME.txt

条件付きデバッグとRadioActiveトレース

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

RadioActiveトレースでは、さらに一歩進んで、対象の条件に対して、複数のプロセスやスレッドにわたってデバッグ情報を条件付きで出力する機能が追加されています。

つまり、基盤となるアーキテクチャが完全に抽象化されます。

注: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アドレスだけです。CLIを使用してIPアドレスを追加できます。

複数のMACアドレスを追加して追跡できます。放射性トレースを開始する準備ができたら、startをクリックします。

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

トラブルシューティングする問題を再現したら、Stopをクリックします。

デバッグしたMACアドレスごとに、Generateをクリックして、そのMACアドレスに関連するすべてのログを集計したログファイルを生成できます。

照合済みログファイルの取得時間を選択し、[デバイスに適用]をクリックします。

ファイル名の横にある小さいアイコンをクリックすると、ファイルをダウンロードできます。このファイルはコントローラのブートフラッシュドライブにあり、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のこの機能は、ASR!kでの実装とまったく同じように動作します。

9800 WLC上のPacket Tracerは、ASR1Kと同じ3レベルの検査を提供します。

- Statistics（統計）：ネットワーキングプロセッサに出入りするパケットの数を示します。

- 要約-

- これは、対象の特定の条件に一致する限られた数のパケットについて収集されます。

- サマリー出力は、入力インターフェイスと出力インターフェイス、データプレーンによるルックアップの決定を示し、パント、ドロップ、および挿入パケット（存在する場合）も追跡します。

- この出力は、データプレーン処理の簡潔なビューを提供します

- パスデータ：DPパケット処理の最も詳細なビューを提供します。限定された数のパケットについて収集され、DPパケットをコントロールプレーンデバッグ、タイムスタンプ、および機能固有のパストレースデータに関連付けるために使用できる条件付きデバッグIDが含まれます。この詳細ビューには2つのオプション機能があります

- パケットコピーを使用すると、パケットのさまざまなレイヤ（レイヤ2、レイヤ3、およびレイヤ4）で入出力パケットをコピーできます

- Feature Invocation Array(FIA)は、データプレーンによってパケット上で実行される機能のシーケンシャルリストです。これらの機能は、WLC 9800のデフォルト設定とユーザが有効にした設定から派生しています

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

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

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

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

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

警告：コマンド – debug platform condition機能と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を送信元および通過するパケットを表示できるパケットキャプチャ機能です。これらのキャプチャは、Wiresharkでオフライン分析するためにエクスポートできます。

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

AireOSと比較すると、9800 WLCでは、アップリンクスイッチのパケットキャプチャおよびトラフィックミラーリング機能に依存する代わりに、ボックス自体でpcapキャプチャが可能です。

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

GUIを使用して設定するには、Troubleshooting > Packet Capture > +Addの順に移動します。

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

ステップ 2：フィルタを定義する（存在する場合）

ステップ 3：トラフィックがシステムCPUにパントされ、データプレーンに再注入されるのを確認するには、Monitor Control Trafficのボックスにチェックマークを付けます

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

ステップ 5：必要に応じて、1 ～ 1000000秒の範囲を許可する期間または1 ～ 100000パケットの範囲を許可するパケット数によって制限を定義します

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

手順 7：保存してデバイスに適用

ステップ 8：キャプチャを開始するには、Startを選択します

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

ステップ 10：停止すると、Exportボタンが使用可能になり、httpsまたはTFTPサーバ、FTPサーバ、あるいはローカルシステムのハードディスクまたはフラッシュを介してローカルデスクトップにキャプチャファイル(.pcap)をダウンロードするオプションが表示されます。

注:CLIでは、Limit byなどのオプションの粒度がもう少し細かくなっています。GUIは、一般的な使用例でパケットをキャプチャするのに十分です。

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

モニタキャプチャを作成します。

monitor capture uplink interface <uplink_of_the_9800> both

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

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

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

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

たとえば、50MBバッファに設定した場合です。9800では最大50MBのディスクが必要で、問題の発生を期待して数分のデータをキャプチャするには非常に大きな容量が必要です。

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]