智简园区WLAN二层GRE隧道：原理、配置与排错实战

简介：《智简园区WLAN二层GRE技术白皮书》是华为面向固网运营商推出的技术方案解析文档，聚焦借助WIFI扩展二层服务、降低被边缘化风险的组网需求。内容系统讲述技术产生背景、二层GRE的基本原理与报文转发流程，重点对比SoftGRE与EoGRE+隧道转发两种实现方式，涵盖用户认证、跨VLAN漫游优化，并针对宽带+WIFI融合、Wholesale批发业务和访客接入等典型场景给出组网思路。资源为1个PDF文件，大小894KB，适合网络解决方案架构师、运营商技术工程师及无线网络学习者参考。目前已有115人学习下载。读者可从中理解二层GRE如何在不改动现网架构的前提下，将无线用户流量汇聚到BRAS网关，同时掌握SoftGRE下保持IP不变减少中断、EoGRE+隧道转发下动态调整隧道保障服务质量等关键细节，对园区WLAN方案选型、平滑演进网络与降低投资成本有直接参考价值。

1. 智简园区WLAN里的二层GRE：它把漫游用户“粘”在同一个二层域里

园区无线网络规模一大，AC和AP之间的转发关系就成了绕不开的坎。很多项目实施中，直连转发让漫游切换快，但策略控制散；集中转发让控制集中，却容易把广播和未知单播都塞进隧道。智简园区方案里，二层GRE是一种折中：AP把收到的以太网帧原样封装进GRE隧道，转发到AC或锚点网关，由统一网关完成VLAN终结和漫游锚定。它不改变用户IP，也不要求所有设备理解CAPWAP，只要三层可达就能隧道化。这篇文章从一个一线交付工程师的视角，拆解二层GRE的报文原理、落地配置和调试方法。适合正在做智简园区WLAN交付、维护无线网络，或者想自己用Linux验证L2GRE行为的工程师。白皮书画的是理想拓扑，这里讲的是一台台设备上能敲出来的命令和踩过的坑。

2. 二层GRE在WLAN场景中的定位：为什么它比CAPWAP和VXLAN更“轻”

2.1 二层GRE的报文结构：以太网帧原样进隧道

二层GRE，也叫Transparent GRE或gretap，核心特征是净荷是完整的二层以太网帧。无线终端发来的报文，AP或接入设备拿到的是带源MAC、目的MAC的802.3帧，不拆到IP层，直接添加GRE头，再添加外层IP头和外层以太网头，发往隧道对端。报文层次从外到内是这样：

外层以太网头 | 外层IP头 | GRE头 | 原始以太网帧（含用户VLAN Tag）

GRE头里最关键的是“协议类型”字段。对于二层GRE，它填的是0x6558，表示后面的净荷是透明以太网桥接帧。这个值在抓包里很容易识别，也是判断隧道封装对不对的第一依据。有些设备也用0x6559表示Ethernet帧，但最通用的是0x6558。

理解报文结构后，几个工程结论就自然出来了。隧道对端能看到用户原始VLAN Tag，所以可以在远端做灵活的二层转发；中间设备只看外层IP头，所以二层GRE可以跨三层网络；GRE头没有加密，所以它承载的是可信任园区内网的业务，而不是替代加密隧道。

对WLAN场景来说，还有一层关键含义：AP在隧道口眼中就是一块“透明网桥”。终端DHCP请求、ARP、广播都能原样穿过隧道，到达AC侧的业务网关。这正好契合智简园区“有线无线一张网”的诉求，用户在AP之间漫游时，业务网关看到的MAC表项不需要重新学习，减少了漫游切换引起的中断时长。

2.2 为什么智简园区WLAN偏好二层GRE，而不是CAPWAP数据隧道或VXLAN

CAPWAP是WLAN管理中常用的控制协议，但它同时承载控制和数据时，AC的转发压力很大。CAPWAP报文格式复杂，中间设备想介入排查也比较麻烦。很多智简园区组网改成了“CAPWAP做管理，业务数据走独立隧道”的方式。独立隧道如果走VXLAN，需要引入VNI、UDP端口和VTEP概念，对AP这种轻量节点来说有点重；而且VXLAN通常要和分布式网关、EVPN配合才能发挥价值，仅在无线接入侧使用属于杀鸡用牛刀。

二层GRE只需要一对源IP、目的IP和一个GRE Key就能建立，配置量小，抓包直观，适合AP-AC、AC-AC这类一对一隧道。还有一层原因：二层GRE是标准协议，容易在有线无线融合的交换机、网关、AC之间打通。园区里一台接入交换机如果想镜像或介入无线流量，不需要理解CAPWAP，只需要识别GRE即可。这和“智简园区”强调的开放架构比较贴合。

VXLAN当然也能在WLAN场景承载业务，它的优势是大规模Overlay和虚拟网络隔离。但园区无线通常只需要把用户流量从AP送到一个集中锚点，二层GRE已经够用。如果同时维护很多园区，每个园区或每类业务需要独立网络域，那时再引入VXLAN不迟。选型时不要看协议“新不新”，要看转发目的地的数量。终点少，GRE；终点多且需要大规模隔离，VXLAN。

2.3 二层GRE在智简园区里的三个典型角色

第一个角色是AP到AC的业务隧道。终端接入后，用户报文从AP发出，通过二层GRE直接送到AC终结业务VLAN。这个模式下AC成为所有无线用户的二层网关，策略下发、安全过滤都能集中在AC上做。

第二个角色是AC到AC的漫游隧道。终端从一个AC漫游到另一个AC时，原AC通过二层GRE把报文转发到新AC，保证用户IP不变、网关不用切换。如果没有这条隧道，漫游后用户流量会从新AC绕回原AC，再返回接入侧，路径长且依赖AC间三层路由可用。

第三个角色是有线无线互通。有些园区要求无线用户和有线用户处于同一广播域，二层GRE可以把AP侧的二层域延伸到汇聚交换机，省去每台AP单独做VLAN配置。此时AP更像远端接入板卡，AC或汇聚交换机像集中接口板。

这三个角色对应着不同的配置位置，但隧道本身只有源、目的、Key、桥接关系四个要素。理解了这一点，后面配置就不慌。很多工程师一看到“二层GRE”就往IPsec上联想，实际上它没有认证和加密，定位是“隧道化二层帧”，不是“安全隧道”。

3. 用最小环境跑通二层GRE：从Linux gretap到智简园区AC的落地

3.1 最小实验拓扑与地址规划

不用实物设备，在你电脑上用两台Linux虚拟机就能把二层GRE行为跑明白。一台模拟AP侧接入节点，一台模拟AC侧集中网关，中间用一条三层IP链路连通。这个环境对新手友好，适合验证本系列所讲的MTU、抓包、桥接特性。

两台机器之间至少留一个互通的IP口，比如用ens3接口配置192.168.100.0/24地址。这里采用Linux自带的内核模块，不需要额外安装软件。如果你只有一台物理机，也可以用两个Network Namespace模拟，但虚拟机对网桥和VLAN的模拟更完整，排错思路和真实设备更接近。

3.2 AP侧建立gretap隧道并接入用户端口

在AP侧节点执行：

# 加载通用路由封装的内核模块 modprobe gre # 创建二层GRE隧道设备，名称为 grep-ap # remote指定隧道对端，local指定本端源地址，ttl限制隧道报文跳数 ip link add grep-ap type gretap remote 192.168.100.2 local 192.168.100.1 ttl 64 # 给隧道接口分配一个地址，这个地址不参与业务转发，仅用于接口up和测试 ip link set grep-ap up ip addr add 10.10.1.1/30 dev grep-ap

逻辑说明：gretap类型就是二层GRE，一个ip link add命令就完成了GRE头和以太网净荷的绑定。remote/local决定隧道两端，ttl 64保证隧道报文不会在环里无限流转。此时grep-ap接口看起来像一张网卡，但它的对端是10.10.1.2。参数上如果隧道会跨较多三层设备，建议把ttl调到128或更大；如果只在本园区三层网内，64足够。

把来自终端的接口加入一个Linux网桥，再把grep-ap也加入同一个网桥，让用户帧进隧道：

# 创建网桥，把终端接入端口和隧道接口放进去 ip link add br-ap type bridge ip link set eth1 master br-ap ip link set grep-ap master br-ap ip link set br-ap up

逻辑说明：这样终端发出的以太网帧就会被桥接进gretap隧道。参数上如果终端口允许多VLAN，还需要把eth1配置为trunk并指定允许的VLAN。如果终端口直接是access口，则用户帧上不带VLAN Tag，隧道头里也没有Tag，对端桥接时需要把这个无Tag帧放行到业务VLAN。这个细节经常被忽略，对AC侧配置影响很大。

3.3 AC侧建立gretap隧道并桥接到业务VLAN

在AC侧节点执行：

# 创建对端隧道接口，源目正好互换 ip link add grep-ac type gretap remote 192.168.100.1 local 192.168.100.2 ttl 64 ip link set grep-ac up ip addr add 10.10.1.2/30 dev grep-ac # 在AC侧创建网桥，把隧道口和业务VLAN接口桥在一起 ip link add br-core type bridge ip link set grep-ac master br-core # 假设用户业务VLAN在ens4.100上，先创建VLAN子接口 ip link add link ens4 name ens4.100 type vlan id 100 ip link set ens4.100 master br-core ip link set br-core up

逻辑说明：AC侧把隧道对端指向AP，并把grep-ac桥接到用户VLAN接口。这样用户报文从隧道到达后，被无差别送入业务VLAN。注意grep-ac本身不配置VLAN，它会原样转发内层携带的VLAN Tag，因此对端接入设备需要保持Trunk属性。如果业务VLAN在实体接口上，可以直接把实体接口加入br-core，但要注意这个接口不能再配置IP，否则桥接和三层的冲突会带来意想不到的丢包。

3.4 验证隧道是否真通：ping、桥接、抓包

先验证隧道三层可达：

ping -c 4 10.10.1.2 -I grep-ap

如果ping通，说明GRE隧道已经建立。但这只代表外层IP通了，不代表二层转发正常。再在AC侧抓包：

tcpdump -i grep-ac -e -n

在AP侧用真实终端ping网关，或者用Python脚本构造一个假以太网帧发进桥。抓到带0x6558协议类型字段的包，就是标准二层GRE。重点看内层以太网帧是不是原样到达，源MAC和VLAN是否和出发时一致。如果不一致，说明中间有设备剥离了Tag，隧道本身没问题，但桥接映射是错的。

这些步骤在所有支持gretap的Linux上可直接复现。回到智简园区设备上，华为AC和AP之间的“隧道转发”模式本质上就是建立二层隧道；管理员在AC上看到的配置项通常是“业务转发模式”或“隧道封装类型”，底层实现和这里一致。如果你拿不到物理设备，用Linux模拟器先把行为和抓包练熟，再去设备上验收会轻松很多。

3.5 从Linux实验映射到智简园区设备配置

熟悉Linux后，看设备配置就很快了。智简园区AC侧一般需要做三件事：创建隧道接口、指定源目的地址、把隧道口划入业务桥域。对应关系是ip link add对应“接口类型gretap”，remote/local对应“tunnel source/destination”，网桥对应“bridge-domain”。

华为VRP上的命令风格大概是这样，具体以你设备版本为准：

# AC侧示意：创建隧道接口并指定封装 interface Tunnel0/0/1 tunnel-protocol gre gre key 100 source Loopback0 destination 10.10.1.1 quit

这里gre key对应Linux里的key 100，source对应local，destination对应remote。很多设备还要求隧道接口加入某个桥域或二层转发实例，桥接关系由桥域配置完成。如果只配了隧道但没配桥域，业务流量不会转发，这是智简园区交付中常见的半截配置。

4. 把隧道调对：MTU、GRE Key、Keepalive和冗余的取舍

4.1 MTU与分片黑洞：园区WLAN最常见的丢包原因

二层GRE封装会让数据帧额外增加24到28字节。外层IP头20字节，GRE头4到8字节。如果原报文已经是1500字节，封装后变成1524字节，超过以太网标准MTU。很多园区终端发大包时会遇到能ping通但网页打不开的怪问题，罪魁祸首就是分片被丢弃。

解决策略分三步。第一，在所有隧道承载链路上开启大于1524的MTU，比如配置MTU 1600或启用巨帧；如果中间经过交换机，所有相关端口都要改，漏一个就前功尽弃。第二，如果中间线路不支持，就把业务VLAN接口的MTU调低到1400左右，从源头避免大包产生。第三，抓包看是否有IPv4 DF标志，很多终端默认带DF，如果隧道设备把DF也复制到外层IP头，大包会被直接丢弃，表现为“小包通、大包断”。

我一般会在每次交付后做一轮隧道MTU测试：

ping -M do -s 1472 10.10.1.2 -I grep-ap

-M do表示不允许分片，-s 1472是1500字节扣掉IP/ICMP头。如果这个包通，说明MTU刚好够；如果不通，逐步减小-s，直到得出最大可用值。注意这个测试只验证不带VLAN的净荷；业务报文如果带VLAN Tag，实际可用负载还要再减4字节。建议把测试值定在1400上下，留出余量给未来的扩展标签。

4.2 GRE Key：隔离隧道和防止误插

GRE Key是GRE头里的4字节字段，用来标识隧道。在智简园区WLAN里，如果一个AC同时服务多个AP或者多条隧道，建议每对源、目标使用独立GRE Key。配置命令在Linux下是：

ip link add grep-ap type gretap remote 192.168.100.2 local 192.168.100.1 key 100

设备上对应的参数一般叫“GRE Key”或“Tunnel ID”。注意两边Key必须一致，否则协商或者报文识别会失败。Key不提供加密，只提供标识和轻度过滤，不要把安全寄托在Key上。有些设备允许配置“key任意”，也就是接收时不检查Key，这时候隧道更宽松但也不安全，多AP场景下不建议开启。

实际交付中，我会给每条隧道按“业务VLAN+对端设备”编Key。比如VLAN 100的AP隧道Key就设100，AC间漫游隧道单独设Key 500。这样抓包时看一眼GRE Key就能知道是哪条隧道在转发，排查问题效率高很多。

4.3 Keepalive与隧道状态检测：别让半开隧道“看起来还活着”

二层GRE是纯粹的封装协议，本身没有握手。隧道对端重启或中间链路中断后，本端可能还在转发，造成黑洞。工程上需要配置隧道Keepalive，定期发送探测报文，探不到对端就置Down。Linux原生gretap接口自带carrier机制，可以配置gre keepalive参数，但不是所有版本都支持。稳妥做法是借助上层工具定期ping隧道IP，并把结果接入监控。

设备上常见配置示意：

# 隧道接口下配置Keepalive，周期5秒，连续3次失败则置Down interface Tunnel0/0/1 keepalive 5 3 quit

逻辑说明：探测周期5秒，重试3次，也就是15秒内没有收到回应就标记隧道Down。对于WLAN漫游切换频繁的场景，5秒足够灵敏也足够稳，太短会误报抖动，太长会让终端断网时间变长。Keepalive探测包走的是隧道外层IP，不依赖用户业务，所以能准确反映三层路径状态。如果中间链路做了负载均衡，注意Keepalive包和业务包可能走不同路径，丢包率会不一致，需要结合两端日志判断。

4.4 多隧道冗余：主备和负载均衡的简单做法

一个AC对应多个汇聚交换机时，可以在两端建立两条gretap隧道，分别绑定不同的源接口。运维中用路由优先级或策略路由决定业务走哪条。关键点：两条隧道的GRE Key、桥接VLAN要分开规划，防止广播帧从两条隧道折返形成环路。

智简园区多AC场景下，AC间漫游隧道也要做冗余，但必须启用STP或关闭二层环路协议，否则漫游流量会在AC间反复横跳。有些工程师为了性能关掉STP，业务一忙就出环，最后花两天排障。我的建议是：二层GRE桥域里必须保留STP，并且确保BPDU能穿越隧道。如果你的设备对隧道口不传BPDU，就在配置里显式放行。这属于交付时不起眼但出问题就要命的环节。

5. 二层GRE的避坑指南：现象、原因、解决对照

5.1 漫游后终端ARP不通，业务短暂中断

现象：终端从AP1漫游到AP2后，ping网关前几个包丢，ARP时通时不通，一段时间后恢复。

原因：终端在AP1发出的ARP经由旧隧道送AC，二层表项记录的是旧隧道端口。漫游到AP2后，AP2把该终端的帧从新隧道送来，AC桥上对应MAC的表项没切换，报文仍被转发到旧隧道，造成黑洞。这个问题在接近二层GRE后尤其明显，因为隧道口对AC来说就是“远端网桥”，MAC表项学习位置变了，但老化需要时间。

解决：在AC侧开启MAC地址表项快速老化，或配置MAC学习和隧道口联动刷新。命令行上如果设备支持，把桥接口的MAC老化时间从默认300秒调到30秒，并打开学习告警。配合终端重传就能快速恢复。如果是华为设备，可以检查桥域组播表和单播表是否一致，必要时手动清除老化表项。

5.2 业务子网出现广播风暴，全网告警

现象：同一广播域大量广播，CPU升高，AP之间互相能收到对方的广播帧，交换机端口流量异常。

原因：两棵二层网桥在多条隧道上互联。比如AP侧和AC侧各建了两条gretap，又都桥进同一个VLAN，形成二层环路。广播帧进入一条隧道，传到对端，又从另一条隧道传回来，如此循环放大。

解决：隧道的桥接拓扑必须成树。要么只用一条隧道承载一个业务VLAN，要么在核心侧启用STP/RSTP，并且把STP BPDU封装穿越隧道。很多默认配置不传BPDU，要在隧道接口上放行。最省事的做法是每业务VLAN绑定一条物理路径，不做双隧道。如果你要做主备冗余，务必做“链路+隧道”两级状态联动，隧道Down时立刻切路径，避免双活转发。

5.3 视频会议时好时坏，丢包率不高但延迟抖动

现象：ping包全程无丢包，实际业务卡顿，抓包发现部分包分片，或者RTP时间戳错位、画面马赛克。

原因：隧道MTU配置和终端不一致，大包被分片后在接收端重组，只要丢了其中一片，整个原始帧被丢弃，视频流自然卡顿。踩坑点在于你之前用ping -s 1472测试通过，但视频报文可能带VLAN和MPLS标签，实际负载超过测试值。另一个隐蔽原因：某些终端用UDP大包，而UDP不像TCP那样有重传机制，分片丢失后直接不可恢复。

解决：用抓包工具统计隧道出接口超过MTU的帧数，统一把所有二层链路MTU调到1518以上，隧道内层接口调到与业务匹配。如果无法改MTU，就把应用侧改成UDP小包传输，或者用语音流量优先队列缩短排队时延。最彻底的做法是让终端使用TCP承载大包，UDP承载小包，但这往往要改应用，复杂度高。

5.4 AC或AP重启后隧道恢复很慢，期间无线中断

现象：AC升级重启后，AP全部显示在线，但用户上不了网长达几分钟。

原因：隧道Keepalive周期太长，很多设备默认60秒才探测一次。AC重启后隧道口状态仍为UP，需要等待超时才能重建。另一个原因是AP侧隧道源接口绑定在动态拨号接口上，IP变化后没有触发重连。AP的CAPWAP管理通道可能已经重连，但GRE隧道没有联动重建。

解决：把Keepalive周期调到5秒，重试次数调到3次；AP侧隧道源建议用Loopback口，避免IP漂移。升级流程上，先关闭隧道接口再重启AC，而不是直接断电拔线，能让AP立即走重建流程。如果你在设备上看到“隧道Flap”日志，多半是因为源接口物理状态变化，排查物理链路和接口协商优先级才是重点。

5.5 隧道两端Key不一致导致“野生”流量串入

现象：多个AP的隧道都能起来，但某AP的用户流量偶尔出现在其他VLAN，监控里看到未知MAC的来源是隧道口。

原因：配置时复制粘贴隧道参数，GRE Key填错或漏配。二层GRE不会因为Key错误而拒绝报文，有些设备只在接收侧按Key过滤，如果对端不校验，报文就可能被错误桥接。尤其是多台AP批量部署时，一次性下发配置，Key占位符没替换，所有AP共用了一个Key，业务VLAN却各不相同，于是流量乱串。

解决：配置后必须逐个隧道执行“显示隧道摘要”类命令核对源、目的、Key三类参数。脚本化验证比较可靠，写个循环把各隧道的五元组和桥接关系打出来，和规划表对比。这条不出问题则已，一出就是跨VLAN的合规风险。涉及园区多租户场景时，Key规划表要单独存档，和VLAN规划表放一起，防止后续扩容时新隧道撞Key。

6. 进阶排错：把二层GRE的“命门”抓在手里

6.1 用traceroute确认隧道外层路径

隧道不通时先别查内层，直接用traceroute打隧道目的IP（外层IP）。如果中间某跳丢包，说明链路问题在Underlay，不是GRE配置问题。只有外层路径通了，才有必要看GRE封装。这条习惯能帮你省下至少一半排障时间。很多工程师一上来抓内层包，看到一堆乱码就怀疑加密协商，实际上二层GRE根本没有加密。

6.2 抓包必须看三个地方

一是外层IP头里的源目地址，确认隧道方向；二是GRE头的协议类型，二层GRE应为0x6558，如果看到0x0800说明你抓到的是三层GRE；三是内层以太网帧的VLAN Tag，与规划的桥接VLAN比对。一次抓三个点，基本能把配置错误、路径错误、VLAN错误分开。隧道抓包用tcpdump -i any看所有口，比只监听物理口更全面。

6.3 持续监控隧道丢包率

我习惯在AC侧用如下命令做一轮持续探测：

ping -c 1000 -i 0.2 -s 1400 10.10.1.1 -I grep-ac | grep loss

间隔0.2秒、持续1000次，既能观察抖动又能测丢包。如果丢包集中在某段时间，去查看外层链路的SNMP流量和出端口误码。两分钟观测比一整天看“设备状态正常”更接近真相。配合设备侧隧道接口的收发包计数，能确认丢包发生在入口还是出口。

这些年做园区WLAN交付，我最大的感受是：二层GRE不是复杂技术，但任何一个细节没对齐，都会变成深夜翻车现场。每次隧道类问题，先按分支判断“外层三层通不通、GRE头对不对、桥接VLAN到不到位”，再决定重启谁。希望帮到你。

本文还有配套的精品资源，点击获取