AC+AP本地转发实验：数据面与管理面分离的无线组网配置与验证

做企业无线网络的人都知道ACAP架构下数据转发模式是最容易被忽略、又最影响体验的一个配置点。大多数人照着厂商文档搭完无线SSID能连上、能上网就收工了默认用的往往就是集中转发——所有无线数据先封装进CAPWAP隧道送到AC再由AC转发出去。终端少没问题终端一旦超过几十个或者有人在传大文件AC的CPU和隧道带宽就顶不住了。我这次做的是无线本地转发实验把FIT AP的数据面和管理面拆开让无线数据直接从AP进入有线网络。这篇就是完整实验记录从组网规划、VLAN划分到AC上的本地转发配置和结果验证适合刚接触企业级无线组网、想搞清楚两种转发模式区别或者正在规划高带宽无线网络时纠结选型的同学参考。1. 实验背景为什么偏偏要测本地转发1.1 集中转发的逻辑和它的瓶颈先说集中转发。在默认的FIT AP组网里AP通过CAPWAP隧道和AC建立连接管理报文和数据报文全部走这条隧道。简单说无线终端发出的数据先到APAP不直接处理而是加上CAPWAP头封装后发给ACAC打开隧道封装再按普通有线报文转发到核心网络。这种模式的好处是控制集中AC能看到所有用户的数据做认证、限速、ACL都很方便网络边界也简单业务VLAN只需要在AC侧规划AP侧几乎不用管VLAN。但问题也出在这。所有数据都汇聚到ACAC就同时承担了控制面和数据面的工作。我见过一个实际案例办公区100多号人每个终端平均带宽要求又不低集中转发模式下AC的吞吐直接飙到接近上限CPU时不时100%终端体验就是“时好时坏”。另外AP和AC之间的链路也被数据流量占满如果中间还有跨地域的传输链路成本更高。说白了集中转发适合终端少、流量小、安全控制要求高的场景一旦流量基数大了就必须给数据面“减负”。1.2 本地转发是怎么把数据面拆出来的本地转发的核心思想是CAPWAP隧道只保留管理控制报文无线用户的数据报文由AP根据配置打上业务VLAN的标签直接从AP的上行有线口转发到接入交换机再沿交换网络转发到网关。AC依然管理AP、下发配置、处理漫游和认证但用户流量不再经过AC。打个比方集中转发像是所有快递先送到一个总仓再由总仓分发本地转发则是每个网点自己直接发件总仓只管调度和看数据。这个差异带来的好处很明显数据路径短一截时延更低AC压力小AP到交换机的链路利用率也更高。代价是配置上要更细致业务VLAN、网关位置、AP与交换机的链路都要规划清楚故障排查也从“看AC一个点”变成了“看AP到网关整条链路”。1.3 实验目标清单我在做这个实验之前先给自己定了几个明确的验证点第一AC上配置完本地转发服务模板后AP能正常上线并下发配置第二无线终端接入后能获取到业务VLAN的地址且网关可达第三通过抓包和AC侧流量观察确认无线数据没有经过AC证明本地转发真实生效第四顺便测试一下终端漫游时业务是否稳定以及AC与AP链路中断时业务的存活情况。目标清晰后面实验就不容易跑偏。这也是我个人做实验的习惯先列验证清单再动手配设备不然配置完了也不知道该看哪些指标。2. 实验环境与参数规划2.1 组网拓扑与设备清单这次实验我在实验室搭了一套比较典型的旁挂式AC组网AC旁挂在核心交换机旁边AP通过POE交换机接入核心管理流量和业务流量共用物理链路但走不同VLAN。设备清单如下无线控制器H3C WX2540E软件版本Comware V7APH3C WA5320FIT模式数量建议两台以上方便测试漫游核心交换机H3C S5560负责VLAN间路由和DHCP服务接入交换机H3C S5130POE给AP供电和接入无线终端笔记本一台、手机一部。拓扑上用大白话描述就是AC接核心交换机核心交换机接POE交换机POE交换机接AP无线终端连AP的SSID。管理VLAN走192.168.10.0/24业务VLAN走192.168.20.0/24。2.2 VLAN与地址规划细节规划是最不能偷懒的部分本地转发对VLAN规划特别敏感。我的规划如下表用途VLAN网段网关/接口DHCPAP管理VLAN 10192.168.10.0/24核心交换机Vlan-interface10192.168.10.1核心交换机DHCP分配192.168.10.20及以后业务数据VLAN 20192.168.20.0/24核心交换机Vlan-interface20192.168.20.1核心交换机DHCP分配192.168.20.100及以后AC互联VLAN 30192.168.30.0/30AC192.168.30.2核心192.168.30.1不需要为什么把管理VLAN和业务VLAN拆开因为在本地转发模式下这两类报文的走向完全不同管理报文要上送AC业务报文要直接从AP进接入交换机。如果把两者放在一个VLAN后续看流量、做安全策略会非常混乱而且无法确认本地转发是否真正生效。AP管理地址这段我特意把DHCP地址池设在核心交换机上而不是AC上这样即使AC暂时不可达AP也能先拿到地址并保持在线等待管理。实验时验证AC中断场景业务甚至还能继续转发这一步很关键。2.3 设备版本与时间同步的小坑配置开始前先确认AC和AP的软件版本兼容。WA5320老版本和WX2540E的新固件有时会出现AP反复重连现象是AP能发现AC但状态始终是Fault。我的做法是先给AC升级到官方稳定版本再把AP固件升级到AC配套版本AP上线后系统会自动同步版本。这个坑如果忽略后面排查起来特别费时间。另外一个容易被忽视的问题是AC和核心交换机的NTP时间同步。无线认证、日志、抓包分析都依赖准确时间戳如果AC时间不对抓包时对应的客户端上下线记录和实际时间对不上实验记录会很难写。我在实验前把所有网络设备都指向同一个NTP服务器这点虽然不影响转发功能但直接影响排查效率。3. 核心配置实操让本地转发真正跑起来3.1 交换机侧的基础配置先说核心交换机S5560。第一步创建VLAN、配置VLAN接口IP第二步配置DHCP第三步把下行口放通管理VLAN和业务VLAN。核心交换机关键配置如下以Comware命令为例vlan 10 vlan 20 vlan 30 # interface Vlan-interface10 ip address 192.168.10.1 255.255.255.0 # interface Vlan-interface20 ip address 192.168.20.1 255.255.255.0 # interface Vlan-interface30 ip address 192.168.30.1 255.255.255.0 # dhcp server ip-pool ap gateway-list 192.168.10.1 network 192.168.10.0 mask 255.255.255.0 dns-list 114.114.114.114 # dhcp server ip-pool client gateway-list 192.168.20.1 network 192.168.20.0 mask 255.255.255.0 dns-list 114.114.114.114然后是接口配置。POE交换机上连核心的trunk口要放通VLAN 10和20下连AP的接口设置成trunk且PVID为VLAN 10。核心交换机上连AC的接口这个实验的AC只管理无线我就在互联接口放通VLAN 30。POE交换机下联AP的口我习惯用trunkPVID设为10并放通VLAN 10和20。这样AP自身管理报文不带Tag也能上送无线用户数据由AP打上VLAN 20的Tag后送出。如果AP型号较老也可以把PVID设为管理VLAN效果是一样的。3.2 AC侧让AP正常上线AC上我创建了Vlan-interface30作为管理地址并指定了核心交换机作为网关interface Vlan-interface30 ip address 192.168.30.2 255.255.255.0 # ip route-static 0.0.0.0 0.0.0.0 192.168.30.1AC上配置AP自动发现比较方便实验环境里我直接手动指定AP避免测试时混入无关设备wlan ap ap1 model WA5320 serial-number 219801A0CNC1234567 description lab-ap-1 # wlan ap ap2 model WA5320 serial-number 219801A0CNC7654321 description lab-ap-2AP上电后会广播寻找AC如果组网里有DHCP Option 43就自动找没有就手动指定。我用的是三层发现加Option 43的方式在DHCP地址池里给AP下发AC地址这样只要AP拿到管理地址就能定位AC。Option 43的具体格式和厂商有关华三这边是hex格式的AC IP配置的时候要注意地址换算别把进制搞错。3.3 服务模板与本地转发模式服务模板是VAP的灵魂。我创建了一个名为lab-local的无线服务模板关键命令是forward-mode localwlan service-template 1 ssid lab-local forward-mode local akm mode psk preshared-key pass-phrase simple lab123 cipher-suite ccmp security-ie rsn service-template enable这里解释一下为什么forward-mode local是关键。默认情况下Comware服务模板的转发模式是tunnel也就是集中转发。只有把模式改为localAP收到无线数据后才不会封装进CAPWAP隧道而是直接在本地查找对应的业务VLAN并转发。我个人习惯在模板里先不搞限速和高级策略把数据面跑通之后再去加bandwidth limit、ACL这些。另外要注意的是修改服务模板的转发模式最好在模板未绑定到AP组、未使能的情况下操作。我一开始图省事模板已经使能了再去改结果AP上VAP反复重建终端掉线好几次。所以规范顺序应该是先建模板再配模式最后使能。3.4 AP组与业务VLAN的绑定服务模板配完需要把它绑定到AP的射频上同时指定业务VLAN。这一步最容易出错因为它决定了AP收到无线数据后打哪个VLAN的Tag。我的配置思路是创建一个专门的AP组lab-group把测试用的AP都加进去wlan ap-group lab-group ap-model WA5320 radio 1 service-template 1 vlan 20 radio 2 service-template 1 vlan 20这里service-template 1 vlan 20表示VAP使用服务模板1并且无线用户的数据报文由AP打上VLAN 20的标签。如果漏掉vlan 20AP就会用管理VLAN或默认VLAN转发业务数据和核心交换机上的网关不在一个网段终端就上不了网。如果是单台AP直接在AP的radio下绑定也行效果一样。绑定之后记得在AC上确认配置下发display wlan ap all看到AP状态为R/M运行再在dis wlan client里看终端状态这才是配置闭环的关键。3.5 保存配置与初步验证所有配置完成后我在AC和交换机上都执行了save force。然后连接SSID lab-local在线播放视频、传文件终端拿到了192.168.20.100段的地址ping核心网关正常。这时还不能算完全验证成功因为“能上网”也可能是在集中转发模式下工作的。必须做数据路径确认这一步我单独拿出来讲因为它才是这个实验最有价值的部分。4. 验证与抓包证明数据真的没走AC4.1 从AC侧看流量特征本地转发生效后AC上最直观的表现就是数据流量几乎为0。我在AC上开了几个监控点一是dis wlan client verbose查看客户端条目里的Forwarding Mode字段如果显示Local说明AP不会把该客户端的数据隧道化二是看AC的CPU负载和接口流量终端跑大流量应用时AC对应接口流量并没有明显上涨这就很有说服力了。另外display wlan ap statistics里能看到CAPWAP隧道收发报文数量。正常情况管理报文数量平稳数据隧道报文不增长。如果发现数据报文也在涨说明本地转发并没有真正生效。我实际测试时一边让终端持续下载一个大文件一边在AC上用debug抓CAPWAP报文计数连续观察五分钟AC上数据平面的计数器基本纹丝不动管理控制报文则有规律地更新。这个现象基本可以断定数据面已经和AC解耦。4.2 在AP侧和交换机侧抓包印证比AC侧统计更直观的办法是抓包。我在POE交换机上做了端口镜像把AP上行口镜像到抓包口然后用Wireshark抓包。抓包结果里能明确看到两类报文管理类报文源地址是AP的管理IP192.168.10.x目的地址是AC的192.168.30.2走CAPWAP协议端口5246/5247数据类报文源地址是无线终端的业务IP192.168.20.x目的地址是网关或互联网地址是普通二层/三层报文没有CAPWAP封装。这个对比非常直观如果看到无线终端的数据全部被CAPWAP封装那就是集中转发如果终端的数据以普通报文形式出现在接入交换机上说明本地转发已经生效。另外还可以在核心交换机上看终端的ARP表现。本地转发模式下核心交换机直接就能看到终端的MAC地址因为终端数据是正常二层转发过来的集中转发模式下核心交换机看到的往往是AC的MAC或隧道终结后的源MAC终端MAC被藏在了隧道里。这个细节排查时特别好用。4.3 一次漫游断流问题的复现两台以上的AP就可以测漫游。我在两台AP之间做了简单的漫游测试终端从AP1走到AP2的信号范围断开再重连后IP地址不变因为业务VLAN二层可达漫游后数据路径仍然从新AP出去。但我复现了一个问题漫游瞬间丢了两三个包。原因大概是AP侧业务VLAN的MAC表项短暂缺失广播重新学习的时间差导致。这个现象在集中转发模式下很少见本地转发模式下更依赖接入交换机的MAC地址学习和快速收敛。解决办法是在接入交换机上把MAC地址表项老化时间适当调大或者在关键AP的接入口开启边缘端口特性让交换机尽快学习到终端MAC。实验环境里调完参数再漫游丢包明显减少。5. 常见问题与排查技巧实录5.1 终端连上SSID却拿不到IP这个现象排在本地转发实验踩坑榜第一名。排查思路按三步走第一步确认终端关联成功后在AC上看dis wlan client如果客户端状态是RUN且Forwarding Mode为Local说明VAP没问题第二步检查核心交换机Vlan-interface20是否upDHCP服务是否启用。手动给终端配一个192.168.20.x地址看能否ping通网关。能通网关说明二层三层都通问题就在DHCP第三步重点检查POE交换机上连AP的接口是否放通了业务VLANPVID是否与管理VLAN一致。如果AP的出口只放通了VLAN 10而AP打上的VLAN 20标签在交换机侧找不到对应的trunk放行报文直接就被丢弃。我见过最冤的一次就是POE交换机下联口的trunk白名单里忘加VLAN 20结果终端能关联、能拿到管理VLAN里的地址但所有业务报文进出都失败表现就是“能连上但上不了网”。排查了半小时才反应过来所以写配置时把交换机口子上的放行VLAN列表打印出来看一遍往往比在AC上反复猜更有效。5.2 AP一直不上线或反复重启AP不上线先看三个地方一是管理VLAN是否可达AP能不能从DHCP拿到地址二是AC的版本是否兼容三是Option 43下发的AC地址是否正确。前两个都正常就看display wlan ap all里的状态如果长时间停留在Fault或Download多半是AP和AC固件不匹配导致版本自动下载失败。这个场景我前面提过排查重点是先把AC升级到官网推荐版本再让AP重新发起注册。还有一个小概率问题是AP的管理VLAN和AC不在同一个三层域但中间路由器没有回程路由。AC能看到AP发来的发现请求却无法回包AP就一直处于Discover状态。排查时直接在AC上ping AP管理地址马上就能定位。5.3 配置了本地转发但数据仍在走AC明明服务模板里写了forward-mode local抓包却还是看到CAPWAP封装的数据要检查两点服务模板是否绑定了正确的AP组或AP射频。模板即使已使能如果没绑定AP上就不会创建对应的VAP是否存在多个服务模板同时绑定了同一APAP优先使用了另一个集中转发模板。我在实验时为了测试便利建过两个模板一个local一个tunnel结果AP同时广播两个SSID用户连到了tunnel模板的SSID上误以为配置失效。这个检查方式很直接执行dis wlan ap name ap1 verbose查看该AP所有radio绑定的VAP确认每个VAP的转发模式。注意本地转发模式下VAP的状态字段和集中转发有差异多看几遍再判断别急着改配置。5.4 业务VLAN跨三层时网关位置混乱本地转发如果涉及跨三层漫游问题会复杂很多。最简单的思路是让终端网段的网关部署在核心交换机上所有AP接入交换机都在同一个二层域内这样漫游只需要处理二层问题。如果AP分布在不同的三层网络中业务VLAN需要沿用相同VLAN ID三层漫游时业务报文要从新AP直接到达原网关这时对核心路由的收敛速度要求很高需要配合动态路由协议。实验室里先把二层漫游实验做透对理解核心机制已经很有帮助跨三层可以留到以后做专项验证。6. 从本地转发想到的更多实验方向6.1 本地转发与安全策略的联动本地转发有一个容易被忽略的副作用AC上针对无线用户做的ACL、限速策略如果是作用在隧道数据流上对本地转发用户不生效。想对本地转发用户做基于IP地址和端口的安全策略必须把ACL下到AP或接入交换机上。这一点和“基于IP地址和端口的安全策略配置实验”正好可以组合起来在核心交换机上写ACL限制无线业务网段只能访问内网指定服务器禁止访问其他网段然后通过本地转发把策略执行点下移AC只保留隧道控制面。顺便说一句IPv6 ACL配置也能在这个框架下扩展把VLAN 20的IPv6网段单独规划ACL在交换机上做协议和端口限制思路和IPv4完全一致。6.2 本地转发配合动态路由技术当实验环境有多个网段、核心和汇聚之间存在三层路由时可以配合OSPF动态路由来验证。简单说把核心交换机当作无线业务的网关AC和其他网段都跑OSPF无线用户经由本地转发进入核心后路由由OSPF负责整个网络不再依赖静态路由兜底。如果再深入一点把AC的环回口、防火墙和核心交换机都接入OSPF区域本地转发下的无线用户访问防火墙业务时路径是终端→AP→核心→防火墙AC完全不参与数据面。这也为后面做防火墙HA配置实验打基础因为HA主备切换时业务路径是否平滑切换取决于核心交换机上的路由收敛无线侧只要本地转发稳定影响面就很小。网络规模更大、涉及分支机构互联时BGP4配置实验也可以纳入后续计划本地转发只是数据面问题控制面的路由协议越健壮数据面的本地化优势就越明显。6.3 把“本地化”思路延伸到Linux实验这次实验让我联想到Linux里配置本地yum源的思路。两者有一个共通点把高频、大流量的资源尽量在“本地”解决减少对中心节点的依赖。yum源每次都去外网拉包网络慢不说还容易失败配置了本地源之后关键依赖从本地仓库获取效率高、可控性强。无线本地转发也是同理数据尽量在AP本地出口AC只保留管理面网络的扩展性和健壮性都更好。做实验时多对比这两种“本地化”思路对理解分布式架构的取舍会有帮助。6.4 本地转发的适用场景总结从我自己的测试结果看本地转发最适合的场景有三类一是视频监控这类持续高带宽的数据流集中转发会让AC和隧道链路压力很大二是AP数量多、AC性能有限的办公网络本地转发能大幅降低AC负担三是对时延敏感的业务数据路径短一截时延自然更低。不适合的场景也有比如需要AC对每个用户流量做深度检测审计的场合本地转发模式下AC看不到用户数据想做集中审计必须依赖交换机或额外的流量镜像设备。设计无线网络时不能只看转发模式的优劣还要考虑运营侧的管理需求。7. 实验总结与个人心得7.1 配置链路中最容易忽略的细节回头整理配置记录我发现几条容易忽略但影响很大的细节服务模板的转发模式改动一定要在模板未使能时进行否则VAP反复重建业务VLAN在POE交换机下联口必须放通而且PVID要和AP管理VLAN一致保存配置后先在AC上确认AP状态为R/M再连SSID验证验证数据路径时核心交换机ARP表是判断本地转发是否生效的最好突破口之一。这些细节单独看都不难但串在一起就容易漏。我在实验记录里把这些写成checklist后续再搭无线环境时直接照着过一遍省了不少时间。7.2 本地转发实验后的几点体会配置本身并不复杂命令就那么几条真正花时间的往往是理解“为什么”。我在这个实验里最大的收获是把管理面和数据面的概念从书面上落地了CAPWAP隧道可以是控制通道也可以是数据和控制的混合通道而选择哪种模式取决于你希望AC扮演什么角色。做实验之前建议先用集中转发把AP上线、服务模板、终端接入跑通再切换到本地转发。这样出问题时起码能区分是基础组网问题还是本地转发特有的问题。实验完成后记得把AC、核心交换机、POE交换机的配置、版本、抓包文件都留个快照写记录时真的会用到。最后分享一个小技巧验证本地转发是否生效不需要复杂的工具在AC上打开display wlan client verbose扫一眼Forwarding Mode字段再在核心交换机上查看ARP表里能不能直接看到终端的MAC。这两个信息加在一起基本可以当场判断数据面走向。实验记录做到这个程度后续无论是写文档还是跟同事讨论都会特别有底气。