简介：这份《智简园区WLAN二层GRE技术白皮书》面向固网运营商网络规划与运维人员、WLAN解决方案工程师及通信专业学习者，聚焦固网运营商在移动化与物联网趋势下如何借助Wi-Fi拓展业务、避免被管道化这一核心问题。白皮书系统梳理二层GRE技术的产生背景、实现原理与典型组网应用，涵盖EoGRE+隧道转发与SoftGRE两种转发方式，并深入讲解报文转发、用户认证、SoftGRE与EoGRE+隧道转发下的漫游机制，以及宽带+Wi-Fi融合、Wholesale批发、访客接入三类业务场景，帮助读者理解无线流量如何统一汇聚至现有BRAS网关、复用现网资源平滑演进。资源为1个PDF文件，压缩包约894KB，篇幅精炼、目录结构清晰，便于按章节检索查阅。目前已有115人学习，适合需要掌握运营级Wi-Fi二层GRE方案设计与漫游优化的技术人员参考。
1. 为什么固网运营商死磕 WLAN 二层 GRE：一份白皮书拆出来的真实价值
固网宽带增速见顶这件事，做接入网的人比谁都清楚。用户不再关心你家宽带是 100M 还是 500M，他们关心的是"我在客厅、在卧室、在楼下咖啡厅，能不能用同一个账号无感接入"。华为这份《智简园区 WLAN 二层 GRE 技术白皮书》讲的正是这件事——怎么在不推翻现有 BRAS、AAA、城域资源的前提下，把无线用户流量直接甩到现有网关上去认证计费，AC 只当接入控制器。
说白了，它解决的是一个很具体的工程矛盾：无线用户要漫游、要统一认证、要 QoS，但运营商又不想为 WLAN 单独建一套核心。二层 GRE 就是那个"缝合怪"——用 GRE 隧道把以太帧封进 IP 里跑，让无线流量在现网里"假装"是有线流量。适合谁看？做园区 WLAN 规划的、做运营商接入网改造的、以及被 SoftGRE 和 EoGRE 两种模式搞混过的工程师。下面我按"原理→配置→踩坑→验证"的顺序，把这份白皮书里能落地的部分拆开讲。
2. 二层 GRE 的封装原理与两种转发模式选型
2.1 GRE 与二层 GRE 的本质区别
普通 GRE 隧道里跑的是 IP 报文或 MPLS 报文，隧道两端是三层设备，本质是"IP in IP"。二层 GRE 不一样，它承载的是完整的以太帧，GRE 头里的 Protocol Type 字段填的是0x6558，也就是 Transparent Ethernet Bridge。这意味着隧道两端看到的是对方的 MAC 地址，而不是路由下一跳。
白皮书里给了一张 SoftGRE 隧道封装图，我把它拆成字段来看更清楚：
| 封装层次 | 字段 | 取值来源 |
|---|---|---|
| 外层 ETH Header | 源 MAC | VAP 对应的 BSSID |
| 外层 ETH Header | 目的 MAC | IP 下一跳的 MAC |
| 外层 VLAN | VLAN ID | AP 的管理 VLAN |
| 外层 IP Header | 源 IP | 隧道源设备 IP（AP 或 AC） |
| 外层 IP Header | 目的 IP | 隧道目的设备 IP（网关） |
| GRE Header | Protocol Type | 0x6558 |
| GRE Header | Flags | 全 0，Option 不保留 |
| 内层 ETH Header | 源 MAC | STA 的 MAC |
| 内层 ETH Header | 目的 MAC | 网关的 MAC |
| 内层 VLAN | VLAN ID | 用户业务 VLAN |
| 内层 IP Header | 源 IP | STA 的 IP |
| 内层 IP Header | 目的 IP | 用户访问的目的地址 |
这张表是排障的命根子。隧道不通的时候，先抓包看外层 IP 通不通，再看 GRE Protocol Type 是不是 0x6558，最后看内层 VLAN 有没有打对。三层排查顺序，一步都不能跳。
2.2 SoftGRE 与 EoGRE+隧道转发的选型逻辑
白皮书给了两种实现方式，很多人第一次看会懵——都是二层 GRE，到底选哪个？
SoftGRE 方式：AP 直接和网关建隧道。控制报文走 CAPWAP 上 AC，用户流量走 SoftGRE 隧道直接到网关。这种模式的好处是流量路径短，AP 到网关一跳直达，AC 不承担流量转发压力。坏处是 AP 要支持 SoftGRE 封装，对 AP 性能有要求，而且漫游范围受限——白皮书明确写了"只支持无线用户在同一个 WIFI 网关内的二层漫游"。
EoGRE+隧道转发方式：AP 先把流量通过 CAPWAP 隧道送到 AC，AC 再通过 EoGRE 隧道送到网关。这种模式对 AP 要求低，漫游处理跟传统隧道转发完全一致，AC 间漫游也好做。代价是流量绕了一圈 AC，AC 的转发压力大。
选型建议很直接：新建网络、AP 型号较新、漫游范围小，选 SoftGRE；存量 AP 多、需要跨 AC 漫游、AC 性能富余，选 EoGRE+隧道转发。白皮书里没有明说但实际工程中必须考虑的一点是——SoftGRE 模式下 AC 不转发用户流量，如果 AC 本身还兼做其他业务，SoftGRE 能省不少 CPU。
2.3 Keepalive 检测的参数配置与单向性陷阱
二层 GRE 协议本身不探测链路状态，对端挂了发送端不知道，会继续往黑洞里灌报文。白皮书里 Keepalive 检测这部分写得比较细，我把它翻译成可操作的配置逻辑。
Keepalive 的工作机制是：使能后，设备周期性发送 Keepalive 报文，每发一个不可达计数器加 1，如果计数器达到retry-times还没收到回应，就认为对端不可达，关闭隧道连接。
两个关键参数：
period：发送 Keepalive 的周期，默认 5 秒retry-times：不可达次数阈值，默认 3 次
按默认值算，最坏情况下 15 秒才能感知到隧道断开。如果业务对中断敏感，可以把 period 调到 1 秒、retry-times 调到 3 次，3 秒感知。但 period 调太小会增加协议报文开销，一般园区场景 2~3 秒比较均衡。
注意：白皮书特别强调 Keepalive 是单向的。A 端使能了，B 端没使能，A 能检测 B，但 B 检测不了 A。实际部署时两端都要配，别只配一头。
2.4 优先级映射：UP、DSCP、802.1p 三者的转换关系
SoftGRE 模式下支持空口报文和隧道报文的优先级映射，这块是 QoS 落地最容易翻车的地方。白皮书列了四种映射方向，我用一张表整理清楚：
| 方向 | 映射类型 | 说明 |
|---|---|---|
| 上行 | 802.11 UP → 外层 IP DSCP | STA 报文的 UP 映射到隧道外层 DSCP |
| 上行 | 802.11 DSCP → 外层 IP DSCP | STA 报文的 DSCP 映射到隧道外层 DSCP |
| 下行 | 外层 IP DSCP → 802.11 UP | 隧道外层 DSCP 映射到空口 UP |
| 下行 | 802.3 802.1p → 802.11 UP | 有线侧 802.1p 映射到空口 UP |
WMM 定义了四种接入类别，UP 值和 AC 的对应关系是：UP 1/2 → AC_BK（背景），UP 0/3 → AC_BE（尽力而为），UP 4/5 → AC_VI（视频），UP 6/7 → AC_VO（语音）。配置映射策略时，语音业务 UP 6/7 要映射到高 DSCP（如 EF），视频 UP 4/5 映射到 AF41，这样才能保证有线侧调度时语音优先。
3. 二层 GRE 下的报文转发、认证与漫游实操
3.1 控制报文与用户报文的分离转发
二层 GRE 方案的核心设计思想是控制与转发分离。控制报文走 CAPWAP 上 AC，用户报文走二层 GRE 隧道上网关。白皮书把控制报文分了三类：
- AC 对 AP 的配置管理、监控、控制信息
- 用户关联管理报文：Association request/response、Reassociation、Disassociation、Authentication、Deauthentication
- AP 测量和统计信息
用户报文就是 DHCP、DNS、访问 Internet 的数据报文。这个分离逻辑决定了排障时的抓包位置——用户上不了网但能连上 SSID，说明 CAPWAP 通但二层 GRE 不通；连 SSID 都连不上，说明 CAPWAP 就有问题。
在 SoftGRE 转发模式下，认证报文有个特殊处理：用户发送的认证报文可以根据配置决定是否通过 CAPWAP 上 AC 处理。这意味着如果认证点在 AC 上，认证报文走 CAPWAP；如果认证点在网关上，认证报文走二层 GRE 隧道。配置时要想清楚认证点在哪，别配混了。
3.2 用户认证方式的组合矩阵
白皮书给了一张认证方式支持表，我把它整理成更直观的对比：
| 认证方式 | AC 上认证 | 网关认证 |
|---|---|---|
| MAC | 支持（DHCP 或其他首包经 CAPWAP 上 AC 触发） | 支持 |
| Portal | 支持（http/https 报文经 CAPWAP 上 AC 触发） | 支持 |
| 802.1x | 支持（EAP 报文经 CAPWAP 上 AC 触发） | 不支持 |
| WAPI | 支持（WAPI 协议报文经 CAPWAP 上 AC 触发） | 不支持 |
这张表直接决定了方案选型。如果运营商要求 802.1x 或 WAPI 认证，认证点必须放在 AC 上，网关不支持这两种。如果只需要 MAC 或 Portal 认证，认证点可以放在网关上，利用现有 BRAS 的认证体系。
实际部署中常见的做法是：AC 上做 802.1x 认证保证接入安全，网关侧做 Portal 认证做二次授权和计费。两层认证叠加，既安全又能复用现有计费系统。
3.3 SoftGRE 与 EoGRE 漫游流程的差异
漫游是 WLAN 最玄学的部分，二层 GRE 下的漫游又分两种模式。
SoftGRE 方式下的漫游：用户数据本身就是通过 SoftGRE 隧道直接上网关，不管二层漫游还是三层漫游，数据报文都是在 AP 上进隧道。但白皮书明确限制——只支持同一个 WIFI 网关内的二层漫游。跨 AC 漫游时，AC 之间需要建立 CAPWAP 隧道同步用户信息。如果认证点在 AC 上，AC 还要把用户策略下发到新 AP。
EoGRE+隧道转发方式下的漫游：漫游处理跟传统隧道转发完全一致，区别只在上行链路用 EoGRE。AC 内漫游时，FAP 通过 CAPWAP 隧道把报文送到 AC，AC 通过 EoGRE 隧道送到网关。AC 间漫游时，二层漫游 FAC 直接通过 FAC 与网关之间的隧道送到网关；三层漫游 FAC 通过漫游隧道把流量导回 HAC，HAC 再通过 EoGRE 送到网关。
两种模式的漫游差异总结成一句话：SoftGRE 漫游范围受网关限制，EoGRE 漫游范围受 AC 间隧道限制。规划时先确定漫游域有多大，再倒推选哪种模式。
3.4 典型组网场景的配置要点
白皮书给了三个典型场景，我补充一些配置层面的落地建议。
宽带+WIFI 业务：一个账号同时享受家庭宽带和热点 WIFI。配置要点是 SSID 对应的业务 VLAN 要和宽带用户的 VLAN 规划一致，这样网关才能识别为同一个用户。认证报文走 CAPWAP 上 AC 做 Portal 认证，认证通过后用户流量走二层 GRE 隧道到 BRAS。
Wholesale 业务：按 SSID 或域名转售给其他运营商。配置要点是不同 SSID 映射不同内层 VLAN，网关侧根据 VLAN 区分不同转售商。白皮书提到 BT-FON 模式，实际配置时要注意不同转售商的地址池要隔离，避免 IP 冲突。
访客接入：访客流量全部导入 EoGRE 隧道导出到安全区。配置要点是访客 SSID 单独规划 VLAN，EoGRE 隧道的目的地址指向安全区网关，AC 上配置策略禁止访客 VLAN 访问内部资源。
4. 二层 GRE 部署避坑：五条血泪经验
4.1 隧道通了但用户上不了网
现象：AP 和网关之间能 ping 通，隧道状态显示 up，但 STA 获取不到 IP 地址。
原因：外层 IP 通不代表内层 VLAN 通。常见情况是内层 VLAN 在网关侧没有创建，或者网关侧接口没有放通该 VLAN。另一个可能是 DHCP 报文被 CAPWAP 隧道截走了——如果配置了认证报文走 CAPWAP，DHCP 首包可能被送到 AC 而不是走二层 GRE 隧道。
解决：先在网关侧确认内层 VLAN 已创建且接口放通。然后抓包确认 DHCP 报文走的是哪条路径。如果走错了，检查认证报文转发配置，确保 DHCP 报文走二层 GRE 隧道。
4.2 Keepalive 两端配置不一致导致隧道震荡
现象：隧道频繁 up/down，日志里 Keepalive 超时告警反复出现。
原因：Keepalive 是单向的，一端配了另一端没配，或者两端 period 和 retry-times 不一致。一端认为对端可达，另一端认为不可达，状态机对不上。
解决：两端都使能 Keepalive，period 和 retry-times 配成相同值。建议 period 2~3 秒，retry-times 3 次。
4.3 漫游后用户 IP 不变但业务中断
现象：STA 从 AP1 漫游到 AP2，IP 地址没变，但 ping 不通网关。
原因：SoftGRE 模式下跨网关漫游不支持，用户漫游到了另一个网关的覆盖范围，但隧道还指向原网关。或者 EoGRE 模式下 AC 间漫游隧道没建好，流量回不到 HAC。
解决：确认漫游范围是否超出设计边界。SoftGRE 只支持同一网关内二层漫游，跨网关必须换 EoGRE 模式。EoGRE 模式下检查 AC 间漫游隧道状态和 HAC 的 EoGRE 隧道状态。
4.4 QoS 映射不生效导致语音卡顿
现象：语音业务在空口侧优先级正常，但过了隧道后 DSCP 变成 0，有线侧调度时和普通数据一样。
原因：上行 UP 到 DSCP 的映射没配置，或者映射表配错了。默认情况下隧道外层 DSCP 可能继承内层或置 0。
解决：在 AP 上配置 802.11 UP 到外层 IP DSCP 的映射表，确保 UP 6/7 映射到 EF，UP 4/5 映射到 AF41。配置后在网关侧抓包验证外层 DSCP 值。
4.5 认证报文路径混乱导致认证失败
现象：Portal 认证页面弹不出来，或者认证通过后立即掉线。
原因：认证报文该走 CAPWAP 的走了二层 GRE，该走二层 GRE 的走了 CAPWAP。SoftGRE 模式下认证报文路径是可配的，配错了认证流程就断了。
解决：明确认证点位置。认证点在 AC 上，认证报文走 CAPWAP；认证点在网关上，认证报文走二层 GRE。配置后抓包确认认证报文路径，Portal 认证重点看 http/https 报文，802.1x 重点看 EAP 报文。
5. 用抓包和计数器验证二层 GRE 隧道健康度
隧道配完了不代表配对了。我一般会走一遍验证流程，确保隧道真的在干活。
第一步：看隧道状态和 Keepalive 计数器
在 AC 或 AP 上执行display gre tunnel interface类似的命令（不同设备命令有差异），确认隧道状态是 up，Keepalive 的发送和接收计数器都在增长。如果发送在涨接收不涨，说明对端没回 Keepalive，检查对端是否使能。
第二步：抓包验证封装格式
在隧道两端抓包，过滤 GRE 协议。正常的二层 GRE 报文，GRE 头的 Protocol Type 应该是 0x6558。如果看到的是 0x0800，说明封的是 IP 报文不是以太帧，配置模式错了。
# 在网关侧抓包，过滤 GRE 报文 tcpdump -i any -nn -vv gre # 输出中关注 Protocol Type 字段 # 期望看到：gre-proto-0x6558 (Transparent Ethernet Bridge)第三步：验证内层 VLAN 和 MAC
抓包看内层以太帧的 VLAN 和 MAC。内层源 MAC 应该是 STA 的 MAC，目的 MAC 是网关的 MAC。内层 VLAN 应该是业务 VLAN。如果内层 VLAN 是 0 或者不对，检查 AP 上的 VLAN 配置。
第四步：验证 QoS 映射
发一个语音报文，在网关侧抓包看外层 IP 的 DSCP 值。期望 UP 6/7 的报文外层 DSCP 是 EF（0x2E）。如果 DSCP 是 0，检查映射表配置。
第五步：漫游验证
让 STA 在两个 AP 之间漫游，持续 ping 网关。观察丢包情况。二层漫游应该只有 1~2 个丢包，三层漫游可能多一些。如果漫游后完全不通，检查漫游隧道和用户信息同步。
从那以后我每次配完二层 GRE，都强制走一遍这五步验证，尤其是抓包看 Protocol Type 这一步——看起来最基础，但翻车往往就翻在这里。希望帮到你。
本文还有配套的精品资源，点击获取
