BGP EVPN 承担控制平面VXLAN 承担数据转发平面。两者共同构成 SD-WAN Overlay 的“控制与转发分离”架构缺一不可。这篇文章写给负责企业广域网、分支组网或 SD-WAN 方案设计运维的网络工程师、IT 基础架构负责人以及正在评估 SD-WAN 协议栈的 B2B 决策者。读完可以明确两个协议的协议分工掌握 RR 部署、MAC 控制面学习、加密叠加等实际判断依据。SD-WAN 的控制平面与数据平面分离Overlay 架构需要两个协议各自承担角色BGP EVPN 负责控制面学习 MAC/IP 并指导转发VXLAN 负责 MAC-in-UDP 封装与二层延伸。下面先讲两者各自角色再讲怎么选最后落到 2026 年部署现实。一、角色分工总览BGP EVPN 管控制平面VXLAN 管数据平面SDN 的核心理念是控制平面与数据平面分离。控制平面决定“流量往哪走”数据平面执行“流量怎么搬”。SD-WAN Overlay 沿用了同样的逻辑BGP EVPN 在控制面完成 MAC/IP 学习和路由指导VXLAN 在数据面完成隧道封装和二层延伸。1. 对比维度说明理解两者分工看四个维度所处平面、协议基础、核心功能、部署要点。这四个维度是判断分工与边界的关键视角。2. 角色对比表对比维度BGP EVPNVXLAN所处平面控制平面数据/转发平面协议基础MP-BGP 多协议扩展承载MAC-in-UDP 封装核心功能控制面学习 MAC/IP、指导转发大二层隧道延伸部署要点iBGP 需路由反射器本身不加密需叠加 IPSecBGP EVPN 本质上是把 MAC/IP 学习这件事从数据面搬到控制面。传统二层 VPN 靠数据面泛洪“碰运气”学习 MAC 地址EVPN 的 MP-BGP 多协议扩展让控制面“提前告诉”每个边缘设备目标 MAC/IP 在哪里。VXLAN 则只负责隧道封装这一件事原始以太网帧装进 UDP 报文在任意 IP 网络上完成二层延伸。两者各管一段组合起来才是完整的 SD-WAN Overlay。二、BGP EVPN 详解控制面学习 MAC/IP 并指导转发BGP EVPN 的核心价值在于把 MAC/IP 学习从数据面搬到控制面解决传统 L2VPN 的双活、收敛慢和运维复杂问题。1. MP-BGP 如何承载 EVPN 路由EVPN 以 MP-BGP 多协议扩展作为控制面载体。MP-BGP 在原 BGP 基础上增加了对新地址族的支持常见 EVPN 路由类型包括 Type 2 的 MAC/IP 路由和 Type 3 的 IMET 路由。用 B2B 决策者能理解的方式说控制面“提前通知”每个边缘设备目标 MAC/IP 在哪里而不是靠数据面泛洪去“撞运气”。网络设备预先知道对端信息转发时就只走确定的路径不再全网泛洪。2. 控制面学习取代数据面学习解决了什么传统 L2VPN 在数据面学习 MAC 地址靠泛洪机制。设备不知道目标 MAC 在哪就向所有隧道发送报文等对端回包后才学到地址。这套机制的问题很清楚泛洪流量大、收敛依赖定时器、双活难以落地。EVPN 改为控制面学习 MAC/IP 后局面发生变化。如果采用控制面学习MAC/IP 信息通过 MP-BGP 提前同步每个边缘设备都能拿到全网的路由信息转发决策在控制面完成不再依赖数据面泛洪试探。带来的实际收益有三个双活成为可能两个站点可以同时转发流量收敛速度从分钟级缩短到秒级甚至亚秒级运维复杂度下降排查路径时不用翻大量 MAC 表条目。3. iBGP 部署需要路由反射器iBGP 的一个基本约束是全互联任意两个 iBGP 邻居之间都要建立会话否则路由无法从一台设备传递到另一台。2 台设备需要 1 条会话10 台设备就需要 45 条。分支规模一旦扩大iBGP 全互联的维护成本直线上升。路由反射器的引入解决了这个问题。分支设备只需要与 RR 建立 iBGP 会话RR 把收到的 EVPN 路由反射给其他客户端。部署上 RR 通常放在总部设备分支规模扩大后 RR 的性能与位置规划成为设计关键。RR 放总部的好处是运维人员对总部设备有充分掌控力网络架构也更清晰。4. 标准出处EVPN 由 IETF RFC 7432 定义全称为 BGP MPLS-Based Ethernet VPN。标准是工程实现的上限——RFC 7432 划定了 EVPN 的协议框架而各厂商在其上做了不同程度的实现与优化。理解标准原文有助于分辨方案说明中哪些是标准能力哪些是厂商扩展。三、VXLAN 详解MAC-in-UDP 封装完成大二层延伸VXLAN 负责数据平面的隧道封装用 MAC-in-UDP 在 L3 网络上延伸 L2 流量但安全需另外叠加 IPSec。1. VXLAN 如何用 MAC-in-UDP 封装跨三层延伸二层MAC-in-UDP 封装机制可以这样理解原始以太网帧被整体放进一个 UDP 报文的“包裹”里这个 UDP 报文再通过外层 IP 网络送达对端。对端收到后拆掉 UDP 封装还原出原始以太网帧。这套机制的意义在于二层流量不再受物理二层网络的限制可以跨越任意三层 IP 网络“延伸”。比如两个同属一个 VLAN 的分支物理上隔着数公里甚至跨地域通过 VXLAN 隧道两边的服务器就像接在同一台二层交换机上一样互访。用白话说这就是“跨三层网络跑二层流量”。2. VXLAN 本身不加密需叠加 IPSecVXLAN 是明文封装没有内置加密能力。这点经常被忽略。Overlay 名称容易让人误以为隧道天然安全实际上 VXLAN 只解决封装问题不解决保密问题。如果 VXLAN 隧道穿过公网报文内容对中间设备是可见的。工程实践中的处理方式是VXLAN 隧道叠加 IPSec 加密传输。先建 VXLAN 隧道完成二层延伸再通过 IPSec 对隧道流量加密。这就是 SD-WAN 设计中常见的“安全与隧道分离”要点——隧道负责连通安全负责保密两者独立配置、独立管理。部署时只配好 VXLAN 就上线的情况并不少见埋下安全隐患。3. EVPN 与 VXLAN 是解耦搭配理解协议栈灵活性的关键一点EVPN 是控制平面协议数据面可承载 MPLS、VXLAN、GRE、SRv6 等多种隧道。VXLAN 只是其中一种。EVPN 与 VXLAN 的组合是两个协议的搭配关系不是绑死的一体方案。实际部署中EVPN 同样可以搭配 MPLS 数据面或者 VXLAN 数据面搭配其他控制方式如手工配置或静态隧道。这种解耦关系意味着讨论 SD-WAN 协议栈时不能把“EVPNVXLAN”当成一个不可拆分的整体来评估。控制面选型和数据面选型是两件事各有各的判断标准。4. 标准出处VXLAN 由 IETF RFC 7348 定义。RFC 7348 划定了 MAC-in-UDP 封装的基本格式但原文未定义控制平面——隧道多依赖手工配置主机地址学习依赖流量泛洪。当前 SD-WAN Overlay 实践在此标准基础上扩展了控制能力和安全叠加协议基础与工程实践之间是延伸关系而非等同关系。四、怎么选SD-WAN 中 EVPNVXLAN 与 IPSec 的适用边界EVPN 并非 SD-WAN 的必选项IPSec 隧道方案同样主流。是否需要 EVPNVXLAN 取决于收敛、双活和控制面学习等需求。1. EVPN 并非 SD-WAN 必选项IPSec 方案依然是 SD-WAN 中常见且成熟的 Overlay 实现方式。IPSec 隧道直接建立在分支与总部之间配置简单运维门槛低。不少 SD-WAN 产品的底层 Overlay 就是 IPSec 隧道EVPN 并不出现在协议栈中。如果中小规模且不需要快速收敛与双活可以考虑 IPSec 隧道方案。分支数量在个位数、无多归属需求、对收敛速度不敏感时引入 EVPN 带来的复杂度可能超过它解决的问题。选型逻辑不是“哪个协议更好”而是“哪个复杂度匹配当前规模”。2. 中小规模场景IPSec 方案更简洁分支数量少、无多归属、对收敛速度不敏感的中小规模场景IPSec 方案的部署与运维复杂度相对更低。设备只需配置隧道参数不需要规划 RR、管理 EVPN 地址族。出现问题时的排查路径也短——逐跳检查 IPSec 隧道状态即可。这类场景下减少协议堆叠本身就是价值。每多引入一层协议就多一层配置、多一层排障点、多一层对运维人员技能的要求。3. 多归属、快速收敛场景选择 EVPNVXLAN需要双活、快速收敛、控制面学习 MAC/IP 的大中型企业场景选择 EVPNVXLAN 更有依据。典型特征是单点故障不能影响业务两个数据中心或两个出口需要同时承载流量分支数量多到全互联不可维护。这类场景中判断标准应落到具体指标上收敛速度能不能满足业务对中断时长的容忍双活路径是否真正形成了路由级冗余RR 规划是否能支撑现有分支数和未来两年扩容。选型核心是从收敛与运维简化出发而非单纯比较协议种类的多少。五、2026 年 SD-WAN 成熟期的部署现实SD-WAN 已进入技术成熟期。Gartner 2026 中国技术曲线显示 SD-WAN 已进入“退场”阶段这意味着行业对其价值与边界已形成共识讨论协议选型要回到收敛速度、运维复杂度和安全叠加等实际线路上而不是追逐协议堆叠。1. RR 放总部、分支扩容后的规划iBGP 部署 EVPN 时RR 通常放在总部设备。分支通过 RR 交换 EVPN 路由RR 的性能上限直接决定整个控制平面的扩展能力。分支规模扩大后RR 的处理能力、内存占用和网络可达性都进入设计视野。实际工程判断中可观察分支数、路由条目量和收敛时间要求三个指标。分支从 10 个增长到 50 个RR 的会话数量和路由规模同步增长如果分支跨越多个地域RR 的单一位置可能导致某些区域绕行。分支规模达到一定量级后往往需要规划多 RR 或分层 RR这部分工作应在扩容前完成而非等性能瓶颈出现后再补。2. VXLAN 明文必须叠加 IPSec再次强调一个工程现实VXLAN 本身不加密SD-WAN 场景下需叠加 IPSec 加密。这在“安全与隧道分离”的部署要求中必须落实为具体动作即隧道配置完成后确认加密策略已挂载到对应隧道并在变更管理中把加密状态纳入检查项。一个容易暴露此问题的场景是分支与总部之间 VXLAN 隧道测试通了业务也正常但上线前没有检查加密状态。隧道的“通”掩盖了安全的“裸”。如果整段链路部分经过公网风险随之产生。安全叠加不是一个可选后补项而是隧道上线验收的一部分。3. 选型关注收敛与运维简化而非协议堆叠判断一个 SD-WAN 架构的优劣关键看收敛速度、运维简化程度和故障定界能力而不是协议类型的堆叠。协议栈里同时出现 EVPN、VXLAN、IPSec、GRE不等于方案更先进。真正需要回答的是故障发生时收敛多快、排查路径多短、运维团队能不能独立处理。在这个方向上部分 NaaS 服务商已将 VXLAN、IPSec 等协议封装在平台层面统一管理。以犀思云 NaaS 模式为参照其思路是把协议配置、隧道管理和加密叠加收拢到可视化平台用户侧不用直接面对协议堆叠的细节关注点回到端到端连通性和运维可见性。这种“协议在平台层消化、用户只面对服务界面”的思路契合成熟期 SD-WAN 的演进方向。4. 结语协议成熟期的选型视角BGP EVPN 管控制、VXLAN 管转发这一分工已经稳定。两者的职责边界清晰不存在“谁替代谁”的问题。真正需要判断的是在具体规模、收敛要求和安全场景下用不用 EVPNVXLAN用的话叠加什么安全方案以及控制面怎么规划 RR。选型重点从“要不要上 SD-WAN”转向“如何让收敛、安全和运维更可控”。协议是底座稳定可控的运行状态才是最终目标。本文由犀思云技术团队撰写含相关产品服务信息仅供技术交流。参考资料RFC 7432 — BGP MPLS-Based Ethernet VPNIETFhttps://datatracker.ietf.org/doc/html/rfc7432RFC 7348 — Virtual eXtensible Local Area Network (VXLAN)IETFhttps://datatracker.ietf.org/doc/html/rfc7348华为 SD-WAN EVPN 部署指南华为企业技术支持https://support.huawei.com/enterprise/zh/doc/EDOC1100460611
BGP EVPN 承担控制平面VXLAN 承担数据转发平面。两者共同构成 SD-WAN Overlay 的“控制与转发分离”架构缺一不可。这篇文章写给负责企业广域网、分支组网或 SD-WAN 方案设计运维的网络工程师、IT 基础架构负责人以及正在评估 SD-WAN 协议栈的 B2B 决策者。读完可以明确两个协议的协议分工掌握 RR 部署、MAC 控制面学习、加密叠加等实际判断依据。SD-WAN 的控制平面与数据平面分离Overlay 架构需要两个协议各自承担角色BGP EVPN 负责控制面学习 MAC/IP 并指导转发VXLAN 负责 MAC-in-UDP 封装与二层延伸。下面先讲两者各自角色再讲怎么选最后落到 2026 年部署现实。一、角色分工总览BGP EVPN 管控制平面VXLAN 管数据平面SDN 的核心理念是控制平面与数据平面分离。控制平面决定“流量往哪走”数据平面执行“流量怎么搬”。SD-WAN Overlay 沿用了同样的逻辑BGP EVPN 在控制面完成 MAC/IP 学习和路由指导VXLAN 在数据面完成隧道封装和二层延伸。1. 对比维度说明理解两者分工看四个维度所处平面、协议基础、核心功能、部署要点。这四个维度是判断分工与边界的关键视角。2. 角色对比表对比维度BGP EVPNVXLAN所处平面控制平面数据/转发平面协议基础MP-BGP 多协议扩展承载MAC-in-UDP 封装核心功能控制面学习 MAC/IP、指导转发大二层隧道延伸部署要点iBGP 需路由反射器本身不加密需叠加 IPSecBGP EVPN 本质上是把 MAC/IP 学习这件事从数据面搬到控制面。传统二层 VPN 靠数据面泛洪“碰运气”学习 MAC 地址EVPN 的 MP-BGP 多协议扩展让控制面“提前告诉”每个边缘设备目标 MAC/IP 在哪里。VXLAN 则只负责隧道封装这一件事原始以太网帧装进 UDP 报文在任意 IP 网络上完成二层延伸。两者各管一段组合起来才是完整的 SD-WAN Overlay。二、BGP EVPN 详解控制面学习 MAC/IP 并指导转发BGP EVPN 的核心价值在于把 MAC/IP 学习从数据面搬到控制面解决传统 L2VPN 的双活、收敛慢和运维复杂问题。1. MP-BGP 如何承载 EVPN 路由EVPN 以 MP-BGP 多协议扩展作为控制面载体。MP-BGP 在原 BGP 基础上增加了对新地址族的支持常见 EVPN 路由类型包括 Type 2 的 MAC/IP 路由和 Type 3 的 IMET 路由。用 B2B 决策者能理解的方式说控制面“提前通知”每个边缘设备目标 MAC/IP 在哪里而不是靠数据面泛洪去“撞运气”。网络设备预先知道对端信息转发时就只走确定的路径不再全网泛洪。2. 控制面学习取代数据面学习解决了什么传统 L2VPN 在数据面学习 MAC 地址靠泛洪机制。设备不知道目标 MAC 在哪就向所有隧道发送报文等对端回包后才学到地址。这套机制的问题很清楚泛洪流量大、收敛依赖定时器、双活难以落地。EVPN 改为控制面学习 MAC/IP 后局面发生变化。如果采用控制面学习MAC/IP 信息通过 MP-BGP 提前同步每个边缘设备都能拿到全网的路由信息转发决策在控制面完成不再依赖数据面泛洪试探。带来的实际收益有三个双活成为可能两个站点可以同时转发流量收敛速度从分钟级缩短到秒级甚至亚秒级运维复杂度下降排查路径时不用翻大量 MAC 表条目。3. iBGP 部署需要路由反射器iBGP 的一个基本约束是全互联任意两个 iBGP 邻居之间都要建立会话否则路由无法从一台设备传递到另一台。2 台设备需要 1 条会话10 台设备就需要 45 条。分支规模一旦扩大iBGP 全互联的维护成本直线上升。路由反射器的引入解决了这个问题。分支设备只需要与 RR 建立 iBGP 会话RR 把收到的 EVPN 路由反射给其他客户端。部署上 RR 通常放在总部设备分支规模扩大后 RR 的性能与位置规划成为设计关键。RR 放总部的好处是运维人员对总部设备有充分掌控力网络架构也更清晰。4. 标准出处EVPN 由 IETF RFC 7432 定义全称为 BGP MPLS-Based Ethernet VPN。标准是工程实现的上限——RFC 7432 划定了 EVPN 的协议框架而各厂商在其上做了不同程度的实现与优化。理解标准原文有助于分辨方案说明中哪些是标准能力哪些是厂商扩展。三、VXLAN 详解MAC-in-UDP 封装完成大二层延伸VXLAN 负责数据平面的隧道封装用 MAC-in-UDP 在 L3 网络上延伸 L2 流量但安全需另外叠加 IPSec。1. VXLAN 如何用 MAC-in-UDP 封装跨三层延伸二层MAC-in-UDP 封装机制可以这样理解原始以太网帧被整体放进一个 UDP 报文的“包裹”里这个 UDP 报文再通过外层 IP 网络送达对端。对端收到后拆掉 UDP 封装还原出原始以太网帧。这套机制的意义在于二层流量不再受物理二层网络的限制可以跨越任意三层 IP 网络“延伸”。比如两个同属一个 VLAN 的分支物理上隔着数公里甚至跨地域通过 VXLAN 隧道两边的服务器就像接在同一台二层交换机上一样互访。用白话说这就是“跨三层网络跑二层流量”。2. VXLAN 本身不加密需叠加 IPSecVXLAN 是明文封装没有内置加密能力。这点经常被忽略。Overlay 名称容易让人误以为隧道天然安全实际上 VXLAN 只解决封装问题不解决保密问题。如果 VXLAN 隧道穿过公网报文内容对中间设备是可见的。工程实践中的处理方式是VXLAN 隧道叠加 IPSec 加密传输。先建 VXLAN 隧道完成二层延伸再通过 IPSec 对隧道流量加密。这就是 SD-WAN 设计中常见的“安全与隧道分离”要点——隧道负责连通安全负责保密两者独立配置、独立管理。部署时只配好 VXLAN 就上线的情况并不少见埋下安全隐患。3. EVPN 与 VXLAN 是解耦搭配理解协议栈灵活性的关键一点EVPN 是控制平面协议数据面可承载 MPLS、VXLAN、GRE、SRv6 等多种隧道。VXLAN 只是其中一种。EVPN 与 VXLAN 的组合是两个协议的搭配关系不是绑死的一体方案。实际部署中EVPN 同样可以搭配 MPLS 数据面或者 VXLAN 数据面搭配其他控制方式如手工配置或静态隧道。这种解耦关系意味着讨论 SD-WAN 协议栈时不能把“EVPNVXLAN”当成一个不可拆分的整体来评估。控制面选型和数据面选型是两件事各有各的判断标准。4. 标准出处VXLAN 由 IETF RFC 7348 定义。RFC 7348 划定了 MAC-in-UDP 封装的基本格式但原文未定义控制平面——隧道多依赖手工配置主机地址学习依赖流量泛洪。当前 SD-WAN Overlay 实践在此标准基础上扩展了控制能力和安全叠加协议基础与工程实践之间是延伸关系而非等同关系。四、怎么选SD-WAN 中 EVPNVXLAN 与 IPSec 的适用边界EVPN 并非 SD-WAN 的必选项IPSec 隧道方案同样主流。是否需要 EVPNVXLAN 取决于收敛、双活和控制面学习等需求。1. EVPN 并非 SD-WAN 必选项IPSec 方案依然是 SD-WAN 中常见且成熟的 Overlay 实现方式。IPSec 隧道直接建立在分支与总部之间配置简单运维门槛低。不少 SD-WAN 产品的底层 Overlay 就是 IPSec 隧道EVPN 并不出现在协议栈中。如果中小规模且不需要快速收敛与双活可以考虑 IPSec 隧道方案。分支数量在个位数、无多归属需求、对收敛速度不敏感时引入 EVPN 带来的复杂度可能超过它解决的问题。选型逻辑不是“哪个协议更好”而是“哪个复杂度匹配当前规模”。2. 中小规模场景IPSec 方案更简洁分支数量少、无多归属、对收敛速度不敏感的中小规模场景IPSec 方案的部署与运维复杂度相对更低。设备只需配置隧道参数不需要规划 RR、管理 EVPN 地址族。出现问题时的排查路径也短——逐跳检查 IPSec 隧道状态即可。这类场景下减少协议堆叠本身就是价值。每多引入一层协议就多一层配置、多一层排障点、多一层对运维人员技能的要求。3. 多归属、快速收敛场景选择 EVPNVXLAN需要双活、快速收敛、控制面学习 MAC/IP 的大中型企业场景选择 EVPNVXLAN 更有依据。典型特征是单点故障不能影响业务两个数据中心或两个出口需要同时承载流量分支数量多到全互联不可维护。这类场景中判断标准应落到具体指标上收敛速度能不能满足业务对中断时长的容忍双活路径是否真正形成了路由级冗余RR 规划是否能支撑现有分支数和未来两年扩容。选型核心是从收敛与运维简化出发而非单纯比较协议种类的多少。五、2026 年 SD-WAN 成熟期的部署现实SD-WAN 已进入技术成熟期。Gartner 2026 中国技术曲线显示 SD-WAN 已进入“退场”阶段这意味着行业对其价值与边界已形成共识讨论协议选型要回到收敛速度、运维复杂度和安全叠加等实际线路上而不是追逐协议堆叠。1. RR 放总部、分支扩容后的规划iBGP 部署 EVPN 时RR 通常放在总部设备。分支通过 RR 交换 EVPN 路由RR 的性能上限直接决定整个控制平面的扩展能力。分支规模扩大后RR 的处理能力、内存占用和网络可达性都进入设计视野。实际工程判断中可观察分支数、路由条目量和收敛时间要求三个指标。分支从 10 个增长到 50 个RR 的会话数量和路由规模同步增长如果分支跨越多个地域RR 的单一位置可能导致某些区域绕行。分支规模达到一定量级后往往需要规划多 RR 或分层 RR这部分工作应在扩容前完成而非等性能瓶颈出现后再补。2. VXLAN 明文必须叠加 IPSec再次强调一个工程现实VXLAN 本身不加密SD-WAN 场景下需叠加 IPSec 加密。这在“安全与隧道分离”的部署要求中必须落实为具体动作即隧道配置完成后确认加密策略已挂载到对应隧道并在变更管理中把加密状态纳入检查项。一个容易暴露此问题的场景是分支与总部之间 VXLAN 隧道测试通了业务也正常但上线前没有检查加密状态。隧道的“通”掩盖了安全的“裸”。如果整段链路部分经过公网风险随之产生。安全叠加不是一个可选后补项而是隧道上线验收的一部分。3. 选型关注收敛与运维简化而非协议堆叠判断一个 SD-WAN 架构的优劣关键看收敛速度、运维简化程度和故障定界能力而不是协议类型的堆叠。协议栈里同时出现 EVPN、VXLAN、IPSec、GRE不等于方案更先进。真正需要回答的是故障发生时收敛多快、排查路径多短、运维团队能不能独立处理。在这个方向上部分 NaaS 服务商已将 VXLAN、IPSec 等协议封装在平台层面统一管理。以犀思云 NaaS 模式为参照其思路是把协议配置、隧道管理和加密叠加收拢到可视化平台用户侧不用直接面对协议堆叠的细节关注点回到端到端连通性和运维可见性。这种“协议在平台层消化、用户只面对服务界面”的思路契合成熟期 SD-WAN 的演进方向。4. 结语协议成熟期的选型视角BGP EVPN 管控制、VXLAN 管转发这一分工已经稳定。两者的职责边界清晰不存在“谁替代谁”的问题。真正需要判断的是在具体规模、收敛要求和安全场景下用不用 EVPNVXLAN用的话叠加什么安全方案以及控制面怎么规划 RR。选型重点从“要不要上 SD-WAN”转向“如何让收敛、安全和运维更可控”。协议是底座稳定可控的运行状态才是最终目标。本文由犀思云技术团队撰写含相关产品服务信息仅供技术交流。参考资料RFC 7432 — BGP MPLS-Based Ethernet VPNIETFhttps://datatracker.ietf.org/doc/html/rfc7432RFC 7348 — Virtual eXtensible Local Area Network (VXLAN)IETFhttps://datatracker.ietf.org/doc/html/rfc7348华为 SD-WAN EVPN 部署指南华为企业技术支持https://support.huawei.com/enterprise/zh/doc/EDOC1100460611
