问
S9820-8C 在M-LAG环境下，穿越了peerlink的VPN实例路由，会被封装吗
3天前提问
- 0关注
- 0收藏，103浏览
- 单纯 VPN 实例路由（IPVPN/MPLS VPN 路由报文）穿过 M-LAG Peer-link 时：不会额外新增封装，只会携带原有 VPN 标签；Peer-link 本质就是一条普通跨设备二层聚合链路，仅负责打通两台 M-LAG 设备之间的二层转发通道，不对报文再封装。
- 只有流量是 VXLAN 报文 穿越 Peer-link 才会保留 VXLAN 封装；普通 VPN 路由流量穿越 Peer-link 全程原生三层转发。
- S9820-8C（H3C S9820 数据中心核心，V7 平台）完全存在「主机跨 M-LAG 接入、流量经由 Peer-link 转发、VPN 路由在全局公网表（public）路由转发」的现象，属于 M-LAG 标准转发逻辑。
一、分层拆解：Peer-link 本质与报文封装规则
1. Peer-link 链路属性
M-LAG 的 Peer-link 是两台 M-LAG 主备交换机之间的二层 Trunk 聚合链路，作用：
- 同步 M-LAG 成员端口的 MAC 表、ARP 表、VPN 路由表项；
- 转发跨设备接入主机的跨板流量； Peer-link 不具备 VPN 封装 / 解封装能力，不会对经过的 IPVPN 报文做二次封装。
2. 两种 VPN 流量穿过 Peer-link 的表现
场景 1：普通 MPLS L3VPN 业务流量
报文结构：
二层头 + MPLS VPN标签 + IP报文- 终端接入 M-LAG 设备 A，属于 VPN 实例 VPN-A；
- 目的终端接入 M-LAG 设备 B，同 VPN-A；
- 流量从设备 A 经由 Peer-link 发到设备 B： Peer-link 仅做二层透传，MPLS VPN 标签原样保留，不会新增 VXLAN、GRE、额外 MPLS 封装；
- 设备 B 收到报文后剥离外层二层头，基于 VPN 标签送入对应 VPN 实例路由转发。
场景 2：VXLAN EVPN VPN 流量（数据中心主流）
- 主机流量先在本地封装 VXLAN（VNI+UDP 外层 IP）；
- 封装完成的 VXLAN 报文穿越 Peer-link：VXLAN 封装完整保留，Peer-link 只当做普通 IP 二层流量转发；
- 对端设备收到 VXLAN 报文后再解封装。
核心定论
Peer-link 只负责二层桥接转发，永远不会主动对 VPN 路由报文新增封装；封装行为只发生在「VPN 入口 PE 节点」。
二、为什么主机流量会在 public 全局路由表转发（S9820-8C 必然出现该现象）
组网场景
两台 S9820-8C 做 M-LAG 双活，下联接入交换机 / 服务器双归接入 M-LAG 聚合组：
- 服务器上行双网线分别接入
Device-A、Device-B的 M-LAG 成员口； - 服务器发出访问跨网段 VPN 业务的报文，上行到达接入侧 M-LAG 成员端口；
- 若接收流量的 M-LAG 设备本地没有该 VPN 路由的 ARP/MAC 表项，设备会把流量送入 Peer-link 转发至另一台 M-LAG 对等设备查询路由。
转发逻辑（出现 public 全局路由的根源）
- 流量进入 Peer-link 属于跨设备二层转发，报文到达对端 M-LAG 交换机后；
- 对端交换机先在全局公网路由表（public） 完成外层路由寻址（VXLAN 外层 IP/MPLS 公网标签）；
- 匹配成功后，再剥离封装，将内层 IP 送入对应 VPN 实例进行私网路由查找。
通俗解释：
- VXLAN/MPLS VPN 分为「公网承载层（public 全局表）」+「私网 VPN 实例路由表」；
- 流量跨过 Peer-link 到达另一台 S9820 时，必然先走全局公网表完成承载层路由，再进 VPN 私网路由表。
- S9820-8C 作为数据中心高端框式设备，EVPN+M-LAG 是标准部署模型，100% 会出现该转发现象，不属于异常故障。
三、细分两种典型流量完整转发流程（S9820 M-LAG+EVPN）
模式 1：同 VPN 主机分别接入两台 M-LAG 交换机
主机 S 接入 Device-A，主机 D 接入 Device-B，同 EVPN-VPN 实例：
- S 发报文 → Device-A M-LAG 成员口接入；
- Device-A 查询 MAC 表，发现目的 MAC 在对端 Device-B，将原始二层报文通过 Peer-link 二层转发给 Device-B；
- 全程无封装，纯二层互通，VPN 实例只用来做路由同步。
模式 2：主机访问远端机房 VPN 业务（跨 EVPN VTEP）
- 主机上行至 Device-A，进入 VPN 实例；
- Device-A 查找 VPN 路由，得知远端 VTEP 为 Device-B，封装 VXLAN 外层 IP（使用全局 public 公网路由表路由外层 IP）；
- VXLAN 封装后的报文经过 Peer-link 发给 Device-B；
- Device-B 收到报文： ① 先用全局 public 路由表转发外层 VXLAN IP； ② 解 VXLAN 封装，内层 IP 送入对应 VPN 实例做私网路由转发；
这就是你观察到「流量在 public 进行路由」的完整过程。
四、补充容易混淆的关键点
- Peer-link 不会封装报文，封装动作只在 VTEP 节点完成 S9820 作为 EVPN VTEP 时，封装 VXLAN 的动作在本地 VPN 入节点执行，穿越 Peer-link 只是透传已经封装好的报文。
- 会不会出现 VPN 流量丢失 / 跨 Peer-link 不通？ 只要两台 M-LAG 设备同步了 EVPN 路由、MAC/ARP 同步正常、Peer-link 允许对应 VLAN 通行，转发完全正常； 异常场景：Peer-link 放行了业务 VLAN 但没放 EVPN VLAN，会导致跨 Peer-link 的 VXLAN 封装报文不通。
- 如何验证流量是否经过 public 表路由？
在 S9820 上抓 Peer-link 流量：
抓到 VXLAN UDP 4789 端口报文，就代表流量外层已经封装、依靠全局公网路由转发。plaintext
monitor source interface Bridge-Aggregation X both
五、总结
- VPN 路由报文穿越 M-LAG Peer-link：不会被 Peer-link 新增封装，原有 VXLAN/MPLS 封装原样透传；
- S9820-8C M-LAG+EVPN 架构中，远端 VPN 流量跨过 Peer-link 后，一定会先在public 全局路由表处理外层承载 IP，再进入 VPN 私网路由表，该现象是标准设计逻辑；
- 只有 VPN 流量需要跨 VTEP 访问远端业务时，才会触发「public 表路由 + VPN 私网路由」两段查表，同 M-LAG 本地主机互通仅二层转发、不走三层路由表。
针对您提出的关于 H3C S9820-8C 在 M-LAG 环境下，穿越 Peer-link 的 VPN 实例路由是否会被封装的问题，核心结论是：这取决于该 VPN 实例是否配置了 VXLAN 隧道（即是否作为 VXLAN 网关）。
结合 S9820-8C 的设备特性及 M-LAG 技术原理，具体分为以下两种情况：
1. 不会封装的情况（纯二层/三层 M-LAG 组网）
如果该 VPN 实例仅仅是作为普通的三层网关（例如连接服务器或普通交换机），没有配置 VTEP 和 VXLAN 隧道，那么流量在穿越 Peer-link 时不会被封装。
- 转发机制：此时 M-LAG 仅工作在二层或普通三层模式。当流量需要跨设备绕行 Peer-link 时，交换机会基于内层路由表进行常规的 IP 路由转发或二层 MAC 地址转发。
- VLAN 透传：Peer-link 作为二层链路，仅允许对应的业务 VLAN 通过，数据包保持原始的二层/三层帧格式透传。
2. 会封装的情况（VXLAN + M-LAG 组网）
如果该 VPN 实例被用作 VXLAN 网关（配置了 VTEP 接口并建立了 VXLAN 隧道），那么流量在穿越 Peer-link 时会被封装。
- 虚拟 VTEP 机制：在 M-LAG 双归接入 VXLAN 网络的场景中，两台 M-LAG 设备会被虚拟成一个统一的 VTEP。它们使用相同的虚拟 VTEP IP 地址与外界建立 VXLAN 隧道。
- 封装过程：当本地设备收到去往远端 VTEP 的流量，且需要通过 Peer-link 绕行至对端 M-LAG 设备进行 VXLAN 封装和发送时，该流量会携带内层（私网标签）和外层（公网标签）两层 MPLS/VXLAN 标签穿越 Peer-link。
关于“主机在 public 路由”的现象分析
您提到的“主机上是在 public 进行路由，S9820-8C 会出现这种现象吗”，这通常属于路由泄漏或配置不当导致的异常现象。
- 正常情况：在标准的 M-LAG + VXLAN 组网中，业务流量应严格在各自的 VPN 实例（VRF）内进行隔离和路由。
- 异常原因：如果主机或交换机出现了在 public（公网/默认路由表）中进行路由的现象，通常是因为：
- Peer-link 允许的 VLAN 与 Keepalive 链路重叠：未正确排除重叠 VLAN，导致路由表项混淆或产生环路。
- 路由泄漏：在配置跨 VPN 的路由导出/导入（Export/Import）时配置错误，导致私网路由意外泄漏到了 public 路由表中。
- Keepalive 链路配置：在 EVPN 组网中，若未将 Keepalive 相关的 VPN 实例接口配置为 M-LAG 保留接口（
m-lag mad exclude interface），也可能引发异常。
排查建议：
针对 S9820-8C，建议您登录设备执行以下检查：
针对 S9820-8C，建议您登录设备执行以下检查：
- 确认该 VPN 实例下是否配置了
vxlan相关的 VTEP 和 VSI 虚接口。 - 检查 Peer-link 的 VLAN 允许列表，确认是否包含了不必要的公网或管理 VLAN。
- 检查主机的路由表（
display ip routing-table），确认是否存在去往私网网段的错误默认路由或泄漏路由。
暂无评论
编辑答案
➤
✖
亲~登录后才可以操作哦!
确定
✖
✖
你的邮箱还未认证，请认证邮箱或绑定手机后进行当前操作
✖
举报
×
侵犯我的权益
>
对根叔社区有害的内容
>
辱骂、歧视、挑衅等（不友善）
侵犯我的权益
×
侵犯了我企业的权益
>
抄袭了我的内容
>
诽谤我
>
辱骂、歧视、挑衅等（不友善）
骚扰我
侵犯了我企业的权益
×
您好，当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时，您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱，我们会在审核后尽快给您答复。
- 1. 您举报的内容是什么？（请在邮件中列出您举报的内容和链接地址）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
- 3. 是哪家企业？（营业执照，单位登记证明等证件）
- 4. 您与该企业的关系是？（您是企业法人或被授权人，需提供企业委托授权书）
我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。
抄袭了我的内容
×
原文链接或出处
诽谤我
×
您好，当您发现根叔知了上有诽谤您的内容时，您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱，我们会尽快处理。
- 1. 您举报的内容以及侵犯了您什么权益？（请在邮件中列出您举报的内容、链接地址，并给出简短的说明）
- 2. 您是谁？（身份证明材料，可以是身份证或护照等证件）
我们认为知名企业应该坦然接受公众讨论，对于答案中不准确的部分，我们欢迎您以正式或非正式身份在根叔知了上进行澄清。
对根叔社区有害的内容
×
垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载
>
辱骂、歧视、挑衅等（不友善）
骚扰我
诱导投票
不规范转载
×
举报说明
暂无评论