下一代数据中心网络重构：从 EVPN-VxLAN 走向端到端 SRv6 Fabric

在过去十年的云计算演进中，SRv6的前身协议——EVPN-VxLAN几乎定义了数据中心虚拟化与多租户网络的标准底座。它打破了传统VLAN 4096的隔离上限，在三层物理网络之上构建起无感漂移的虚拟二层网络，让虚拟机与容器的跨机架迁移成为可能。

然而，随着大模型分布式训练、高密GPU算力集群以及跨数据中心协同计算的爆发，网络流量特征发生了根本性变化。传统VxLAN架构在面对海量大象流调度、跨域协议打通以及报文封装开销时，逐渐暴露出结构性短板。基于原生IPv6的SRv6（Segment Routing over IPv6）正迅速从广域网下沉至数据中心内部，有望成为新一代算力Fabric的核心底座。

EVPN-VxLAN的三大结构性瓶颈

VxLAN在通用云时代表现优异，但面对异构算力与多中心协同，结构性短板日益凸显。

跨域"协议缝合"与网关瓶颈。 DC内部跑EVPN-VxLAN，广域网跑MPLS/IP，边界网关必须解封VxLAN、剥标签、重封装。协议转译带来状态开销与单点瓶颈，DC与WAN的OAM机制割裂，端到端故障定界困难。

算力"大象流"遭遇ECMP极化。 AI训练中的AllReduce流量流数少、单流极大，VxLAN靠UDP源端口哈希分流，少量大象流极易撞至同一条链路。RoCEv2无损网络中，拥塞触发PFC反压甚至死锁，直接拉低集群算力利用率（MFU）。

封装开销与芯片解析代价。 标准VxLAN额外引入至少50字节头部，大模型梯度同步中大量小包进一步降低有效载荷比，同时加重交换机ASIC的解析深度与流水线负担。

新一代 SRv6 Fabric 的技术原理

SRv6（Segment Routing over IPv6）不是"另一种隧道协议"，而是一套基于 IPv6 的"网络导航指令系统"。

传统网络中，数据包就像没有导航的出租车，每到一个路口都要问交警（路由器）"下一站怎么走"。而 SRv6 相当于给每辆车装上了北斗导航——出发前就知道全程路线，把途经的每一个路口都写进一张"路书"里，沿途设备只负责"照单执行"，不需要自己动脑决策。

SRv6 到底比 VxLAN 强在哪？

1、Locator:Function:Args —— 一个地址，三层含义

SRv6 把网络中的一切行为，都编码成了一个 128 位的 IPv6 地址，叫做 SID（Segment ID）。这个地址不是随便编的，它内部被拆成了三段，就像快递地址的"省-市-街道"结构：

① Locator（定位符）—— "省/市"：负责找到你

告诉全网：这个节点在哪个位置，通过标准 IPv6 路由就能到达。

② Function（功能指令）—— "街道+门牌号"：负责让你干什么

• End.DT4 / End.DT6：拆包后去查 IPv4/IPv6 路由表（做三层转发，隔离不同租户）
• End.DX2：拆包后直接按二层帧转发（做二层桥接）
• End.X：三层交叉连接（类似 VPN 专线）

③ Args（参数段）—— "备注栏"：携带额外信息

可以塞进各种元数据，比如：

• 这个流属于哪个安全域？
• 需要打上什么 QoS 优先级标记？
• 遥测采样 ID 是多少？

传统网络中，定位、功能、参数需要三种不同的协议/机制来表达（IP 地址 + MPLS 标签 + ACL/NetFlow）。SRv6 把它们全部塞进了一个 IPv6 地址里，"一个地址 = 完整指令"。

2、EVPN over SRv6

控制平面依然采用成熟的 BGP-EVPN，但实现机制大幅简化：

在路由发布阶段，Egress Leaf 通过 BGP Prefix-SID 属性直接向全网通告业务 SID（例如 2001:db8:1::End.DT4）。

Ingress Leaf 收到租户数据后，直接将对应的 IPv6 SID 作为目的 IP 封装外层报文。报文在 Fabric 内部透明转发，无需在 Spine 节点上维护任何租户隔离状态。

3、SRv6 Policy

AI 算力网络的痛点，大象流撞车。SRv6 提供了确定性的流量编排手段：

• 显式路径指定： Ingress Leaf 或集中式控制器根据链路实时遥测（Telemetry）状态，在报文中压入一组经过无拥塞链路的 SID 列表（Segment List）。
• 零状态中间转发： 中间 Spine 和交换节点只需机械地读取当前 SID 转发并执行指针偏移（Segments Left 减 1），完全不需要在核心交换机上配置和下发细颗粒度的流表。

4、SID 压缩技术

如果一条路径经过 5 个节点，每个 SID 128 位，光路书就占了 80 字节。加上 IPv6 头，小报文的有效载荷比例大幅下降，MTU 也容易超标。

解决方案：C-SID 压缩（RFC 8986 / RFC 9800）

把 SID 中重复的部分（Locator 前缀）只写一次，只把变化的部分（Function）打包进地址。

SRv6 在数据中心的典型应用

AI 后端网络 —— MRC 架构

AI 大模型训练时，成千上万个 GPU 之间要频繁同步参数（AllReduce）。这些同步流量特点是：流数少、单条流极大（俗称"大象流"）。

传统网络靠 ECMP（等价多路径）来分流：看数据包的 UDP 源端口，算个哈希值，随机丢到某条链路上。一旦几条大象流哈希到了同一条链路，就像多辆重型卡车挤上了同一条窄路，堵死、PFC 反压、算力利用率暴跌。

OpenAI、微软、英伟达等联合开发的 MRC 架构（Multi-Path Routing and Congestion Control），把 SRv6 的源路由能力直接暴露给了传输层协议栈。简单说：发送端的网卡或协议栈，可以为每一个数据包独立选择路径。它根据实时监测到的链路状态（RTT、ECN 标记、队列深度），动态决定下一个包走哪条路。

容器网络 —— 阿里云 NetPila

在 Kubernetes 集群里，Pod 之间通信传统上靠 VxLAN 隧道。流程是这样的：

1. Pod A 发一个包
2. 宿主机给这个包套上一层 VxLAN 信封（写上 VNI 租户号）
3. 信封在 Underlay 网络里转来转去
4. 到达 Pod B 的宿主机，拆开信封，交给 Pod B

这就像两个人在同一栋楼里，却要写信并通过前台转交——能通，但绕、慢、额外开销大。

阿里云的 NetPila 方案做了一个巧妙的设计：把 Pod 的"身份信息"直接编码进 IPv6 地址里。这意味着：Pod 的 IP 地址本身就告诉了网络，Pod A 给 Pod B 发数据时，不需要任何隧道封装，网络设备看到这个地址，就知道该怎么路由、该应用什么策略。

跨数据中心骨干网 —— 阿里云 eCore

跨数据中心（DCI）的流量，传统上是"分段接力"：

• DC 内部：VxLAN/EVPN
• DCI 边界：协议转换（VxLAN → MPLS/IP）
• 广域网：MPLS 或纯 IP 逐跳路由

每一段都有自己的决策逻辑。应用层说"我要低时延"，但网络层听到的只是"按默认路由走"。端（服务器）和网（骨干网）之间是割裂的——服务器不知道网络状况，网络也不知道应用意图。

阿里云的 eCore 架构基于统一的 IPv6 Underlay + SRv6 Traffic Engineering，把路径选择从"网络逐跳决策"变成了"端到端可编程控制"。

• 服务器侧根据业务类型（RDMA、普通 TCP、备份流量）和 QoS 需求，在 IPv6 报文的 Flow Label 字段里打上标记
• 网络侧读取 Flow Label，自动映射到对应的 SRv6 SID-List
• 不同业务自动获得不同路径：RDMA 走低时延专线，备份流量走低成本链路

数据中心前端网络 —— DCI 简化

数据中心前端网络负责连接内部业务与外部世界（互联网、合作伙伴、其他云）。在传统架构中，DCI（数据中心互联）边界是一个协议翻译重灾区：内部流量是 VxLAN 封装，外部世界是 MPLS 或纯 IP，DCI 网关必须要经历：解 VxLAN → 剥 VNI → 查内部路由 → 重新封装 MPLS。多厂商设备在 DCI 边界经常因为协议实现细节不一致而"打架"。

SRv6 的解决方案极其简洁：让内部和外部说同一种语言——IPv6。

• 内部流量本身就是 IPv6 报文（目的地址是 SRv6 SID）
• 穿过 DCI 边界时，不需要任何协议转换
• DCI 设备从"复杂的协议网关"降级为"大容量普通 IPv6 路由器"

同时，云网关、防火墙等 NFV 实例运行在通用 Linux/x86 宿主机上，原生支持 IPv6/SRv6 内核处理。服务链引流不再需要硬编码的 PBR 规则，而是变成灵活的 SID 序列编排。

服务链（Service Chaining）

• 将“服务”本身变成SID

这是最大的差异。在VXLAN网络中，服务节点（如防火墙）是拓扑中的一个“黑洞”，流量需要通过复杂的路由策略“扔”进去。而在SRv6中，每个服务节点或其特定接口都被分配了一个全球唯一的SID，服务链本质上就是将一个包含多个服务SID的Segment List附加在报文上，由网络自动完成编排。

• 统一控制面与转发面

VXLAN Overlay网络通常需要独立的控制面（如EVPN），服务链策略也依赖于控制器下发。SRv6则实现了控制面（IGP/BGP扩展通告SID）和转发面（SID封装）的统一，简化了协议栈，使得网络能更自主地执行服务链策略。

• “无状态”的服务链

传统服务链（如通过VRF手拉手）往往需要在服务节点上维护大量状态信息。SRv6的服务链是“无状态”的，路径和服务顺序完全由报文头中的SID列表决定，服务节点只需基于当前SID进行简单转发，无需维护每个流的状态，这大大简化了服务节点（尤其是第三方设备）的设计。

AsterNOS SRv6规格与路线图

为了实现上述端到端 SRv6 Fabric 的演进， AsterNOS 制定了清晰的 SRv6 特性演进路线图。目前，AsterNOS 已完整支持传统的 SRv6 和 REPLACE-C-SID 压缩，并计划于 2026Q4 全面支持 NEXT-C-SID (uSID)，帮助企业构建面向 AI 算力时代的极简扁平化网络。