1. 实验背景为什么我盯上了“无线本地转发”这阵子把无线本地转发实验配置完整跑了一遍趁着实验室里控制器和瘦AP都闲着把整套流程从拓扑规划、设备配置、流量验证到排错记录成一篇可复现的笔记。网络这行干久了会产生一个很直观的感受WLAN里最容易被“想当然”的就是数据转发路径。大部分人做无线项目时AP上线、SSID配好、能上网就认为完事了很少会去追问一句——终端这些业务流量到底从哪里走控制器会不会变成瓶颈漫游时路径又是怎么变的这篇记录适合三类人看一是正在准备WLAN相关实验、想把“本地转发”这个概念从文档落到命令行的朋友二是单位无线网络总感觉慢、想搞明白是不是控制器在“卡脖子”的运维同行三是刚开始接触瘦AP架构、对集中转发和本地转发还比较模糊的新手。我会按实验的真实推进顺序讲先交代为什么选本地转发再给完整配置最后把验证方法和踩过的坑全部摆出来。整个过程基于H3C的ACFIT AP环境不过转发模式的配置逻辑在多数厂商设备上是通用的你完全可以照着思路迁移。1.1 集中转发与本地转发两条完全不同的数据路径先解决最基础的问题瘦AP架构下AC和AP之间始终有一条CAPWAP隧道。集中转发模式里终端用户的数据包会被封装进CAPWAP数据隧道一路送到AC由AC解封装后再进入有线网络本地转发模式则不然AP收到终端数据后直接通过上行有线口转出去只有AP自身的注册、心跳、配置下发这类控制报文才走CAPWAP隧道。用一个生活化的例子集中转发就像便利店结算全部由总店统一收银每个门店只是把消费数据实时报上去本地转发则像每个门店自己收银打烊后向总店报账。总店统一收银的好处是账目集中、管控严格、坏账少但所有客流都要经过总店柜台高峰期必然排长队门店自己收银则吞吐量大、顾客体验好代价是总店对每一笔具体交易的管控变弱了——这个“弱管控”正是本地转发后续所有配置和心理准备的核心。集中转发适合对安全审计要求高、流量规模不大、需要AC统一做策略下发的场景本地转发则适合高带宽业务多、AC性能有限、用户访问的内网资源近在身边的场景。用大白话说如果你的无线网络里跑的是视频监控回传、文件服务器大量下载、办公内网高频访问数据流量全部绕到AC再回来纯粹是给自己找麻烦。1.2 本次实验的目标和适用场景这次实验不是要做一次简单的“AP连上AC能上网”的演示而是要把本地转发的完整链路验证到位。具体目标有三个第一在控制层面确认AP能正常注册上线AC能下发无线服务配置第二在数据层面确认终端业务流量走的确实是本地转发而非CAPWAP数据隧道第三在排错层面梳理出一套可复用的排查方法知道流量不通时到底该去AC上查还是去交换侧查。适用场景上本地转发在真实项目里最常见的三类部署是分支机构办公网AC部署在总部或远端本地转发避免跨广域网的隧道开销高密视频监控场景AP下挂大量摄像头视频流量本来就是本地存储或本地查看没必要绕AC以及控制器性能与业务带宽不匹配的场景用本地转发把AC从“苛刻转发节点”降级为“纯管理节点”。这些场景下的共性都是“数据面与管理面分离”的红利。2. 实验拓扑与前置准备2.1 组网拓扑和VLAN规划实验拓扑我搭得比较简单但结构代表了生产环境中最常见的一种形态。核心交换机作为三层网关和DHCP服务器旁挂一台无线控制器接入交换机通过Trunk上联核心下联APAP的上行口接在接入交换机上无线终端关联AP。这里有个重要的设计选择AC旁挂而不是串在数据通路上。旁挂意味着AC只在管理平面出现业务流量不经过它这与本地转发的思路天然一致。VLAN规划上我分了两个VLAN这是本地转发实验中最重要的规划动作VLAN用途网段网关位置说明VLAN 10管理VLAN192.168.10.0/24核心交换机AC与AP的CAPWAP控制报文走这里VLAN 20业务VLAN192.168.20.0/24核心交换机无线终端的数据流量走这里为什么必须分成两个VLAN最直接的原因是本地转发模式下如果业务VLAN的网关或三层接口还放在AC上终端的跨网段流量仍然要跑到AC去路由那“本地转发”就名存实亡了。业务VLAN网关必须放在核心交换机或更靠近数据出口的位置让AP转发出来的数据在接入侧就能完成路由。管理VLAN单独隔离还能避免AP的广播报文污染业务网段也能防止无线终端的异常流量冲击AC。2.2 设备清单与环境准备这次实验用了一台H3C WX系列的无线控制器、两台WA系列的FIT AP、一台二层接入交换机、一台核心交换机。如果条件有限接入交换机和核心交换机可以先在模拟器里完成但AP和AC强烈建议用真机因为抓包验证数据面行为、观察版本下发过程这些在模拟器里都还原不出来。软件准备方面我提前装好了SSH终端、Wireshark和iperf3。Wireshark用来做流量抓包iperf3用来生成测试流量跑吞吐对比。硬件和软件清单列出来之后还有一件特别容易被个人实验忽略的事AP版本文件。AC在发现AP后如果本地没有对应型号的AP版本文件AP会一直处于“下载”或“版本协商”状态。我之前就吃过这个亏以为AP坏了折腾半天发现是AC的apimage目录里根本没有该型号的版本文件。所以正式实验之前先确认AC系统版本再把对应AP型号的版本文件传到AC上能省掉后面一整个下午。另外建议把所有设备的软件版本号都记录下来。WLAN实验里很多“玄学问题”最后都能追溯到AC与AP版本不匹配、AP之间版本不一致上提前建一个版本记录表比问题出现后再翻聊天记录靠谱得多。3. 无线本地转发配置实操3.1 核心交换机与接入交换机的准备核心交换机这台设备承担了网关和DHCP的双重角色。先把VLAN和三层接口建好然后配置两个DHCP地址池。管理地址池负责给AP分配管理地址业务地址池负责给无线终端分配地址。这里有一个关键细节AP的DHCP Option 43会告诉AP“AC在哪里”。# 核心交换机Comware风格 vlan 10 vlan 20 interface Vlan-interface10 ip address 192.168.10.254 255.255.255.0 interface Vlan-interface20 ip address 192.168.20.254 255.255.255.0 # DHCP基础使能 dhcp enable # AP管理地址池 dhcp server ip-pool mgmt network 192.168.10.0 mask 255.255.255.0 gateway-list 192.168.10.254 dns-list 8.8.8.8 option 43 hex 8007000001c0a80a02 # 业务地址池 dhcp server ip-pool staff network 192.168.20.0 mask 255.255.255.0 gateway-list 192.168.20.254 dns-list 8.8.8.8Option 43这段十六进制字符串值得单独解释一下。H3C的AC地址Option 43子选项格式中80 07表示子选项类型和长度00 00 01是固定的子选项值最后的c0 a8 0a 02才是真正的AC IP地址。我实验里AC的管理地址是192.168.10.2换算成十六进制就是C0 A8 0A 02。初学者最容易在这里出错要么忘了换算要么把IP直接写ASCII字符串进去结果AP一直找不到AC。接入交换机上连接AP的接口配置比较关键必须是Trunk口而且PVID要设成管理VLANinterface GigabitEthernet1/0/1 port link-type trunk port trunk pvid vlan 10 port trunk permit vlan 10 20这里有个很容易踩的坑PVID必须设置成管理VLAN 10。AP刚上电时发出的报文是不带标签的交换机收到后如果PVID是VLAN 10它才能把这份Untagged报文划到管理VLAN里继续转发给AC如果PVID设成了默认的VLAN 1那管理报文就进了错误VLANAC自然发现不了AP。在实验中我曾把PVID漏配AP一直处于离线状态排查了很久才发现是这个小问题。3.2 AC侧基础配置与AP上线AC侧的管理地址要与核心交换机管理VLAN互通。实验里AC的管理地址是192.168.10.2走到核心交换机的默认路由即可。同时把CAPWAP源接口指定到管理VLAN的三层接口。这样AC与AP之间的控制报文就有了明确的源地址。# AC基础配置 vlan 10 interface Vlan-interface10 ip address 192.168.10.2 255.255.255.0 quit capwap source-interface Vlan-interface10AP上线有两种方式一种是让AC自动发现并注册所有AP另一种是先在AC上手工添加AP的MAC地址和型号。个人实验我推荐先用自动注册因为省事到了生产环境建议还是手工注册方便控制哪些AP能接入AC。AP通过DHCP拿到管理地址后再通过Option 43或二层广播发现AC随即建立CAPWAP隧道。如果AC里没有对应AP型号的版本文件它就会进入“下载”阶段等版本传输完成后再真正进入“运行”状态。你可以在AC上执行类似display wlan ap all的命令查看AP状态正常情况下应该是Run或R/M表示主备链路正常。如果一直显示在下载或版本协商按我前面的建议先去查apimage目录。3.3 无线服务模板与转发模式切换这是整个实验的核心环节。AC上创建一个无线服务模板指定SSID、绑定业务VLAN、选择转发模式。默认情况下不少AC会把转发模式设置为集中转发所以要主动切成本地转发。# AC无线服务模板 wlan service-template staff ssid Staff-WiFi vlan 20 forwarding-mode local authen-method open-system service-template enable quitforwarding-mode local这行命令非常关键它告诉AC这个SSID下的数据流量不要封装进CAPWAP数据隧道而是由AP直接转发。如果你不写这行或者写了forwarding-mode tunnel那即使前面网络规划得再好流量一样会绕到AC。认证方式在个人实验阶段建议先用open-system也就是免认证先把数据链路调通。生产环境再改成WPA2/802.1X之类的方式但那些认证配置与本地转发本身互不影响可以后续再叠加。改动无线模板后AC会重新下发配置给AP已连接终端会短暂掉线这是正常现象不用慌张。接着把服务模板绑定到AP组或AP的射频上wlan ap-group office vlan 20 ap-model WA6520 radio 1 service-template staff radio enable这里vlan 20的含义要搞清楚它让AP在处理无线终端数据时给下行业务报文打上VLAN 20的标签这样接入交换机收到后就能正确送入业务VLAN。有些新手只配了服务模板的VLAN而忘了AP组下的VLAN结果终端看到SSID却拿不到地址问题往往就出在这一层。3.4 配置完成后需要确认的状态配置完成后不做任何验证就开始使用是实验的大忌。我习惯先看三组状态。第一组是AC上的AP状态确认所有AP都注册在线第二组是无线客户端状态确认终端连接上了SSID并拿到了业务网段地址第三组是CAPWAP隧道统计确认数据隧道里没有跑业务流量。display wlan ap all // 查看AP在线状态 display wireless client // 查看无线终端与获取的IP display wlan service-template // 查看模板绑定与转发模式看AP状态时要关注的不只是“是否在线”还包括它拿到的管理地址、AC和AP之间的链路质量。看终端状态时要确认它拿到的地址是不是192.168.20.x如果拿到的是别的网段说明VLAN或DHCP配置有问题。看模板状态时重点核对forwarding-mode local已经生效很多AC上的配置改了却没有真正下发到AP终端侧的行为不会变化。4. 验证与流量分析怎么确认流量真的没走隧道4.1 行为验证之外还要做数据面验证最容易被误判的“成功”是终端能连上Wi-Fi能上网就宣称本地转发配置完成。这远远不够因为集中转发模式下终端一样能上网。要证明本地转发生效必须回到数据面去验证业务流量有没有经过AC。行为层面的验证有两个方向。第一个是看AC的负担在终端持续下载大文件的情况下观察AC的CPU和端口流量本地转发模式下AC端口几乎看不到业务流量集中转发模式下AC端口流量会明显飙升。第二个是看业务路径如果你在内网有一台服务器终端下载它上面的文件时本地转发模式的流量路径是终端→AP→接入交换机→核心→服务器AC完全不参与。不过行为验证只能作为辅助判断最硬的证据还得靠抓包。4.2 Wireshark抓包CAPWAP隧道里到底有什么抓包验证的思路是在接入交换机上把连接AP的上行口流量做镜像然后在镜像端口用Wireshark抓包。CAPWAP有两个著名端口需要记住UDP 5246是控制端口UDP 5247是数据端口。# Wireshark过滤器 udp.port 5246 || udp.port 5247在本地转发模式下你会看到大量UDP 5246的控制报文包括Keepalive心跳、配置确认等但UDP 5247数据端口基本是干净的最多只有少量空数据报文。在集中转发模式下则完全不同UDP 5247里会塞满终端访问网络的IP报文看起来就像把整条以太网帧又套了一个外皮。把两种模式的抓包结果放在一起看结论一目了然。另外如果无线终端和目的服务器在同一个二层VLAN内本地转发模式下抓AP上行口还能看到另一个细节AP发出的数据帧目的MAC是网关或目标服务器的MAC而不是AC的MAC这说明数据根本没有要往AC送的意思。4.3 用iperf3做吞吐对比只验证“没走隧道”还不够我想知道本地转发到底能比集中转发带来多少实打实的带宽收益。实验里我在一台有线终端上跑iperf3服务端无线终端上跑iperf3客户端分别测试两种转发模式下的TCP吞吐量。# 服务端 iperf3 -s # 客户端 iperf3 -c 192.168.20.254 -t 60 -i 5同样一台AP、同一个位置、同样的空口条件本地转发模式下测试吞吐大约在450 Mbps左右集中转发模式只有明显更低一些的数值。这背后的原因是多重的集中转发多了CAPWAP封装和解封装开销数据要跨过AC这个中间节点AC的转发能力成为瓶颈而本地转发模式下AP解完无线帧直接走有线口数据链路几乎没有任何额外处理。当然我这里的数据只是个人实验室环境的实测参考无线空口受环境干扰影响很大不能直接拿去做方案承诺但趋势是稳定的转发瓶颈在AC时本地转发收益就越大。5. 常见问题与排查技巧实录5.1 终端能连上Wi-Fi但上不了网这个现象是本地转发实验中出现频率最高的问题。排查的首要步骤是看终端拿到的IP地址如果终端拿到了169.254.x.x这类保留地址说明DHCP过程失败了如果拿到了192.168.20.x但上不了网说明路由或放行有问题。关键认知是本地转发模式下AC已经不再转发业务数据所以业务DHCP失败不要在AC上找原因而是去有线侧查。排查顺序是接入交换机上接AP的Trunk口是否放行了VLAN 20PVID是否仍是VLAN 10核心交换机上VLAN 20的三层接口和地址池是否存在地址池网段和网关是否匹配拿一根网线把PC直接接到接入交换机的Trunk口并模拟终端行为看有线侧能否拿到192.168.20.x地址。如果有线侧都拿不到问题基本与无线无关全在交换侧。我个人的经验是这类问题有七成以上出在交换机Trunk口没有放行业务VLAN或者PVID配置错误。先把交换侧捋顺远比在AC上反复重启服务模板有用。5.2 AP频繁重启、版本下载失败表现为AP上线后反复重启或AC上AP状态长时间停留在“下载”甚至“版本协商”阶段。这通常是AC上缺少对应AP型号的版本文件或者版本不兼容导致的。处理方法是将正确的AP版本文件上传到AC的apimage目录并在AC上确认版本配置与实际AP型号匹配。个人实验环境的设备可能来自不同渠道型号版本混乱是常态我建议在AC上先查看当前已有版本文件再对照AP型号逐一确认而不是一股脑把网上下载的版本文件全传上去。另一个坑是AP软件版本和AC软件版本的兼容性列表。即使是同一厂商老版本AC配新版本AP也可能出现注册异常。如果实验室有条件尽量让所有设备系统的软件版本保持在一个大版本周期内。5.3 本地转发不生效的排查要点如果抓包发现UDP 5247里依然有业务数据包说明本地转发没有真正生效。大多数情况下是配置层面出了问题。我实际遇到过三种典型情况。第一服务模板里漏写forwarding-mode local或者写完后没有重新下发到AP。AC上的配置修改不是即时的有时需要重启服务模板或等待AP重新获取配置。第二AP组下有多个模板SSID绑定的模板与AP射频实际绑定的模板不是同一个业务流量走的还是其他模板的老配置。第三AC版本较老转发模式在部分模板参数里是全局参数而非模板参数被旧的全局配置覆盖。快速判定方法就是抓包用数据端口是否有业务报文作为唯一标准。不要靠感觉不要靠看配置界面直接抓包说话。5.4 组播、广播与漫游的坑本地转发把数据面从AC上解放出来同时也把原本AC承担的广播抑制压力转移到了有线侧。业务VLAN里无线终端的广播报文会被AP直接送上接入交换机如果交换侧没有配置风暴抑制DHCP请求、ARP广播、NetBIOS广播等混在一起业务VLAN里的设备可能被广播报文拖垮。我的建议是接入交换机上开启DHCP Snooping、动态ARP检测和风暴抑制这几个功能对WLAN场景尤其有用。DHCP Snooping能防止非法DHCP服务器干扰无线终端获取地址风暴抑制能防止异常广播影响整个VLAN。漫游方面本地转发模式下同一AC内、同一个业务VLAN的二层漫游没有问题因为AP转发路径相似终端在新AP下重新关联后继续走本地转发即可。但如果业务VLAN跨三层终端从一个VLAN漫游到另一个VLAN本地转发模式下就要考虑跨VLAN漫游的处理机制常见的方案是配置AC上的漫游隧道或快速漫游否则终端会直接掉线重连。个人实验里建议先把跨VLAN漫游这个问题暂时避开不要一开始就把网络设计得过于复杂。这次实验做完我个人最大的感受是本地转发不是“少配一行命令”的简化方案它把数据中心从AC推移到了交换侧你的注意力也必须跟着转移。管理VLAN与业务VLAN的严格划分、接入交换机Trunk的精细放行、DHCP Snooping和风暴抑制这些交换基本功才是本地转发真正稳不稳定的关键。以后我要在这种环境里继续做ACL、IPv6或者安全策略实验时这套本地转发的无线底座可以直接复用省去重新搭建基础网络的功夫也算这次实验意外的长期回报。