目錄

簡介

必要條件

需求

採用元件

背景資訊

CAPWAP會話建立

DTLS會話建立

無線LAN控制器探索方法

無線LAN控制器選擇

CAPWAP狀態機

CAPWAP狀態：發現

CAPWAP狀態：DTLS設定

CAPWAP狀態：加入

CAPWAP狀態：影象資料

CAPWAP狀態：設定

CAPWAP狀態：運行

設定

靜態WLC選擇

啟用對AP的Telnet/SSH訪問

資料連結加密

驗證

疑難排解

已知的問題

WLC GUI檢查

指令

在WLC上

來自Wave 2和Catalyst 11ax AP

來自Wave 1 AP

放射性痕跡

簡介

本檔案將詳細介紹使用Cisco Catalyst 9800 WLC的AP加入程式。

必要條件

需求

思科建議您瞭解以下主題：

- 基本瞭解控制和調配無線接入點(CAPWAP)

- 基本瞭解無線Lan控制器(WLC)的使用

採用元件

本文中的資訊係根據以下軟體和硬體版本：

- Catalyst 9800-L WLC、Cisco IOS® XE Cupertino 17.9.3

- Catalyst 9120AXE存取點

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路運作中，請確保您瞭解任何指令可能造成的影響。

背景資訊

CAPWAP會話建立

控制和設定無線接入點(CAPWAP)是提供接入點(AP)和無線LAN控制器(WLC)使用的傳輸機制的協定，用於通過安全通訊隧道（用於CAPWAP控制）交換控制和資料平面資訊。

為了詳述AP加入流程，請務必瞭解控制和調配無線接入點(CAPWAP)會話建立流程。

請記住，AP在能夠啟動CAPWAP進程之前需要有一個IP地址。如果AP沒有IP地址，它不會啟動CAPWAP會話建立過程。

1. 接入點傳送一個發現請求。有關此問題的詳細資訊，請參閱WLC發現方法部分

2. WLC傳送探索回應

3. DTLS會話建立。此後，此步驟之後的所有郵件都會經過加密，並在任何資料包分析工具中顯示為DTLS應用程式資料包。

4. 接入點傳送加入請求

5. WLC傳送加入回應

6. AP執行映像檢查。如果它的映像版本與WLC相同，則它將繼續進行下一步。如果沒有，則會從WLC下載映像並重新啟動以載入新映像。在這種情況下，它重複步驟1中的過程。

7. 接入點傳送配置狀態請求。

8. WLC傳送組態狀態回應

9. 接入點進入RUN狀態

10. 在RUN狀態期間，會通過兩種方式執行CAPWAP隧道維護：

1. 交換Keepalive以維護CAPWAP資料隧道

2. AP向WLC傳送回應請求，WLC必須透過其各自的回應回應來應答。這是為了維護CAPWAP控制隧道。

CAPWAP會話建立過程

附註：根據RFC 5415,CAPWAP使用UDP埠5246（用於CAPWAP控制）和5247（用於CAPWAP資料）。

DTLS會話建立

一旦接入點收到來自WLC的有效發現響應，就會在它們之間建立DTLS隧道，以通過安全隧道傳輸所有後續資料包。這是建立DTLS會話的過程：

1. AP傳送客戶端Hello消息

2. WLC傳送一則HelloVerifyRequest訊息，其中包含用於驗證的cookie。

3. AP傳送ClientHello消息，其中包含用於驗證的cookie。

4. WLC按以下順序傳送這些封包：

1. ServerHello

2. 憑證

3. 伺服器金鑰交換

4. 證書請求

5. ServerHelloDone

5. AP按以下順序傳送這些資料包：

1. 憑證

2. ClientKeyExchange

3. 證書驗證

4. ChangeCipherSpec

6. WLC使用自己的ChangedCipherSpec對AP做出響應ChangeCipherSpec:

1. ChangeCipherSpec

在WLC傳送最後一個ChangedCipherSpec訊息後，安全通道已建立，且兩個方向傳送的所有流量現在均已加密。

無線LAN控制器探索方法

有幾種選項可讓存取點知道網路中是否存在一個WLC:

- DHCP選項43:此選項為AP提供要加入的WLC的IPv4地址。對於AP和WLC位於不同站點的大型部署，此過程非常方便。

- DHCP選項52:此選項為AP提供要加入的WLC的IPv6地址。在與DHCP選項43相同的場景中，其使用是方便的。

- DNS發現：AP查詢域名CISCO-CAPWAP-CONTROLLER.localdomain。您必須將DNS伺服器配置為解析要加入的WLC的IPv4或IPv6地址。對於將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的記錄。

附註：存取點會嘗試使用這些方法搜尋所有WLC，然後繼續進行下文所述的選舉程式。

無線LAN控制器選擇

AP使用任一WLC探索方法從任何WLC收到探索回應後，會選擇其中一個控制器加入此條件：

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、輔助或第三WLC，則AP嘗試將響應Discovery Request的第一個WLC與具有最大可用AP容量的Discovery Response(即，在給定時間可支援最多AP的WLC)加入。

CAPWAP狀態機

在AP控制檯中，您可以跟蹤CAPWAP狀態機，它跨越了CAPWAP會話建立一節中描述的步驟。

CAPWAP狀態：發現

在這裡，您可以看到Discovery Requests和Responses。觀察AP如何通過DHCP（選項43）接收WLC IP，以及如何向先前已知的WLC傳送Discovery Request:

[*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

除了從靜態配置的WLC(172.16.0.20)和通過DHCP選項43(172.16.5.11)指示的WLC接收發現響應外，此AP還從同一子網中的另一個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指令碼，該指令碼指示AP向WLC請求足夠的映像，並將其下載到其當前的非活動分割槽。

[*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狀態：發現)。

[*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

警告：由於證書過期，Wave 1接入點可能無法下載新影象。如需詳細資訊，請參閱現場通知72524，並仔細閱讀2022年12月4日以後由於映像簽名證書過期而導致的Cisco IOS AP映像下載失敗(CSCwd80290)支援檔案，以瞭解其影響和解決方案。

一旦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狀態：運行

此時，AP已成功加入控制器。在此狀態期間，WLC會觸發一種機制以覆寫AP要求的設定。您可以看到AP被推送了Radio和Credentials配置，而且由於WLC以前對此AP不瞭解，因此它還被分配給default policy tag。

[*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頁籤。在這裡，您可以設定主要、次要和第三WLC，如本檔案的無線LAN控制器選擇一節所述。此配置按接入點執行。

AP的主要、輔助和第三WLC。

附註：從Cisco IOS XE 17.9.2開始，您可以使用啟動配置檔案為一組與正規表示式(regex)匹配的AP或單個AP配置主、輔助和第三控制器。請參閱配置指南的AP Fallback to Controllers Configured Under AP Prime Profile部分瞭解詳細資訊。

請注意，在AP High Availability頁籤中配置的主、輔助和三級控制器與可以在CAPWAP > High Availability頁籤下的Backup Primary和Secondary WLC不同，後者可以根據AP加入配置檔案進行配置。主要、次要和第三控制器被視為分別具有優先順序1、2和3的WLC，而備份主要和輔助被視為具有優先順序4和5的WLC。

如果啟用AP Fallback，則AP在加入其他WLC時會主動查詢主控制器。只有發生CAPWAP Down事件且沒有可用的備份主控制器和輔助控制器時，AP才會查詢優先順序為4和5的WLC。

AP加入配置檔案中的高可用性選項

附註：在AP加入配置文件中配置備份主WLC和備份輔助WLC不會填充接入點的High AvailabilityTab中的Static Primary和Secondary條目。

啟用對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。否則，您的流量會進行加密。

資料連結加密

附註：資料加密僅加密CAPWAP資料流量。CAPWAP控制流量已經通過DTLS加密。

驗證

除了在AP控制檯中跟蹤CAPWAP狀態機外，您還可以在WLC中進行嵌入式資料包捕獲以分析AP加入過程：

在WLC中的嵌入式封包擷取中看到的AP加入程式

請注意，Chance Cipher Spec資料包（資料包1182）之後的所有流量如何僅顯示為Application Data over DTLSv1.2。這是DTLS會話建立後的所有加密資料。

疑難排解

已知的問題

請參閱可能阻止您的AP加入WLC的已知問題。

- 由於Wave 2和Catalyst 11ax存取點(CSCvx32806)中的映像損毀，導致開機回圈中的AP

- 公告72424:從2022年9月開始生產的C9105/C9120/C9130接入點可能需要升級軟體以加入無線LAN控制器。

- 公告72524:在軟體升級/降級期間，由於證書過期，Cisco IOS AP可能會在2022年12月4日後保持下載狀態 — 建議進行軟體升級

- 思科錯誤ID CSCwb13784:由於AP加入請求中的路徑MTU無效，AP無法加入9800

- 思科錯誤ID CSCvu22886:C9130:消息「unlzma:寫入：升級到17.7時，裝置「 」上無剩餘空間。增加/tmp的最大大小

升級之前，請始終參閱每個版本的發行說明的升級路徑部分。

附註：從Cisco IOS XE Cupertino 17.7.1開始，如果智慧許可未連線和開啟，Cisco Catalyst 9800-CL無線控制器接受的AP不會超過50個。

WLC GUI檢查

在WLC上，前往Monitoring > Wireless > AP Statistics > Join Statistics 您可以看到任何AP報告的Last Reboot Reason和WLC註冊的Last Disconnect Reason。

WLC上的「AP加入統計資訊」頁

您可以按一下任何AP並檢查AP加入統計資訊詳細資訊。在此，您可以看到更多詳細資訊，例如AP上次加入並嘗試發現WLC的時間和日期。

常規AP加入統計資訊

有關詳細資訊，請轉至同一視窗的「統計資訊」頁籤。在這裡，您可以比較傳送的加入響應數量與接收的加入請求數量，以及傳送的配置響應與接收的配置請求。

詳細的AP加入統計資訊

指令

這些命令對排除AP加入問題非常有用。

在WLC上

- show ap summary

- debug capwap error

- debug capwap packet

來自Wave 2和Catalyst 11ax AP

- 偵錯 capwap 用戶端事件

- debug capwap client error

- debug dtls client error（調試dtls客戶端錯誤）

- debug dtls client event

- debug capwap client keepalive

- test capwap restart

- capwap ap erase all

來自Wave 1 AP

- debug capwap console cli

- debug capwap client no-reload

- show dtls stats

- clear cawap ap ap all-config

附註：當您通過Telnet/SSH連線到AP進行故障排除時，在啟用AP上的調試後重現問題時，請始終發出terminal monitor命令。否則，您將看不到調試中的任何輸出。

放射性痕跡

排除AP連線問題的一個良好起點是獲取存在連線問題的AP的無線電和乙太網MAC地址的輻射跟蹤。有關生成這些日誌的詳細資訊，請參閱Catalyst 9800 WLC上的調試和日誌收集。