CAPWAP（Control and Provisioning of Wireless Access Points，无线接入点控制与配置协议）是瘦 AP（Fit AP）与无线控制器（AC）之间的核心通信协议，主要用于实现 AC 对 AP 的集中管理（配置下发、状态监控）和数据转发控制。其核心目标是将 AP 的 “控制平面”（管理、配置）与 “数据平面”（终端无线数据）分离，让 AP 专注于无线信号收发，AC 负责统一管控，适配大规模无线网络部署。主要分为控制报文（Control Message）和数据报文（Data Message）两类，分别承载管理控制信息和终端无线数据。其报文结构基于 UDP 协议，通过固定头部 + 可变字段（TLV 或数据载荷）实现灵活的信息交互。
CAPWAP 协议工作原理
CAPWAP 协议基于 “客户端 - 服务器” 架构（AP 为客户端，AC 为服务器），工作流程分为发现与关联、配置下发、数据转发、状态维护四大阶段，同时通过 “控制隧道” 和 “数据隧道” 实现不同类型流量的隔离传输。
一、核心架构：控制隧道与数据隧道分离
CAPWAP 在 AP 与 AC 之间建立两条逻辑隧道，分别承载不同流量，确保管理与数据互不干扰：
| 隧道类型 | 用途 | 传输内容 | 安全机制 |
|---|---|---|---|
| 控制隧道 | AC 对 AP 的集中管理（控制平面） | AP 发现请求、AC 响应、配置指令（如 SSID、信道、功率）、状态上报（AP 在线状态、终端接入数） | 基于 DTLS（Datagram TLS）加密，防止配置被篡改或窃取 |
| 数据隧道 | 终端无线数据的转发（数据平面） | 终端与上层网络的双向数据（如网页请求、文件传输） | 可选 DTLS 加密（根据网络安全需求启用），默认不加密 |
两条隧道均基于 UDP 传输（控制隧道默认端口5246，数据隧道默认端口5247），UDP 的低延迟特性更适配无线数据的实时传输需求。
二、完整工作流程（四阶段）
阶段 1：AP 发现与 AC 关联（AP 找到 AC 并建立连接）
这是 CAPWAP 的初始阶段，核心是让 AP 通过多种方式 “找到” AC，并完成身份认证与隧道建立，具体步骤如下：
-
AP 初始化与 IP 获取AP 上电后，通过 DHCP 协议获取自身 IP 地址、子网掩码、网关，以及AC 的 IP 地址（可通过 DHCP Option 43/60 字段下发，或预配置 AC 地址）。
- 若未通过 DHCP 获取 AC 地址，AP 会通过 “广播发现”（在本地网段发送 CAPWAP 发现请求）或 “组播发现”（发送到 CAPWAP 组播地址 224.0.1.144）寻找 AC。
-
AC 发现请求与响应AP 向获取到的 AC 地址（或广播 / 组播地址）发送CAPWAP Discovery Request（发现请求），携带 AP 的基本信息（如 AP 型号、MAC 地址、硬件版本）。AC 收到请求后，若 AP 在允许接入的列表中（基于 AP MAC 黑白名单），则返回CAPWAP Discovery Response（发现响应），携带 AC 的 IP 地址、优先级、负载情况（如当前管理的 AP 数量）。
-
AP 选择 AC（负载均衡）若 AP 收到多个 AC 的响应（如多 AC 部署场景），会根据 AC 的 “优先级” 和 “负载” 选择最优 AC（优先选择负载低、优先级高的 AC），避免单个 AC 过载。
-
身份认证与隧道建立AP 向选定的 AC 发送CAPWAP Join Request（关联请求），携带 AP 的认证信息（如预共享密钥 PSK，或数字证书）。AC 验证 AP 身份通过后，返回CAPWAP Join Response（关联响应），同时触发DTLS 握手，建立加密的 “控制隧道”—— 至此，AP 与 AC 的管理连接正式建立，AP 进入 “已关联” 状态。
阶段 2：AC 向 AP 下发配置（AP 按 AC 指令初始化无线参数）
AP 与 AC 关联后，AC 会将统一的无线配置下发到 AP，让 AP 按标准配置提供无线服务，步骤如下：
-
配置下发内容AC 通过控制隧道向 AP 推送配置指令，核心内容包括：
- 无线参数：SSID、信道、发射功率、加密方式（如 WPA2-PSK/AES）、终端接入限速；
- 网络参数：AP 管理 VLAN、终端数据 VLAN、DHCP snooping 开关；
- 业务参数：QoS 策略（如语音优先）、漫游配置（如 802.11r 快速漫游）。
-
AP 配置生效与确认AP 接收配置后，自动应用到无线射频（2.4G/5G），并通过控制隧道向 AC 发送配置确认报文（CAPWAP Configuration Status Response），告知 AC 配置已生效。此时，AP 的无线射频开始工作，终端可搜索到 AC 统一配置的 SSID 并尝试接入。
阶段 3：数据转发（终端无线数据通过 AP 与 AC 交互）
终端接入 AP 后，无线数据通过 CAPWAP “数据隧道” 在 AP 与 AC 之间传输，具体转发模式分为集中转发和本地转发（两种模式由 AC 配置决定）：
模式 1：集中转发（数据平面经 AC 中转）
- 原理：终端的无线数据先由 AP 封装为 CAPWAP 数据帧，通过数据隧道发送到 AC；AC 解封装后，将数据转发到上层网络（如核心交换机、互联网）；反之，上层网络的数据经 AC 封装为 CAPWAP 帧，通过数据隧道下发到 AP，再由 AP 转发给终端。
- 适用场景：需要 AC 统一管控数据（如流量审计、访问控制）的场景（如企业总部、校园核心区）。
模式 2：本地转发（数据平面在 AP 本地转发）
- 原理：AC 仅通过控制隧道向 AP 下发 “数据转发规则”（如 “终端数据 VLAN=120”）；AP 接收终端数据后，直接在本地将数据转发到对应 VLAN 的接入交换机（无需经过 AC 中转）；上层网络数据也直接通过接入交换机转发到 AP，再发给终端。
- 适用场景：大规模部署（如园区、商场），可减轻 AC 的数据转发压力，降低延迟。
阶段 4：状态维护与异常恢复（确保 AP 长期稳定工作）
AP 正常运行期间，AC 通过控制隧道实时监控 AP 状态，并处理异常情况，核心机制包括：
-
心跳保活（Keepalive）AP 每隔固定时间（默认 30 秒）通过控制隧道向 AC 发送CAPWAP Keepalive Request（心跳请求），携带 AP 当前状态（如在线终端数、射频状态、信号强度）。AC 收到心跳后返回Keepalive Response—— 若 AC 连续 3 次（可配置）未收到 AP 心跳，判定 AP “离线”，会触发 AP 重连流程。
-
AP 重连机制若 AP 因网络中断（如链路故障）与 AC 断开连接，会自动触发 “重发现” 流程：
- AP 先尝试重连原 AC（使用缓存的 AC 地址）；
- 重连失败后，重新执行 “阶段 1 的发现流程”（广播 / 组播发现），寻找其他可用 AC；
- 接入新 AC 后，新 AC 会重新下发配置，确保 AP 快速恢复服务（避免终端断网时间过长）。
-
动态调整（AC 主动优化）AC 通过 AP 上报的状态数据，动态优化 AP 配置：
- 信道调整：若检测到 AP 间信道干扰严重，AC 自动为 AP 分配空闲信道；
- 功率调整：若 AP 覆盖重叠过多，AC 降低部分 AP 的发射功率，减少干扰；
- 负载均衡：若某 AP 接入终端过多（如超过阈值），AC 引导新终端接入邻近负载低的 AP。
三、CAPWAP 协议的核心优势
- 集中管理：AC 统一管控所有 AP，避免分散配置的低效（如修改 SSID 时，仅需在 AC 操作一次，所有 AP 自动同步）；
- 灵活扩展：新增 AP 时，无需现场配置，AP 上电后自动发现 AC 并获取配置，适合大规模部署；
- 安全可靠：控制隧道基于 DTLS 加密，防止管理配置被窃取或篡改；支持 AP 身份认证，避免非法 AP 接入；
- 适配漫游：AC 统一维护终端的漫游信息（如终端 MAC、IP），终端在不同 AP 间漫游时，无需重新获取 IP，实现 “无缝漫游”（如语音通话不中断）。
四、关键注意事项
- 网络要求：AP 与 AC 之间的链路需保障带宽（尤其是集中转发模式），且延迟需低于 100ms（否则会影响终端体验）；
- 端口开放：防火墙需允许 UDP 5246（控制隧道）和 UDP 5247（数据隧道）端口通行，否则 AP 与 AC 无法建立隧道；
- 版本兼容性：AP 与 AC 的 CAPWAP 协议版本需匹配（如支持 CAPWAP v1），否则可能出现关联失败或配置下发异常。
CAPWAP报文解析
一、CAPWAP 通用头部结构（所有报文共有的基础字段）
无论控制报文还是数据报文，CAPWAP 报文均包含一个8 字节的通用头部（CAPWAP Header），用于标识报文基本属性，结构如下（按字节顺序）：
| 字段偏移（字节） | 字段名称 | 长度（位） | 含义与取值说明 |
|---|---|---|---|
| 0-0 | Version | 4 | CAPWAP 协议版本：目前仅支持版本 1（二进制0001），其他值为保留。 |
| 0-0 | Type | 1 | 报文类型：0表示控制报文（Control），1表示数据报文（Data）。 |
| 0-0 | Reserved | 1 | 保留位，固定为0。 |
| 0-0 | W | 1 | 无线帧标记：仅数据报文有效，1表示载荷为 802.11 无线帧，0表示以太网帧（有线数据）。 |
| 0-0 | M | 1 | 更多分片标记：1表示后续还有分片，0表示当前为最后一片（分片机制用于大报文传输）。 |
| 1-1 | Flags | 8 | 标志位：控制报文和数据报文的标志定义不同（见下文细分）。 |
| 2-3 | Length | 16 | 整个 CAPWAP 报文的总长度（字节），包括通用头部 + 后续所有字段（最大值为 1500 字节，适配 MTU）。 |
| 4-7 | WTP MAC Address | 32 | AP（WTP）的 MAC 地址（前 24 位为厂商 OUI，后 24 位为设备唯一标识），用于 AC 识别 AP。 |
| 8-11 | AC MAC Address | 32 | AC 的 MAC 地址，AP 发送报文时填写目标 AC 的 MAC，AC 响应时填写自身 MAC。 |
| 12-15 | Sequence Number | 32 | 序列号：单调递增，用于报文有序传输和重传检测（控制报文和数据报文各有独立序列号）。 |
二、控制报文解析（管理与配置交互）
控制报文用于 AP 与 AC 之间的管理操作（如发现、关联、配置下发、状态上报等），在通用头部之后增加控制头部（Control Header）和TLV 字段（Type-Length-Value，携带具体管理信息），完整结构为：通用头部 + 控制头部 + 多个TLV字段
1. 控制头部（Control Header，4 字节）
| 字段偏移（字节） | 字段名称 | 长度（位） | 含义与取值说明 |
|---|---|---|---|
| 16-17 | Message Type | 16 | 消息类型：标识控制报文的具体功能，如1= 发现请求（Discovery Request）、2= 发现响应（Discovery Response）、3= 关联请求（Join Request）、4= 关联响应（Join Response）等（共定义 30 + 种类型）。 |
| 18-19 | Message Length | 16 | 控制部分长度（字节）：即控制头部 + 所有 TLV 字段的总长度（不含通用头部）。 |
2. TLV 字段（核心信息载体，可变长度）
TLV 是控制报文携带具体信息的核心结构，每个 TLV 由 “类型（Type）+ 长度（Length）+ 值（Value）” 组成，用于传递 AP 能力、AC 配置、状态数据等。格式为：
- Type（2 字节）：标识 TLV 类型（如
1=AC 名称、5=WTP 描述、10= 支持的信道列表等）； - Length（2 字节）：Value 字段的长度（字节）；
- Value（可变长度）：具体内容（如 AC 名称为字符串、信道列表为字节数组）。
常见 TLV 类型及用途：
| TLV 类型（Type） | 名称 | 用途示例 |
|---|---|---|
| 1 | AC Name | 发现响应报文中，AC 返回自身名称（如 “AC-Office-01”）。 |
| 5 | WTP Description | 关联请求报文中，AP 上报自身信息（型号、硬件版本、支持的射频数）。 |
| 10 | Supported Channels | AP 在关联请求中上报支持的信道（如 5GHz 频段支持 36/40/44 信道）。 |
| 23 | Configuration Status | AP 在配置确认报文中返回配置是否生效（0= 成功，1= 失败）。 |
| 45 | DTLS Session | 关联阶段用于协商 DTLS 加密参数（如加密算法、会话密钥）。 |
3. 控制报文示例：发现请求（Discovery Request）
AP 上电后发送的第一个控制报文，用于寻找 AC，结构如下：
plaintext
通用头部：
Version=1（0x01），Type=0（控制报文），W=0，M=0
Length=40（总长度40字节）
WTP MAC=AA:BB:CC:DD:EE:FF（AP的MAC）
AC MAC=FF:FF:FF:FF:FF:FF（广播，未指定AC时）
Sequence Number=1（初始序列号）
控制头部：
Message Type=1（发现请求）
Message Length=24（控制部分长度24字节）
TLV字段：
TLV 1：Type=5（WTP Description），Length=12，Value=“AP-Model:RG-AP820-L”（AP型号）
TLV 2：Type=10（Supported Channels），Length=3，Value=0x24 0x28 0x2C（对应5GHz信道36/40/44）
三、数据报文解析（终端数据传输）
数据报文用于封装终端的无线数据（如手机、电脑的上网流量），在通用头部之后直接携带终端数据载荷（Payload），结构为：通用头部 + 数据头部（可选） + 终端数据载荷
1. 数据头部（Data Header，可选，2 字节）
仅当通用头部的 “W=1”（载荷为 802.11 无线帧）时存在，用于描述无线帧属性：
| 字段偏移（字节） | 字段名称 | 长度（位） | 含义与取值说明 |
|---|---|---|---|
| 16-16 | Priority | 3 | 802.11 无线帧的优先级（0-7，对应 WMM 服务等级：语音、视频、尽力而为、背景）。 |
| 16-16 | Reserved | 5 | 保留位，固定为0。 |
2. 终端数据载荷（Payload）
- 若为无线终端数据（W=1）：载荷是原始 802.11 无线帧（含终端 MAC、BSSID、数据内容），AP 接收后封装为 CAPWAP 数据报文发送给 AC（集中转发模式），或直接转发到有线网络（本地转发模式）。
- 若为有线数据（W=0）：载荷是以太网帧（含终端 IP、TCP/UDP 数据等），AC 接收后封装为 CAPWAP 数据报文下发给 AP，再由 AP 转换为无线帧发送给终端。
3. 数据报文示例：终端 HTTP 请求
手机连接 AP 后访问网页，AP 发送的数据报文结构：
plaintext
通用头部：
Version=1，Type=1（数据报文），W=1（载荷为802.11帧），M=0
Length=528（总长度528字节）
WTP MAC=AA:BB:CC:DD:EE:FF（AP的MAC）
AC MAC=11:22:33:44:55:66（目标AC的MAC）
Sequence Number=102（数据报文序列号）
数据头部（W=1时存在）：
Priority=3（尽力而为服务等级）
载荷（Payload）：
802.11无线帧（含手机MAC=AA:AA:AA:AA:AA:AA、BSSID=BB:BB:BB:BB:BB:BB、HTTP GET请求数据）
四、关键字段与安全机制
-
DTLS 加密：控制报文默认通过 DTLS 加密（基于通用头部后的 “DTLS 封装”），防止配置信息被窃取或篡改；数据报文可按需启用 DTLS（通过控制报文中的 “DTLS Session TLV” 协商）。
-
序列号与重传：通用头部的 “Sequence Number” 用于标识报文顺序，AC/AP 若发现序列号不连续（如缺失某序号），会触发重传请求，确保数据可靠传输。
-
分片机制：当报文长度超过 MTU（如大配置文件），“M” 标志位设为 1，将报文分片传输，接收方通过序列号重组分片。
扫一扫
3684
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
