Catalyst 9800 WLCでのAP加入プロセスについて

概要

このドキュメントでは、Cisco Catalyst 9800 WLCを使用したAP加入プロセスについて詳しく説明します。

前提条件

要件

次の項目に関する知識があることが推奨されます。

• Control and Provisioning Wireless Access Points(CAPWAP)の基本的な知識
• ワイヤレスLANコントローラ(WLC)の使用に関する基本的な知識

使用するコンポーネント

このドキュメントの情報は、次のソフトウェアとハードウェアのバージョンに基づいています。

• Catalyst 9800-L WLC、Cisco IOS® XE Cupertino 17.9.3
• Catalyst 9120AXEアクセスポイント

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。本稼働中のネットワークでは、各コマンドによって起こる可能性がある影響を十分確認してください。

背景説明

CAPWAPセッションの確立

Control And Provisioning Wireless Access Point(CAPWAP)は、アクセスポイント(AP)およびワイヤレスLANコントローラ(WLC)で使用される転送メカニズムを提供するプロトコルで、セキュアな通信トンネル（CAPWAPコントロール用）を介してコントロールおよびデータプレーン情報を交換します。

AP加入プロセスを詳しく説明するには、Control And Provisioning Wireless Access Point(CAPWAP)セッションの確立プロセスを理解することが重要です。

CAPWAPプロセスを開始するには、APにIPアドレスが必要であることに注意してください。APにIPアドレスがない場合、APはCAPWAPセッション確立プロセスを開始しません。

1. アクセスポイントがディスカバリ要求を送信します。詳細については、「WLCの検出方法」セクションを参照してください
2. WLCがディスカバリ応答を送信する
3. DTLSセッションの確立。この後、この後のすべてのメッセージは暗号化され、パケット分析ツールでDTLSアプリケーションデータパケットとして表示されます。
4. アクセスポイントが参加要求を送信する
5. WLCが参加応答を送信する
6. APはイメージチェックを実行します。WLCと同じイメージのバージョンがある場合は、次の手順に進みます。存在しない場合は、WLCからイメージをダウンロードし、リブートして新しいイメージをロードします。この場合は、ステップ1からのプロセスを繰り返します。
7. アクセスポイントが設定ステータス要求を送信します。
8. WLCが設定ステータス応答を送信する
9. アクセスポイントがRUN状態になる
10. RUN状態の間、CAPWAPトンネルメンテナンスは次の2つの方法で実行されます。
    1. キープアライブは、CAPWAPデータトンネルを維持するために交換されます
    2. APはエコー要求をWLCに送信します。この要求には、対応するエコー応答で応答する必要があります。これは、CAPWAP制御トンネルを維持するためです。

CAPWAPセッションの確立プロセス

DTLSセッションの確立

アクセスポイントがWLCから有効なディスカバリ応答を受信すると、その間にDTLSトンネルが確立され、以降のすべてのパケットが安全なトンネルを介して送信されます。次に、DTLSセッションを確立するプロセスを示します。

1. APがClient Helloメッセージを送信する
2. WLCは、検証に使用されるcookieを含むHelloVerifyRequestメッセージを送信します。
3. APは検証に使用されるCookieを含むClientHelloメッセージを送信します。
4. WLCは次のパケットを順に送信します。
   1. サーバHello
   2. 証明書
   3. サーバキー交換
   4. 証明書要求
   5. ServerHelloDone
5. APは次のパケットを順に送信します。
   1. 証明書
   2. ClientKeyExchange
   3. 証明書の確認
   4. ChangeCipherSpec
6. WLCはAPのChangeCipherSpecに対し、独自のChangedCipherSpecで応答します。
   1. ChangeCipherSpec

WLCによって最後にChangedCipherSpecメッセージが送信された後、セキュアトンネルが確立され、両方向で送信されるすべてのトラフィックが暗号化されます。

ワイヤレスLANコントローラの検出方法

アクセスポイントにネットワーク内の1つのWLCの存在を知らせる方法はいくつかあります。

• DHCPオプション43:このオプションは、加入するWLCのIPv4アドレスをAPに提供します。このプロセスは、APとWLCが異なるサイトにある大規模な展開に便利です。
• DHCPオプション52:このオプションは、加入するWLCのIPv6アドレスをAPに提供します。DHCPオプション43と同じシナリオで使用すると便利です。
• DNSディスカバリ:APはドメイン名CISCO-CAPWAP-CONTROLLER.localdomainを照会します。参加するWLCのIPv4またはIPv6アドレスを解決するようにDNSサーバを設定する必要があります。このオプションは、WLCがAPと同じサイトに保存されている導入に便利です。
• レイヤ3ブロードキャスト:APは255.255.255.255にブロードキャストメッセージを自動的に送信します。APと同じサブネット内のすべてのWLCが、このディスカバリ要求に応答することが想定されています。
• 静的設定：次のコマンドを使用できます capwap ap primary-base <wlc-hostname> <wlc-IP-address>コマンドを使用して、APでWLCのスタティックエントリを設定します。
• モビリティディスカバリ:APが以前にモビリティグループの一部であったWLCに加入していた場合、APはそのモビリティグループに存在するWLCのレコードも保存します。

ワイヤレスLANコントローラの選択

いずれかのWLCディスカバリ方式を使用して、任意のWLCからAPがディスカバリ応答を受信すると、APは次の条件で加入するコントローラを1つ選択します。

1. プライマリコントローラ(capwap ap primary-base <wlc-hostname> <wlc-IP-address>コマンドで設定)
2. セカンダリコントローラ(capwap ap secondary-base <wlc-hostname> <wlc-IP-address>コマンドで設定) 
3. ターシャリコントローラ(capwap ap tertiary-base <wlc-hostname> <wlc-IP-address>コマンドで設定)
4. プライマリ、セカンダリ、またはターシャリWLCが事前に設定されていない場合、APは、使用可能なAP(つまり、任意の時点で最も多くのAPをサポートできるWLC)の最大容量を持つ独自のDiscovery Responseを使用して、ディスカバリ要求に応答した最初のWLCへの加入を試みます。

CAPWAPステートマシン

APコンソールでは、CAPWAPステートマシンを追跡できます。この追跡は、「CAPWAPセッションの確立」セクションで説明する手順を実行します。

CAPWAPの状態：検出

ここでは、ディスカバリ要求とディスカバリ応答を確認できます。APがDHCP（オプション43）経由でWLC IPを受信し、さらに既知のWLCにディスカバリ要求を送信する方法を確認します。

[*09/14/2023 04:12:09.7740] CAPWAP State: Init
[*09/14/2023 04:12:09.7770] 
[*09/14/2023 04:12:09.7770] CAPWAP State: Discovery
[*09/14/2023 04:12:09.7790] Discovery Request sent to 172.16.0.20, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7800] Discovery Request sent to 172.16.5.11, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7800] Got WLC address 172.16.5.11 from DHCP.
[*09/14/2023 04:12:09.7820] Discovery Request sent to 172.16.0.20, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7830] Discovery Request sent to 172.16.5.11, discovery type STATIC_CONFIG(1)
[*09/14/2023 04:12:09.7840] Discovery Request sent to 255.255.255.255, discovery type UNKNOWN(0)
[*09/14/2023 04:12:09.7850] 
[*09/14/2023 04:12:09.7850] CAPWAP State: Discovery
[*09/14/2023 04:12:09.7850] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8030] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.11
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.0.20
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.169
[*09/14/2023 04:12:09.8060] Discovery Response from 172.16.5.169

このAPは、スタティックに設定されたWLC(172.16.0.20)とDHCPオプション43(172.16.5.11)で指定されたWLCの両方からディスカバリ応答を受信するだけでなく、ブロードキャストディスカバリメッセージを取得したため、同じサブネット内の別のWLC(172.16.5.169)からもディスカバリ応答をを受信しました。

CAPWAPの状態：DTLSのセットアップ。

ここでは、APとWLCの間のDTLSセッションが交換されます。

[*09/27/2023 21:50:41.0000] CAPWAP State: DTLS Setup
[*09/27/2023 21:50:41.7140] sudi99_request_check_and_load: Use HARSA SUDI certificat

CAPWAPの状態：参加

DTLSセッションを確立した後、WLCへの参加要求がセキュアセッション経由で送信されます。この要求がWLCからの加入応答で即時に応答される方法を確認します

[*09/27/2023 21:50:41.9880] CAPWAP State: Join
[*09/27/2023 21:50:41.9910] Sending Join request to 172.16.5.11 through port 5270
[*09/27/2023 21:50:41.9950] Join Response from 172.16.5.11 
[*09/27/2023 21:50:41.9950] AC accepted join request with result code: 0
[*09/27/2023 21:50:41.9990] Received wlcType 0, timer 30
[*09/27/2023 21:50:41.9990] TLV ID 2216 not found
[*09/27/2023 21:50:41.9990] TLV-DEC-ERR-1: No proc for 2216

CAPWAPの状態：イメージデータ

APは自身のイメージをWLCのイメージと比較します。この場合、APのアクティブパーティションとバックアップパーティションの両方ともWLCとは異なるイメージを持つため、upgrade.shスクリプトを呼び出します。このスクリプトは、WLCに適切なイメージを要求し、それを現在の非アクティブパーティションにダウンロードするようにAPに指示します。

[*09/27/2023 21:50:42.0430] CAPWAP State: Image Data
[*09/27/2023 21:50:42.0430] AP image version 8.10.185.0 backup 8.10.105.0, Controller 17.9.3.50
[*09/27/2023 21:50:42.0430] Version does not match.
[*09/27/2023 21:50:42.0680] upgrade.sh: Script called with args:[PRECHECK]
[*09/27/2023 21:50:42.1060] do PRECHECK, part2 is active part
[*09/27/2023 21:50:42.1240] upgrade.sh: /tmp space: OK available 101476, required 40000 
[*09/27/2023 21:50:42.1250] wtpImgFileReadRequest: request ap1g7, local /tmp/part.tar
[*09/27/2023 21:50:42.1310] Image Data Request sent to 172.16.5.11, fileName [ap1g7], slaveStatus 0
[*09/27/2023 21:50:42.1340] Image Data Response from 172.16.5.11
[*09/27/2023 21:50:42.1340] AC accepted join request with result code: 0
[*09/27/2023 21:50:42.1450] <..................................................
[*09/27/2023 21:50:55.4980] ..................................................
[*09/27/2023 21:51:11.6290] ...............................Discarding msg CAPWAP_WTP_EVENT_REQUEST(type 9) in CAPWAP state: Image Data(10).
[*09/27/2023 21:51:19.7220] ...................
[*09/27/2023 21:51:24.6880] ..................................................
[*09/27/2023 21:51:37.7790] ..................................................
[*09/27/2023 21:51:50.9440] ...................................> 76738560 bytes, 57055 msgs, 930 last
[*09/27/2023 21:51:59.9160] Last block stored, IsPre 0, WriteTaskId 0
[*09/27/2023 21:51:59.9160] Image transfer completed from WLC, last 1

イメージ転送が完了すると、APはイメージ署名検証プロセスを開始して検証します。その後、upgrade.shスクリプトによってイメージが現在の非アクティブパーティションにインストールされ、ブート元のパーティションがスワップされます。最後に、APは自分自身をリロードし、プロセスを最初から繰り返します(CAPWAP State: Discover)。

[*09/27/2023 21:52:01.1280] Image signing verify success.
[*09/27/2023 21:52:01.1440] 
[*09/27/2023 21:52:01.1440] [9/27/2023 21:53:2] : Shadow is now in-synced with master
[*09/27/2023 21:52:01.1440] 
[*09/27/2023 21:52:01.1440] [9/27/2023 21:53:2] : Verifying against bundle image btldr.img...
[*09/27/2023 21:52:01.1570] upgrade.sh: part to upgrade is part1
[*09/27/2023 21:52:01.1780] upgrade.sh: AP version1: part1 8.10.105.0, img 17.9.3.50
[*09/27/2023 21:52:01.1960] upgrade.sh: Extracting and verifying image in part1...
[*09/27/2023 21:52:01.2080] upgrade.sh: BOARD generic case execute
[*09/27/2023 21:52:01.5280] upgrade.sh: Untar /tmp/part.tar to /bootpart/part1...
[*09/27/2023 21:52:01.7890] upgrade.sh: Sync image to disk...
[*09/27/2023 21:52:31.4970] upgrade.sh: status 'Successfully verified image in part1.'
[*09/27/2023 21:52:32.5270] upgrade.sh: AP version2: part1 17.9.3.50, img 17.9.3.50
[*09/27/2023 21:52:32.5540] upgrade.sh: AP backup version: 17.9.3.50
[*09/27/2023 21:52:32.5700] upgrade.sh: Finished upgrade task.
[*09/27/2023 21:52:32.5840] upgrade.sh: Cleanup for do_upgrade...
[*09/27/2023 21:52:32.5970] upgrade.sh: /tmp/upgrade_in_progress cleaned
[*09/27/2023 21:52:32.6090] upgrade.sh: Cleanup tmp files ...
[*09/27/2023 21:52:32.6720] upgrade.sh: Script called with args:[ACTIVATE]
[*09/27/2023 21:52:32.7100] do ACTIVATE, part2 is active part
[*09/27/2023 21:52:32.7640] upgrade.sh: Verifying image signature in part1
[*09/27/2023 21:52:33.7730] upgrade.sh: status 'Successfully verified image in part1.'
[*09/27/2023 21:52:33.7850] upgrade.sh: activate part1, set BOOT to part1
[*09/27/2023 21:52:34.2940] upgrade.sh: AP primary version after reload: 17.9.3.50
[*09/27/2023 21:52:34.3070] upgrade.sh: AP backup version after reload: 8.10.185.0
[*09/27/2023 21:52:34.3190] upgrade.sh: Create after-upgrade.log
[*09/27/2023 21:52:37.3520] AP Rebooting: Reset Reason - Image Upgrade

APがリロードしてCAPWAP DiscoverおよびJoin状態に戻ると、Image Data状態のときに適切なイメージであることが検出されます。

[*09/27/2023 21:56:13.7640] CAPWAP State: Image Data
[*09/27/2023 21:56:13.7650] AP image version 17.9.3.50 backup 8.10.185.0, Controller 17.9.3.50
[*09/27/2023 21:56:13.7650] Version is the same, do not need update.
[*09/27/2023 21:56:13.7650] status 'upgrade.sh: Script called with args:[NO_UPGRADE]'
[*09/27/2023 21:56:13.7850] do NO_UPGRADE, part1 is active part

CAPWAPの状態：設定

APは、自身のバージョンがWLCと同じであることを確認した後、自身の現在の設定をWLCに通知します。一般に、これはAPが設定を維持するように要求することを意味します（設定がWLCで使用可能な場合）。

[*09/27/2023 21:56:14.8680] CAPWAP State: Configure
[*09/27/2023 21:56:15.8890] Telnet is not supported by AP, should not encode this payload
[*09/27/2023 21:56:15.8890] Radio [1] Administrative state DISABLED change to ENABLED 
[*09/27/2023 21:56:16.0650] Radio [0] Administrative state DISABLED change to ENABLED 
[*09/27/2023 21:56:16.0750] DOT11_CFG[1]: Starting radio 1
[*09/27/2023 21:56:16.1150] DOT11_DRV[1]: Start Radio1
[*09/27/2023 21:56:16.1160] DOT11_DRV[1]: set_channel Channel set to 36/20
[*09/27/2023 21:56:16.4380] Started Radio 1
[*09/27/2023 21:56:16.4880] DOT11_CFG[0]: Starting radio 0
[*09/27/2023 21:56:17.5220] DOT11_DRV[0]: Start Radio0
[*09/27/2023 21:56:16.5650] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:16.5650] Started Radio 0
[*09/27/2023 21:56:16.5890] sensord psage_base init: RHB Sage base ptr a1030000

CAPWAP状態：Run

この時点で、APはコントローラに正常に加入しています。この状態では、WLCはAPによって要求された設定を上書きするメカニズムをトリガーします。WLCはこのAPについてこれまで認識していなかったため、APに無線とクレデンシャルの設定がプッシュされ、APがデフォルトポリシータグに割り当てられることがわかります。

[*09/27/2023 21:56:17.4870] CAPWAP State: Run
[*09/27/2023 21:56:17.4870] AP has joined controller uwu-9800
[*09/27/2023 21:56:17.4940] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:17.5440] sensord split_glue psage_base: RHB Sage base ptr a1030000
[*09/27/2023 21:56:17.6010] sensord split_glue sage_addr: RHB Sage base ptr a1030000
[*09/27/2023 21:56:17.6230] ptr a1030000
[*09/27/2023 21:56:17.6420] DOT11_DRV[0]: set_channel Channel set to 1/20
[*09/27/2023 21:56:17.8120] DOT11_DRV[1]: set_channel Channel set to 36/20
[*09/27/2023 21:56:17.9350] Previous AP mode is 0, change to 0
[*09/27/2023 21:56:18.0160] Current session mode: ssh, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1220] Current session mode: telnet, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1310] Current session mode: console, Configured: Telnet-No, SSH-Yes, Console-Yes
[*09/27/2023 21:56:18.1340] chpasswd: password for user changed
[*09/27/2023 21:56:18.1350] chpasswd: password for user changed
[*09/27/2023 21:56:18.1520] systemd[1]: Starting Cisco rsyslog client watcher...
[*09/27/2023 21:56:18.1610] Same LSC mode, no action needed
[*09/27/2023 21:56:18.1640] CLSM[00:00:00:00:00:00]: U3 Client RSSI Stats feature is deprecated; can no longer be enabled
[*09/27/2023 21:56:18.1720] systemd[1]: Stopping rsyslog client...
[*09/27/2023 21:56:18.2120] systemd[1]: Starting Cisco syslog service...
[*09/27/2023 21:56:18.2230] systemd[1]: Started Cisco syslog service.
[*09/27/2023 21:56:18.2410] systemd[1]: Started rsyslog client.
[*09/27/2023 21:56:18.2440] AP is in good condition, BLE is off
[*09/27/2023 21:56:18.2510] SET_SYS_COND_INTF: allow_usb state: 1 (up) condition 
[*09/27/2023 21:56:18.2530] systemd[1]: Starting dhcpv6 client watcher...
[*09/27/2023 21:56:18.2530] systemd[1]: Stopping DHCPv6 client...
[*09/27/2023 21:56:18.2530] systemd[1]: Starting DHCPv6 client...
[*09/27/2023 21:56:18.2530] systemd[1]: Started DHCPv6 client.
[*09/27/2023 21:56:18.2530] systemd[1]: Started dhcpv6 client watcher.
[*09/27/2023 21:56:18.2560] Set radio 0 power 4 antenna mask 15
[*09/27/2023 21:56:18.2530] Set radio 1 power 4 antenna mask 15
[*09/27/2023 21:56:18.2530] Got WSA Server config TLVs
[*09/27/2023 21:56:18.2720] AP tag change to default-policy-tag
[*09/27/2023 21:56:18.2780] Chip flash OK

設定

スタティックWLCの選択

GUIでは、Configuration > Wireless > Access Pointsの順に選択し、APを選択して、High Availabilityタブに移動できます。ここでは、このドキュメントの「ワイヤレスLANコントローラの選択」セクションで説明されているように、プライマリ、セカンダリ、およびターシャリ WLCを設定できます。この設定は、アクセスポイントごとに行います。

APのプライマリ、セカンダリ、ターシャリWLC。

APのHigh Availabilityタブで設定されるプライマリ、セカンダリ、ターシャリコントローラは、CAPWAP > High AvailabilityタブでAP Join Profileごとに設定できるバックアッププライマリおよびセカンダリ WLCとは異なることに注意してください。プライマリ、セカンダリ、ターシャリコントローラは、それぞれプライオリティ1、2、3のWLCと見なされ、バックアッププライマリおよびセカンダリは、プライオリティ4および5のWLCと見なされます。

AP Fallbackが有効な場合、APは別のWLCに加入するときにプライマリコントローラをアクティブに検索します。CAPWAPダウンイベントが発生し、バックアッププライマリおよびセカンダリコントローラが使用できない場合、APはプライオリティ4および5のWLCのみを検索します。

AP加入プロファイルのハイアベイラビリティオプション

APへのTelnet/SSHアクセスの有効化

Configuration > Tags & Profiles > AP Join > Management > Deviceの順に選択し、SSHまたはTelnet、あるいはその両方を選択します。

AP加入プロファイルでのTelnet/SSHアクセスの有効化

SSH/Telnetクレデンシャルを設定するには、同じウィンドウでUserタブに移動し、Username、Password、およびSecretを設定してAPにアクセスします。

APのSSHおよびTelnetクレデンシャル

データリンク暗号化

APのトラフィックのパケットキャプチャを実行する必要があるクライアントの問題をトラブルシューティングする必要がある場合は、Configuration > Tags & Profiles > AP Join > CAPWAP > AdvancedでData Link Encryptionが有効になっていないことを確認します。そうしないと、トラフィックが暗号化されます。

データリンク暗号化

確認

APのコンソールでCAPWAP状態マシンを追跡することに加えて、WLCで組み込みパケットキャプチャを取得してAP加入プロセスを分析することもできます。

WLCの組み込みパケットキャプチャに見られるAP加入プロセス

Chance Cipher Specパケット（パケット番号1182）の後のすべてのトラフィックが、DTLSv1.2を介したアプリケーションデータとしてのみ表示される点に注意してください。これは、DTLSセッションの確立後のすべての暗号化データです。

トラブルシュート

既知の問題

APのWLCへの加入を妨げる可能性がある既知の問題を参照してください。

• Wave 2およびCatalyst 11axアクセスポイント(CSCvx32806)の破損したイメージによるブートループのAP
• Field Notice72424:2022年9月以降に製造されたC9105/C9120/C9130アクセスポイントがWireless LAN Controllerに加入するには、ソフトウェアのアップグレードが必要になる場合があります。
• Field Notice72524：ソフトウェアのアップグレード/ダウングレード中に、証明書の期限切れによりCisco IOS APが2022年12月4日以降もDownloading状態のままになる場合がある – ソフトウェアのアップグレードを推奨
• Cisco Bug ID CSCwb13784:AP加入要求で無効なパスMTUが原因でAPが9800に加入できない
• Cisco Bug ID CSCvu22886:17.7へのアップグレード時のC9130：メッセージ「unlzma: write: No space left on device」、/tmpの最大サイズの増加

アップグレードする前に、各バージョンのリリースノートの「アップグレードパス」セクションを必ず参照してください。

WLC GUIのチェック

WLCで、Monitoring > Wireless > AP Statistics > Join Statisticsの順に選択すると、任意のAPから報告されたLast Reboot ReasonとWLCに登録されたLast Disconnect Reasonを確認できます。

WLCのAP加入統計情報ページ

任意のAPをクリックして、AP加入統計情報の詳細を確認できます。ここでは、APが最後に加入してWLCの検出を試行した日時など、より詳細な情報を確認できます。

一般的なAP加入統計情報

詳細については、同じウィンドウのStatisticsタブを参照してください。ここで、送信された参加応答の量と受信された参加要求の量、および送信された設定応答と受信された設定要求の量を比較できます。

詳細なAP加入統計情報

コマンド

次のコマンドは、APの加入に関する問題のトラブルシューティングに役立ちます。

WLCから

• show ap summary
• debug capwapエラー
• CAPWAPパケットのデバッグ

Wave 2およびCatalyst 11ax APから

• debug capwap client events
• debug capwap client error
• debug dtls clientエラー
• debug dtls client event
• debug capwap client keepalive
• CAPWAP再起動のテスト
• capwap ap erase all（すべて消去）

Wave 1 APから

• debug capwap console cli
• debug capwap client no-reload
• show dtls stats
• clear cawap all-config

放射性物質トレース

APの加入に関する問題をトラブルシューティングする場合は、まず、加入に関する問題が発生しているAPの無線MACアドレスとイーサネットMACアドレスの両方の放射性トレースを調べます。これらのログの生成の詳細については、『Catalyst 9800 WLCでのデバッグとログの収集』を参照してください。