CAPWAP基础原理

AP技术介绍

AP介绍：

无线局域网络的架构主要分为：

1. 基于控制器的AP架构（瘦AP，FitAP）

2. 传统的独立AP架构（胖AP，Fat AP）

   胖AP：

所谓的胖AP，典型的例子为无线路由器。无线路由器与纯AP不同，除无线接入功能外，一般具备WAN、LAN两个接口，多支持DHCP服务器、DNS和MAC地址克隆，以及VPN接入、防火墙等安全功能。

瘦AP：

瘦AP是“代表自身不能单独配置或者使用的无线AP产品，这种产品仅仅是一个WLAN系统的一部分，负责管理安装和操作”。

• 对于可运营的WLAN，从组网的角度，为了实现WLAN网络的快速部署、网络设备的集中管理、精细化的用户管理，相比胖AP（自治性AP）方式，企业用户以及运营商更倾向于采用集中控制性WLAN组网（瘦AP+AC），从而实现WLAN系统、设备的可运维、可管理。
• AC和瘦AP之间运行的协议一般为CAPWAP协议。

胖AP与瘦AP比较：

CAPWAP隧道介绍

CAPWAP背景：

传统的WLAN体系结构已经无法满足大规模组网的需求，因此，IETF成立的CAPWAP（Control And Provisioning of Wireless Access Points 无线接入点的控制和配置协议）工作组，研究打过没WLAN的解决方案。以实现各个厂家控制器与AP间的互通。

CAPWAP的起源：

CAPWAP工作组对以上四种通信协议进行评测后，最终采用LWAPP协议作为基础进行扩展，使用DTLS安全技术，加入其他三种协议的有用特性，制定了CAPWAP协议。

CAPWAP介绍：

CAPWAP（无线接入点控制和配置协议），用于无线终端接入点（AP）和无线网络控制器（AC）之间的通信交互，实现AC对其所关联的AP集中管理和控制。

该协议包含的主要内容有：

1. AP对AC的自动发现及AP和AC的状态机运行、维护。
2. AC对AP进行管理，业务配置下发。
3. STA数据封装CAPWAP隧道进行转发。

CAPWAP模式：

CAPWAP协议支持两种操作模式：SPlit MAC和Local MAC。

Split MAC模式：

• 在Split MAC模式下，所有二层的无线数据和管理帧都被CAPWAP协议封装，在AC和AP之间交互。
• 从STA收到的无线帧，直接封装，转发给AC。
• 在split MAC模式下，无线报文不经过报文转换，直接到达AC。

Local MAC模式：

本地转发模式允许数据帧可以用本地桥或者使用802.3的帧形式用隧道转发。二层无线管理帧在AP本地处理，然后再转发给AC。

STA传送的无线帧在AP被封装成802.3数据帧。

CAPWAP报文格式：

1. CAPWAP是基于UDP端口的应用层协议。

2. CAPWAP协议传输层运输两种类型的负载：

   数据消息，封装转发无线帧 。

   控制消息，管理AP和AC之间交换的管理消息 。

3. CAPWAP数据和控制报文基于不同的UDP端口发送：

   控制报文端口为UDP端口5246。

   数据报文端口为UDP端口5247。

瘦AP发现AC：

瘦AP发现AC的流程：

图：瘦AP发现AC的流程

AP上电后，当存在预配置的AC IP列表时，则AP直接启动预配置静态发现流程并与指定的AC连接。

如果未配置AC IP列表，则启动AP动态发现AC机制，执行DHCP/DNS/广播发现流程后与AC连接。

瘦AP发现AC的过程：

图：瘦AP发现AC的过程

1. AP启动以后会通过DHCP获取IP地址、DNS server、域名。
2. AP发出L2广播的发现请求报文试图联系一个AC。
3. 如果长时间（30秒）没有响应,AP会启动L3发现。AP会从DHCP Server通过Option43获得AC的IP，或者通过Option15获得AC的域名，AP向该IP地址（域名）发送发现请求。
4. 接收到发现请求报文的AC会检查该AP是否有接入本机的权限，如果有则回应发现响应。
5. AC和AP间建立CAPWAP隧道。

CAPWAP隧道建立：

图：CAPWAP隧道建立的总体过程

CAPWAP隧道建立过程有：

• Discovery阶段
• DTLS协商阶段（可选）
• Join阶段
• Image data阶段（可选）
• configure
• Data check阶段
• Run（Data）阶段
• Run（Control）阶段

CAPWAP隧道建立-DHCP:

图：DHCP的四步交互

DHCP的四步交互：

1. 在没有预配置AC IP列表时，则启动AP动态AC发现机制。通过DHCP获取IP地址，并通过DHCP协议中的option返回AC地址列表。
2. 首先是AP发送discover广播报文，请求DHCP server响应，在DHCP服务器侦听到discover报文后，它会从没有租约的地址范围中，选择最前面的空置IP，连同其他TCP/IP设定，响应AP一个DHCP offer报文，该报文中会包含一个租约期限的信息。
3. 由于DHCP offer报文既可以是单播报文，也可以是广播报文，当AP端收到多台DHCP Server的响应时，只会挑选其中一个offer(通常是最先抵达的那个)，然后向网络中发送一个DHCP request广播报文，告诉所有的offer，并重新发送DHCP，DHCP server它将指定接收哪一台服务器提供的IP地址，同时，AP也会向网络发送一个ARP封包，查询网络上面有没有其他机器使用该IP地址，如果发现该IP已被占用，AP会发送出一个DHCP Decline封包给DHCP服务器，拒绝接收其DHCP discover 报文。
4. 当DHCP Server接收到AP的request报文之后，会向AP发送一个DHCP Ack响应，该报文中携带的信息包括了AP的IP地址，租约期限，网关信息，以及DNS server IP等，以此确定租约的正式生效，就此完成DHCP的四步交互工作。

CAPWAP隧道建立-Discovery：

图：AC发现机制

AC发现机制：

1. AP使用AC发现机制来获知哪些AC是可用的，决定与最佳AC来建立CAPWAP的连接。（当然，AP的发现过程是可选的，如果在AP上已经静态配置了AC，那么就不需要完成AC的发现过程。）
2. AP启动CAPWAP协议的发现机制，以单播或广播的形式发送发现请求报文试图关联AC，AC收到AP的discovery request以后，会发送一个单播discover response 给AP，AP可以通过discover response中所带的AC优先级或者AC上当前AP的个数等，确定与哪个AC建立会话。

CAPWAP隧道建立-DTLS（可选）：

图；DTLS握手

DTLS握手：

1. AP根据此IP地址与AC协商，AP接收到响应消息后开始与AC建立CAPWAP隧道，这个阶段可以选择CAPWAP隧道是否采用DTLS加密传输UDP报文。
2. DTLS: Datagram Transport Layer Security（数据报传输层安全协议）

CAPWAP隧道建立-join：

图：Join过程

Join：

• 在完成DTLS握手后，AC与AP开始建立控制通道，在建立控制的交互过程中，AC回应的Join response报文中会携带用户配置的升级版本号，握手报文间隔/超时时间，控制报文优先级等信息。AC会检查AP的当前版本，如果AP的版本无法与AC要求的相匹配时，AP和AC会进入Image Data状态做固件升级，以此来更新AP的版本，如果AP的版本符合要求，则进入configuration状态。

CAPWAP隧道建立-image date（可选）：

图：image date

image data：

1. AP根据协商参数判断当前版本是否是最新版本，如果不是最新版本，则AP将在CAPWAP隧道上开始更新软件版本。
2. AP在软件版本更新完成后重新启动，重复进行AC发现、建立CAPWAP隧道、加入过程。

CAPWAP隧道建立-configure：

图：Configure过程

Configuration：

• 进入Configuration状态后是为了做AP的现有配置和AC设定配置的匹配检查，AP发送configuration request到AC，该信息中包含了现有AP的配置，当AP的当前配置与AC要求不符合时，AC会通过configuration response通知AP。

CAPWAP隧道建立-date check：

图：date check过程

Data Check ：

• 当完成configuration后，AP发送change state event request信息，其中包含了radio，result，code等信息，当AC接收到change state event request后，开始回应change state event response 。

至此完成data check 后，已经完成管理隧道建立的过程，开始进入run状态。

CAPWAP隧道维护-run（date）：

图；Run数据过程

Run：

1. AP发送keepalive到AC，AC收到keepalive后表示数据隧道建立，AC回应keepalive，AP进入“normal”状态，开始正常工作。

CAPWAP隧道维护-run(control):

图：run（控制）过程

管理隧道维护：

• AP进入run状态后，同时发送echo request报文给AC，宣布建立好CAPWAP管理隧道并启动echo发送定时器和隧道检测超时定时以检测管理隧道时候异常。
• 当AC收到echo request报文后，同样进入run状态，并回应echo response报文给AP，启动隧道超时定时器。
• 到AP收到echo response报文后，会重设检验隧道超时的定时器。