企业官网建设流程全解析

1. 实验背景：为什么我盯上了“无线本地转发”

这阵子把无线本地转发实验配置完整跑了一遍，趁着实验室里控制器和瘦AP都闲着，把整套流程从拓扑规划、设备配置、流量验证到排错记录成一篇可复现的笔记。网络这行干久了会产生一个很直观的感受：WLAN里最容易被“想当然”的就是数据转发路径。大部分人做无线项目时，AP上线、SSID配好、能上网就认为完事了，很少会去追问一句——终端这些业务流量到底从哪里走？控制器会不会变成瓶颈？漫游时路径又是怎么变的？

这篇记录适合三类人看：一是正在准备WLAN相关实验、想把“本地转发”这个概念从文档落到命令行的朋友；二是单位无线网络总感觉慢、想搞明白是不是控制器在“卡脖子”的运维同行；三是刚开始接触瘦AP架构、对集中转发和本地转发还比较模糊的新手。我会按实验的真实推进顺序讲，先交代为什么选本地转发，再给完整配置，最后把验证方法和踩过的坑全部摆出来。整个过程基于H3C的AC+FIT 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上联核心，下联AP；AP的上行口接在接入交换机上，无线终端关联AP。这里有个重要的设计选择：AC旁挂，而不是串在数据通路上。旁挂意味着AC只在管理平面出现，业务流量不经过它，这与本地转发的思路天然一致。

VLAN规划上，我分了两个VLAN，这是本地转发实验中最重要的规划动作：

为什么必须分成两个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.8

Option 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要设成管理VLAN：

interface 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，那管理报文就进了错误VLAN，AC自然发现不了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-interface10

AP上线有两种方式：一种是让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 quit

forwarding-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 20，PVID是否仍是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或者安全策略实验时，这套本地转发的无线底座可以直接复用，省去重新搭建基础网络的功夫，也算这次实验意外的长期回报。