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を宛先とする、および9800 WLCから発信されるネットワークモビリティサービスプロトコル(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

次の出力には、一般的なログと、一部のwireless-specification(WLC)のログが示されています。ただし、従来のCisco IOS®とは異なり、ワイヤレスデバッグは通常、このログ出力に到達しません。

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

常時トレース

WLC9800上のすべてのコントロールプレーンプロセスは、専用バッファに対して常に通知レベルのロギングを行います。これは、always-onトレースと呼ばれます。

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

たとえば、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  ?

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

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

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

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

注：16.12では、放射性トレースが実行されるのは、AP無線MACアドレスとイーサネットMACアドレスによるAP加入、クライアントMACアドレスによるクライアント加入、およびモビリティピアIPによるモビリティの問題とCMX IPアドレスによるCMX接続を関心のある条件としてトラブルシューティングする場合のみです。

注:MACアドレスとIPアドレスの条件は、異なるプロセスが同じネットワークエンティティ（AP、クライアント、またはモビリティピア）の異なる識別子を認識しているため、異なる出力を提供します。

トラブルシューティングの例としてクライアント接続を使用すると、クライアント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_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の累乗として定義されます。既定では、概要データとフィーチャデータの両方がキャプチャされます。オプションで、「要約のみ」サブオプションを使用する場合は、要約ビューのみを取得するように選択できます。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：停止すると、「エクスポート」ボタンをクリックできるようになります。このボタンをクリックすると、httpsまたはTFTPサーバ、FTPサーバ、ローカルシステムのハードディスクまたはフラッシュを介して、ローカルデスクトップにキャプチャファイル(.pcap)をダウンロードできます。

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

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

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

monitor capture uplink interface <uplink_of_the_9800> both

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

この例では、9800の2つのIPアドレスと別のWLC 5520の間のトラフィックを照合する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が赤色になった場合は、プラットフォームにクリティカルアラームがあることを意味します。

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

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]