目录

简介

先决条件

要求

使用的组件

背景信息

CAPWAP会话建立

DTLS会话建立

无线LAN控制器发现方法

无线LAN控制器选举

CAPWAP状态机

CAPWAP状态：发现

CAPWAP状态：DTLS设置。

CAPWAP状态：加入

CAPWAP状态：图像数据

CAPWAP状态：配置

CAPWAP状态：运行

配置

静态WLC选举

启用对AP的Telnet/SSH访问

数据链路加密

验证

故障排除

已知问题

WLC GUI检查

命令

从WLC

来自Wave 2和Catalyst 11ax AP

来自第1波AP

放射性痕迹

简介

本文档详细介绍 Cisco Catalyst 9800 WLC 的 AP 加入过程。

先决条件

要求

Cisco 建议您了解以下主题：

- 基本了解控制和调配无线接入点(CAPWAP)

- 基本了解无线Lan控制器(WLC)的使用

使用的组件

本文档中的信息基于以下软件和硬件版本：

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

- Catalyst 9120AX接入点

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

背景信息

CAPWAP会话建立

控制和调配无线接入点(CAPWAP)是提供接入点(AP)和无线局域网控制器(WLC)使用的传输机制的协议，用于通过安全通信隧道（用于CAPWAP控制）交换控制和数据平面信息。

要详细介绍AP加入流程，您必须了解控制和调配无线接入点(CAPWAP)会话建立流程。

请记住，AP需要有IP地址才能启动CAPWAP进程。如果AP没有IP地址，则不会启动CAPWAP会话建立过程。

1. 接入点发送发现请求。有关此问题的详细信息，请参阅WLC发现方法部分

2. WLC发送发现响应

3. DTLS会话建立。之后，此命令后的所有邮件都会被加密，并在任何数据包分析工具中显示为DTLS应用数据包。

4. 接入点发送加入请求

5. WLC发送加入响应

6. AP执行映像检查。如果它与WLC具有相同的映像版本，则会继续执行下一步。如果没有，则会从WLC下载映像并重新启动以加载新映像。在这种情况下，它会重复步骤1中的过程。

7. 接入点发送一个配置状态请求。

8. WLC发送配置状态响应

9. 接入点进入运行状态

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发送包含用于验证的cookie的HelloVerifyRequest消息。

3. AP发送包含用于验证的cookie的ClientHello消息。

4. WLC按以下顺序发送这些数据包：

1. ServerHello

2. 证书

3. 服务器密钥交换

4. 证书请求

5. ServerHelloDone

5. AP按以下顺序发送这些数据包：

1. 证书

2. ClientKeyExchange

3. 证书验证

4. ChangeCipherSpec

6. WLC使用自己的ChangedCipherSpec响应APChangeCipherSpec:

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尝试将响应发现请求的第一个WLC与具有最大可用AP容量的发现响应(即，在给定时间可支持最多AP的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

除了从静态配置的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、辅助和第三WLC，如本文档的无线LAN控制器选举部分所述。此配置按接入点执行。

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

注意：从Cisco IOS XE 17.9.2开始，您可以使用启动配置文件为一组与正则表达式(regex)匹配的AP或单个AP配置主、辅助和第三控制器。有关详细信息，请参阅配置指南的AP回退到在AP启动配置文件下配置的控制器部分。

请注意，AP High Availability选项卡中配置的主控制器、辅助控制器和第三控制器与Backup Primary and Secondary WLC不同，后者可以在CAPWAP > High Availability选项卡下的Backup Primary and Secondary配置每个AP Join Profile。主、辅助和三级控制器被视为优先级分别为1、2和3的WLC，而备用主和辅助被视为优先级分别为4和5的WLC。

如果AP Fallback已启用，则AP会在加入其他WLC时主动查找主控制器。在发生CAPWAP Down事件且没有可用的备份主控制器和辅助控制器时，AP仅查找优先级为4和5的WLC。

AP加入配置文件中的高可用性选项

注意：在AP加入配置文件中配置备份主WLC和备份辅助WLC不会填充接入点的High Availability选项卡中的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接入点可能需要软件升级才能加入无线局域网控制器。

- 问题信息通告72524：在软件升级/降级期间，由于证书过期，Cisco IOS AP可能会在2022年12月4日后保持下载状态 — 建议进行软件升级

- Cisco Bug ID CSCwb13784（仅限注册用户）：由于AP加入请求中的路径MTU无效，AP无法加入9800

- 思科漏洞ID CSCvu22886:C9130:消息“unlzma:写入：升级到17.7时设备“ ”上无剩余空间，增加/tmp的最大大小

在升级之前，请始终参阅每个版本的发行说明的升级路径部分。

注意：从Cisco IOS XE Cupertino 17.7.1开始，如果智能许可未连接和开启，Cisco Catalyst 9800-CL无线控制器不能接受超过50个AP。

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 error

- debug capwap packet

来自Wave 2和Catalyst 11ax AP

- debug capwap client events

- debug capwap client error

- debug dtls client error

- debug dtls client event

- debug capwap client keepalive

- test capwap restart

- capwap ap erase all

来自第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上的调试和日志集合。