Catalyst 9800ワイヤレスLANコントローラのワイヤレスデバッグとログ収集について

はじめに

このドキュメントでは、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状態になるまで、クライアントから送信されるすべてのトラフィックがこれに該当します。

さまざまなデーモンが着信トラフィックを処理すると、結果として生じる、クライアントに送信される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のログレベルで継続的にロギングされます。これは、always-onトレースと呼ばれます。

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

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

常時接続のトレースでは、すでにキャプチャされたトレースを振り返って、それが一般的な根本原因であるかどうかを特定できます。  生成されるログの量に応じて、数時間から数日を振り返ることができます。

トレースは個々のプロセスごとにログに記録されますが、クライアントMAC、AP MAC、またはAP IPアドレスなどの特定のコンテキストについて総合的に表示できます。そのためには、次のコマンドを実行します

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

デフォルトでは、このコマンドはログの生成とデコードに10分しか時間がかかりません。以下を使用して、さらに時間を遡ることができます。

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

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

# show logging process  to-file bootflash:

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

# show logging profile wireless ?
# show logging process  ?

条件付きデバッグと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アドレスに関連するすべてのログを集計したログファイルを生成できます。

照合済みログファイルの取得時間を選択し、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_aaaaabbbbcccc_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

組み込みパケットキャプチャ(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では最大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]