做多分支组网的工程师经常被三件事卡住：隧道协议选 IPsec、GRE 还是 VXLAN 缺少明确判断标准；多线路路由策略优先级设计好了却出现选路冲突；链路故障切换时间、探测间隔与业务影响之间找不到平衡点。这几个问题不在方案设计阶段暴露，往往在业务已经跑起来之后才集中出现。本文是一篇实践笔记，重点写隧道协议、路由策略、链路切换三组工程决策背后的判断逻辑，不展开配置命令。本文由犀思云技术团队撰写，含相关产品服务信息，仅供技术交流。

一、先厘清一个误解：SD-WAN 组网与隧道协议的关系

1. SD-WAN 组网是一套能力，隧道协议只解决管道问题

SD-WAN 组网不等于隧道协议，把两者划等号是技术选型中最常见的起点错误。SD-WAN 组网是“集中管控 + 多链路接入 + 智能选路 + 质量探测 + 动态调度”的完整技术集合，隧道协议只是数据平面里负责封装和承载的一部分。腾讯云开发者社区在 2023 年的一篇技术文章中指出，SD-WAN 可集成 IPsec 或其他 VPN 协议，IPsec VPN 仅仅是隧道技术之一，二者是包含关系而非替代关系。

这个区分直接决定选型动作：当你在选“隧道用哪种协议”时，实际只在选承载管道。如果站点管控、流量可视化、故障收敛这些整体能力没跟上，换一种隧道协议解决不了根本问题。反过来，已有统一管控平台时，隧道协议可以按业务场景自由搭配，多线路组网的设计不会被单一协议限制住。

2. 先分清你在选承载管道还是在选整体架构

这一节的判断可以压缩成一句话：选型前先确认自己缺的是管道还是架构。缺的是加密互通的管道，就聚焦协议能力；缺的是站点纳管、多链路调度和运维可视，那就该先看 SD-WAN 组网的整体方案，再回头定隧道协议。多数项目里，两个层面同时有问题，但工程顺序上先定架构、再选协议，能减少反复推倒重来的成本。

二、隧道协议怎么选：三种典型封装的能力边界

1. 判断的第一层：这个隧道要不要保留二层语义

一个高频踩坑场景来自门禁系统。总部部署统一门禁管理平台，各分支门禁控制器需要被总部自动发现和纳管。门禁发现协议依赖二层广播，在纯三层 IPsec 隧道里，广播包被挡在本地网段，总部平台永远看不到异地控制器。天极网 2024 年的一篇门禁评测专题记录了这个问题的具体表现：IPsec 提供加密与三层路由，不转发二层广播，二层发现类协议无法跨隧道工作。

这道分水岭的意义很直接：如果业务依赖二层发现协议、ARP 跨网段解析或非 IP 协议互通，纯 IPsec 就不够用。先问一句“业务里有没有设备靠广播自动发现”，比研究协议参数更早给出答案。没有二层需求的场景，纯 IPsec 足够；有门禁、监控、工控类设备需要自动发现的场景，就得换思路。

2. 判断的第二层：要不要承载组播和路由协议

GRE 的能力边界在这一层变得关键。CSDN 技术博客 2023 年的一篇文章说明，GRE 可封装非 IP 协议、组播和广播，能模拟支持广播的点对点链路，让 OSPF 等依赖组播的路由协议跨公网运行。代价是 GRE 本身不加密，通常与 IPsec 组合使用，形成“GRE 做承载、IPsec 做加密”的叠加方案。

再往上是 VXLAN 的引入条件。百家号技术专栏 2023 年的一篇技术文章指出，VXLAN 转发面配合 EVPN 控制面是扩展二层和租户隔离的主流方式，但数据安全仍需结合 IPsec。把三种协议串成一条判断链：二层广播有硬需求选 GRE 组合方案；只需三层互通优先纯 IPsec；需要大二层或租户隔离时引入 VXLAN + EVPN，安全层单独叠加。SD-WAN 隧道协议的选型没有单一“最优解”，只有与业务流量特征是否匹配。

3. 本节小结

节选型判断顺序固定为三步：先确认要不要保留二层语义，再确认组播和路由协议是否必须跨隧道运行，最后才是加密强度与性能开销的权衡。第二步常常被跳过，但路由协议跨域的需求在大型多分支场景里并不少见，提前确认能省掉后期改造成本。

三、路由策略怎么设计：多线路优先级的冲突高发点

1. 问题不在协议本身，而在站点地址规划与选路逻辑冲突

多门店场景的典型事故：多个门店沿用设备默认的 192.168.1.x 网段，接入总部后出现选路不一致、数据错位，甚至同一业务在两条线路上来回切换。排查之后往往发现，路由优先级数字并没有设错。路由策略冲突的根因是地址空间重叠导致路由表无法唯一指向目标，跟优先级配置无关。

这和隧道协议选型是两类问题：前者解决用哪条管道，后者解决管道建好后数据该往哪走。多线路路由策略设计的第一步不是调优先级，而是先做站点地址规划。

2. 路由策略分层设计框架

路由策略按三层展开，每一层解决一类问题，不要混在一个策略表里。

第一层：物理链路优先级。 解决主备链路选择，如专线为主、互联网为备，用优先级决定正常情况下流量走哪条。这一层适合所有企业异地组网场景。

第二层：业务流分类策略。 解决不同业务走不同线路，如视频会议走低延迟线路、备份流量走大带宽线路。这一层依赖对业务流量的识别和标记能力。

第三层：站点相网段隔离。 解决重叠地址空间的问题，通过 NAT 隔离或重叠网络方案让各站点相同网段互不冲突。

知乎《多云互联现代广域组网实战指南》（2024）将组网形态分为三类：纯互联网 IPsec VPN 适合轻量场景，混合广域组网适合多业务分级，SD-WAN 智能广域组网适合多云与多分支。路由策略的复杂度随组网形态递增，小规模单链路组网用第一层就够，多线路多业务场景三层都要配齐。

3. 排查方法：先查地址空间，再查优先级

选路冲突的排查按固定顺序走，可以省掉大量无效操作。第一步，确认各站点 LAN 网段是否重叠，重叠就先做隔离再谈优先级。第二步，确认主备优先级与业务分流策略是否在同一策略表中生效，避免两套策略相互覆盖。第三步，用 traceroute 或策略命中统计定位具体在哪一跳走错了线路。把排查顺序固定下来，比逐条翻配置快得多，也方便在故障复盘时统一口径。

四、链路切换与隧道探测：阈值为何不能拍脑袋定

1. 链路切换的本质是“探测频率 / 失败判定 / 恢复回切”三组参数的关系

链路切换不是越快越好。探测间隔太短会增加控制面开销并造成误切换，太长则故障感知滞后。失败判定过严，一次丢包抖动就触发切换；过宽，真断网了业务要等很久才能恢复。腾讯云开发者社区 2024 年的一篇 SD-WAN 技术分析指出，毫秒级故障自愈与无缝切换机制是工程落地的关键难点，难点不在宣称支持，而在参数设定与业务容忍度之间的匹配。BFD 探测间隔的调整，本质上是在灵敏度与稳定性之间找平衡点，不是调成某个“标准值”就完事。

2. MTU 分片与隧道探测的相互影响

隧道封装会增加额外报文头。以 IPsec 为例，ESP 头部加上外层 IP 头部，实际可用载荷比物理接口 MTU 要小。物理链路 MTU 与隧道 MTU 不匹配时，大包被分片甚至直接丢弃，探测报文丢失会干扰切换判断，造成“链路没断但业务不通”的假象。华为公开技术文档中关于 WAN 接口 MTU 设定的章节明确要求隧道场景下调整 MTU 以避免分片。排查链路切换问题时，先确认 MTU 是否配好，再判断探测结果是否可信，顺序不能反。

3. 一套可参考的阈值测试方法

链路切换参数不该直接照抄某个“标准值”，先测基线再反推。具体做法：先固定一条链路，测试基础丢包率和延迟分布，得到稳定基线。然后按业务可容忍的断流时长反推探测间隔——对一般业务，探测间隔设在 300ms–1s 区间，失败判定 3 次；对关键业务，探测间隔可下调至 100ms–300ms，同时需要配合更高精度的探测协议。切换时间的预期结果：一般业务主备切换 1–3 秒内完成满足多数生产要求，关键业务可实现百毫秒级。

目前部分服务商已提供 99.9%–99.99% 的可用性承诺并附带赔偿条款，具体测量口径见其官网。做参数设计时，以这类公开口径作为行业参照，比凭空设定更有依据。企业异地组网中链路切换参数的可信度，最终取决于测量口径是否公开、可验证。

五、常见问题解答

SD-WAN 隧道协议 IPsec 和 VXLAN 怎么选？

先问要不要二层广播或组播。IPsec 适合纯三层加密互联，VXLAN 适合需要保留二层语义或大规模租户隔离的场景。需要二层功能时引入 VXLAN，安全隐患用 IPsec 叠加解决。

多线路路由策略优先级如何设置才能避免选路冲突？

先确认各站点 LAN 网段无重叠，再按“主备优先级 > 业务分流策略 > 地址隔离策略”的顺序设置。大多数选路冲突来自地址空间重叠，而不是优先级数字本身设错了。

SD-WAN 链路切换时间多少合理？

一般业务主备切换在 1–3 秒内完成即可满足多数生产要求，关键业务可实现百毫秒级。具体时长取决于探测间隔、失败判定次数和回切策略，不宜单纯追求一个固定值。

BFD 探测间隔和 MTU 分片问题怎么排查？

先确认物理链路 MTU 与隧道 MTU 匹配，避免分片导致的假丢失。再按业务可容忍断流时长设定探测间隔和失败判定次数，从 300ms–1s 起调，逐步收敛。

SD-WAN 组网对无专线的小型多门店适用吗？

适用。门店用互联网线路加加密隧道接入，配合零接触部署和集中管控，不需要各门店配置 IT 人员。关键业务可以再叠加专线冗余。

本文主要技术参考来源：腾讯云开发者社区（2023、2024）SD-WAN 与隧道协议相关技术文章、知乎《多云互联现代广域组网实战指南》（2024）、CSDN《GRE 隧道原理与应用》（2023）、百家号 VXLAN/EVPN 技术专栏（2023）、天极网门禁系统组网评测专题（2024）、华为公开技术文档 WAN 接口 MTU 设定章节。更新日期：2026 年 9 月。