企业官网建设流程全解析

去年做无线覆盖改造的时候，我被AC集中转发坑得不轻。宿舍区几百个终端全部通过CAPWAP隧道把流量绕回AC再出去，高峰期AC的CPU直接飙到80%以上，上行链路也经常打满，用户投诉断流、卡顿的工单堆了一整屏。当时我就决定做一套无线本地转发实验配置，把无线用户的业务流量从“绕回AC再转发”改成“在AP侧直接转出去”。实验结果比预想的好很多，这篇文章就是那次实验的完整记录。

如果你正在做园区网、宿舍网或者办公网的无线覆盖，又纠结过“流量到底该走AC还是走AP”，这篇记录应该能给你不少参考。我会把实验拓扑、VLAN规划、AC配置、验证方法、踩坑记录全部写出来，尽量保留当时的原始操作，给同样做网络实验的朋友一个可以照着抄的版本。

1. 实验背景：核心问题不在无线信号，而在流量走向

无线网络项目的调试，很多人第一反应是调信号、调功率、调漫游阈值。但实际生产环境里，真正决定用户体验的往往是流量走向，也就是用户数据从AP上去之后，到底走哪条路到达网关和出口。

1.1 集中转发的原理和它带来的问题

集中转发（Central Forwarding）模式下，AP和AC之间建立CAPWAP隧道，无线终端的所有业务报文都会被封装在CAPWAP隧道里，送到AC后再由AC解封装、转发出去。这个模式最大的好处是管理集中：AC能看到所有流量，做ACL控制、流量审计、认证放行都很方便。

但代价也很明显。第一，所有流量都要过AC，AC的CPU和转发性能直接决定整网吞吐上限；第二，如果无线用户分布在多个楼层、多个区域，所有流量都汇聚到AC再绕回汇聚交换机，链路占用和时延都会增加；第三，AC一旦出问题，整张无线网直接瘫痪。

我实验环境里的AC性能不算差，但当时的网络架构是“接入交换机-汇聚交换机-AC”串行，AC挂在汇聚上，用户访问互联网需要走“AP-接入-汇聚-AC-汇聚-防火墙”，等于绕了一个大圈。测试时ping网关的时延偶尔会跳到5ms以上，高峰期丢包率虽然不高，但抖动明显。

1.2 本地转发的目标：把业务流量“就近送走”

本地转发（Local Forwarding）的思路很直接：CAPWAP隧道只承载管理报文和控制报文，无线终端的业务数据由AP直接转发给上层交换机，走正常的二层/三层网络到达网关。这样AC只负责AP的管理、配置下发和漫游协调，不承担业务流量转发，压力瞬间小了很多。

不过本地转发并不是“省事”，而是“换了一类麻烦”：AC不再能看到业务流量，ACL、限速、审计策略的位置都得调整。这正是我想通过实验验证的核心点——转为本地转发之后，无线功能是否正常、数据走向是否符合预期、需要修改哪些配置才能让策略继续生效。

2. 实验拓扑与VLAN规划：先把数据流向想清楚

做实验前我习惯先画拓扑、定VLAN，想清楚每一个报文应该怎么走。这一步偷懒，后面配置必然翻车。

2.1 设备清单与角色分工

实验用了四类设备：AC、汇聚交换机、POE接入交换机、AP，外加一台笔记本当无线终端。设备选型参考的是新华三的典型组合，具体型号如下：

AC挂在汇聚交换机上，AP挂在接入交换机上，接入交换机再上行到汇聚交换机。流量路径可以理解为：终端-AP-接入交换机-汇聚交换机-网关/出口。整个实验的关键就是让“终端-AP-接入交换机”这一段承载业务VLAN，而不是把业务流量塞回AC。

2.2 VLAN与IP地址规划

本地转发的VLAN规划比集中转发多一个心眼：必须把“AP管理VLAN”和“终端业务VLAN”分开，而且业务VLAN要能从接入交换机一路放行到网关所在设备。

我规划了两个VLAN：

这里有个细节：集中转发模式下，业务VLAN的网关可以放在AC上；但本地转发模式下，业务VLAN的网关最好放在汇聚交换机上，甚至直接放在核心交换机的三层接口上。因为本地转发后流量不经过AC，网关放在AC上是没有意义的。我的实验里把VLAN 200的网关放在了汇聚交换机上，AC上只保留VLAN 100的地址作为管理地址。

2.3 链路类型：trunk放行哪些VLAN决定实验成败

规划好VLAN之后，还要明确每一段链路上的放行策略。我的做法是：

• AC上联汇聚交换机：trunk放行VLAN 100和VLAN 200，PVID保持默认1；
• 汇聚下行接入交换机：trunk放行VLAN 100和VLAN 200；
• 接入交换机上联汇聚：trunk放行VLAN 100和VLAN 200；
• 接入交换机接AP的口：trunk放行VLAN 100和VLAN 200，PVID设置成VLAN 100。

最后一条特别重要。AP上电后要获取管理地址，所以AP上联口的PVID必须是管理VLAN；同时AP在本地转发模式下要把终端的数据报文打上VLAN 200的标签发出去，所以trunk必须放行VLAN 200。我第一次做实验时把AP口配成了access模式，只放行VLAN 100，结果AP能上线，终端死活拿不到地址。这个坑后面单独说。

3. AC侧配置：先跑通集中转发，再切到本地转发

我的实验策略不是一上来就配本地转发，而是先把集中转发跑通，确认AP能正常上线、终端能拿到地址，再把转发模式切成本地。这样每一步出现问题时，能快速判断是无线基础的问题还是转发模式的问题。

3.1 基础配置：DHCP、VLAN接口和CAPWAP源地址

AC上的基础配置包括VLAN、VLAN三层接口、DHCP地址池，以及CAPWAP源接口。地址池分两个：一个给AP管理地址，一个给无线终端业务地址。

# 创建VLAN和三层接口 system-view vlan 100 vlan 200 interface vlan-interface 100 ip address 10.10.100.1 255.255.255.0 quit interface vlan-interface 200 ip address 10.10.200.1 255.255.255.0 quit # DHCP地址池 dhcp server ip-pool pool-ap network 10.10.100.0 mask 255.255.255.0 gateway-list 10.10.100.1 quit dhcp server ip-pool pool-client network 10.10.200.0 mask 255.255.255.0 gateway-list 10.10.200.1 quit # 指定CAPWAP源接口，AP通过VLAN 100找到AC capwap source interface vlan-interface 100

注意，AC上VLAN 200的网关地址我可以先配着，因为集中转发模式下终端网关放在AC上也行。后期切到本地转发时，我会把这个三层接口停掉，把网关迁移到汇聚交换机，避免出现两个网关抢答的问题。

3.2 无线服务模板：集中转发的完整配置

接下来配置无线服务模板。服务模板是AC下发无线参数的核心对象，SSID、绑定的VLAN、转发模式都在这里控制。

# 创建无线服务模板 wlan service-template 1 ssid Lab-Local client forwarding-location ac vlan 200 service-template enable quit

client forwarding-location ac就是集中转发模式，这也是很多AC的默认值。此时AP上线后，终端关联SSID，数据报文全部封装进CAPWAP隧道送到AC，由AC转发到VLAN 200的网关。

然后配置AP上线和射频绑定。

# 创建AP组（实验里用默认组） wlan ap-group default-group # 注册AP并绑定射频 wlan ap ap1 model WA6320 ap1 radio 1 radio enable service-template 1 quit radio 2 radio enable service-template 1

配置完成后，在AC上执行display wlan ap all，看到AP状态为R/M（正常运行），终端关联后能获取到10.10.200.x的地址，说明基础无线链路没问题。我没有急着验证时延，因为接下来要切本地转发。

3.3 把转发模式切到本地：只有一条命令，但影响不小

切换的关键配置在无线服务模板里，把集中转发改成本地转发：

wlan service-template 1 client forwarding-location ap quit

就这么一条命令。client forwarding-location ap表示业务数据由AP直接转发，CAPWAP隧道只跑管理报文。

但这条命令执行后，AC会通知所有关联这个服务模板的AP更新配置，在线终端会全部掉线重连。这不是故障，是正常的配置下发行为，实验时不要以为设备出问题了。

切完之后，终端重新关联SSID，获取到的地址应该还是10.10.200.x，但流量走向已经完全不同：终端的报文由AP直接发出，打上VLAN 200的标签，经接入交换机、汇聚交换机到达网关，全程不经过AC。

同时在汇聚交换机上配置VLAN 200的网关：

system-view interface vlan-interface 200 ip address 10.10.200.1 255.255.255.0 quit

然后停掉AC上VLAN 200的三层接口，避免双网关冲突：

interface vlan-interface 200 undo ip address shutdown quit

这里要特别提醒：如果你不想让AC彻底退出数据链路，也可以保留AC上的三层接口，但一定要保证终端网关和DHCP地址池指向同一个设备，不然地址分配和回程路由很容易出问题。

4. 验证本地转发是否生效：三层证据链

配置切完，不能只看AP还在线就说本地转发成功。我用了三层验证手段：命令行查看、抓包分析、时延和吞吐测试。三层证据都指向同一个结论，才能完全放心。

4.1 命令行确认：客户端转发模式显示为local

在AC上使用以下命令查看无线客户端的详细信息：

display wlan client verbose

重点关注输出里的Forwarding mode字段。集中转发模式下，这个字段显示为central；切换到本地转发后，显示为local。如果切完配置后这里仍然是central，说明AP没有接收到新的服务模板配置，需要检查AP状态和配置下发情况。

另外还可以在接入交换机上观察MAC地址表，看看终端的MAC地址是出现在AP上联口还是出现在AC上联口。本地转发模式下，终端的MAC一定会出现在AP所在的接入交换机端口上，这是很直观的证据。

4.2 抓包验证：数据包是否还有CAPWAP封装

命令行看的还是“设备自己怎么认为”，抓包才能看到真实报文走向。我在接入交换机上做了端口镜像，把AP上联口的流量镜像到一台抓包主机，然后让终端去ping网关地址。

结果非常清晰：

• 集中转发模式下，抓到的终端ICMP请求报文外层有CAPWAP封装，外层目的IP是AC的管理地址；
• 本地转发模式下，抓到的报文就是普通的以太网帧，VLAN标签是200，目的MAC是网关的MAC，完全没有CAPWAP封装。

看到第二个结果的时候，我基本可以确认本地转发真的生效了。因为如果流量还在AC绕，接入交换机上是不会看到这种“裸报文”的。

4.3 实测数据：时延降了，吞吐涨了

我用两种模式分别做了测试，测试终端一台、干扰变量尽量控制住。结果如下：

本地转发模式下的时延下降非常明显，接近有线网络的表现。吞吐提升主要来自两点：一是流量不再经过AC多一次封装解封装，二是AC的CPU负载大幅下降，不再成为瓶颈。

测试时我特意观察了AC的CPU。集中转发模式下，终端跑iperf时AC的CPU可以到40%上下；切到本地转发后，同样的压力下AC的CPU基本稳定在8%以内。这个数字说明AC的管理面压力和数据面压力被彻底分开了。

5. 本地转发实验踩坑实录：排查链路与修复

实验不是一次顺利做完的。我在过程中踩了三个比较典型的坑，每一个都值得单独记录，特别是排查链路，比最终配置更有参考价值。

5.1 AP反复掉线：CAPWAP源地址和PVID不对

问题现象：AP上电后能上线，但过几分钟就掉线，然后又上线，反反复复。

排查链路是这样的：先看AC上的AP状态和掉线原因记录，用display wlan ap all看到AP的State在Idle和R/M之间反复切换；然后确认AC到AP之间管理VLAN的连通性，在AC上ping AP的管理地址能通，但丢包严重。最后定位到接入交换机接AP的口，发现这个口虽然配了trunk并放行VLAN 100，但PVID不是VLAN 100，导致AP发出的DHCP Discover报文虽然在VLAN 100里，但交换机把不带标签的管理报文按PVID处理，出现了管理流量错乱。把PVID改成VLAN 100之后，AP稳定上线，再无反复掉线。

这个坑的本质是：trunk口放行某个VLAN，只代表允许带该VLAN标签的报文通过；PVID才是决定“收到的无标签报文属于哪个VLAN”的关键。AP在拿到管理地址之前发出的报文是不带标签的，所以PVID必须指向管理VLAN。

5.2 终端获取不到业务地址：业务VLAN没有一路放行

问题现象：切换到本地转发后，终端关联SSID成功，但无法获取到10.10.200.x的地址，手动配置IP也不能上网，ping业务VLAN网关不通。

排查链路：先在接入交换机上看终端MAC是否出现在AP上联口，结果没有；然后在AP上联口抓包，看到终端DHCP Discover没有到达交换机；再查接入交换机配置，发现接AP的口虽然PVID改成了VLAN 100，但trunk只放行了VLAN 100，忘放行VLAN 200。这样一来，AP发出的带VLAN 200标签的报文直接被交换机丢弃，终端自然什么都得不到。

修复方法很简单，在AP上联口补上VLAN 200的放行：

interface GigabitEthernet1/0/24 port link-type trunk port trunk permit vlan 100 200 port trunk pvid vlan 100

这个小错误我犯过一次之后，凡是做本地转发实验，我都会把“AP上联口trunk放行管理VLAN和业务VLAN”写在规划表里，逐个链路检查。

5.3 切了本地转发却不生效：服务模板没有重新下发

问题现象：配置了client forwarding-location ap，在AC上也看到服务模板已经是本地转发，但终端重新关联后，VLAN还是能通，抓包却发现流量依然走了CAPWAP隧道。

排查链路：先在AC上执行display wireless service-template 1，显示转发模式已经切换；再查看在线客户端，发现Forwarding mode还是central；最后确认AP状态，发现这台AP没有重新注册，服务模板的配置没有下发完整。重启AP射频并让终端重新关联之后，转发模式才变成local。

这个坑给我最大的教训是：AC上改配置不等于AP上执行配置。AP的配置更新依赖CAPWAP隧道中的配置同步，有些参数修改不会立即触发全部AP重新加载，必要时要主动重启AP射频或让终端重新关联，甚至在AP组视图下手动下发配置。

6. 复盘：几条值得写进项目笔记的经验

实验做完后，我整理了五条经验，现在每次做无线网络项目都会先过一遍。

第一，做本地转发前一定把管理VLAN和业务VLAN分开，并且提前规划好每个链路口的PVID和trunk放行列表，不要等到配置时再临时想。本地转发的难点不在AC，而在交换机链路配置上。

第二，业务VLAN的网关要放在转发路径上真正会经过的设备。本地转发模式下，网关放在AC上是个常见错误，会导致终端报文能上去，但回程路由绕路，甚至不通。

第三，ACL、认证、限速策略的位置要跟着转发模式走。集中转发时这些策略可以放在AC上；本地转发时，策略必须下放到接入交换机或汇聚交换机，否则业务流量根本不经过AC，AC上的过滤规则形同虚设。我在实验后期做了一个简单验证：在AC上配置一个针对VLAN 200的ACL，集中转发时能过滤，切到本地转发后就完全不生效。

第四，切换转发模式前，提前告知测试终端会短暂断网。服务模板改动导致AP重新下发配置，在线终端会全部掉线重连，这在生产环境里属于影响业务的变更操作，必须走变更窗口。

第五，验证不能只看配置，要看报文走向。命令行显示local不代表流量真的local，抓包看到没有CAPWAP封装才算数。

最后再分享一个小技巧：每次做这类转发模式实验，我都会在换模式前后各保存一份配置文件和抓包结果，用文件名区分版本。这样出了诡异问题，可以快速对比是不是哪个配置被AC自动改回去了。无线实验虽然原理不复杂，但链路环节多，留证据比记性好用得多。