Skip to main content
开放网络的先行者与推动者—星融元
加入我们 | 技术支持(Support)  TEL:(+86)4000989811

标签： 技术分享

ECMP路由场景下哈希极化（哈希不均）现象的解析

近期文章

相关概念

  1. ECMP (Equal-Cost Multi-Path Routing – 等价多路径路由)： 当路由器发现到达同一目的网络存在多条具有相同“代价”（如带宽、跳数、管理距离等）的最佳路径时，它会将这些路径都加入路由表。为了充分利用带宽并实现负载均衡，ECMP使用一种机制（通常是哈希算法）将不同的数据流分配到不同的下一跳路径上。

  2. 哈希算法： 哈希算法将一个输入（如数据包的五元组：源IP、目的IP、源端口、目的端口、协议号）映射为一个固定范围的输出值（哈希桶/索引）。在ECMP中，这个输出值决定了数据流应该走哪条路径（例如，有4条路径，哈希输出范围就是0-3）。

  3. 流的概念： ECMP通常基于“流”进行负载均衡。一个“流”通常指具有相同五元组（或其中关键几项）的数据包序列。哈希算法保证同一个流的所有数据包走同一条路径，以避免乱序问题。不同的流则可能被哈希到不同的路径。

什么是Hash极化

理解ECMP路由方式下的Hash极化现象，需要结合ECMP的工作原理和哈希算法的特性来分析。

Hash极化，又称hash不均，具体的表现是在ECMP进行多路径负载均衡时，流量并没有像预期那样均匀地分布到所有可用的等价路径上，而是呈现出明显的偏向性，导致某些路径负载过重（拥塞），而其他路径负载很轻（闲置）的现象。

为什么会出现Hash极化？

Hash极化现象的根本原因在于哈希算法的一致性与网络拓扑结构和流量模式特性之间的相互作用：

  1. 哈希算法的一致性

    • 网络设备（路由器、交换机）通常使用相同或非常相似的哈希算法（如Toeplitz哈希）和相同的输入参数（如标准的五元组）。

    • 当流量经过多个使用ECMP的网络设备（尤其是在层次化网络如Clos架构的数据中心中）时，如果这些设备使用相同的哈希算法和参数，它们对同一个数据流计算出的哈希结果（即选择的路径索引）高度一致。

  2. 网络拓扑的层次化

    数据中心常见的Clos架构是Hash极化最常见的发生场景。

    • 想象一个典型的三层Clos架构：服务器 -> Leaf交换机 -> Spine交换机 -> … -> 目的地。

    • 第一层ECMP (Leaf -> Spine): 假设Leaf有4个上行端口连接到4个不同的Spine交换机。Leaf使用ECMP和哈希算法H1将服务器流量分配到4个Spine上。目标是均匀分布。

    • 第二层ECMP (Spine -> 下一跳/Leaf): Spine交换机接收到来自Leaf的流量后，它自己也需要使用ECMP（假设也是基于相同的哈希算法H1和相同的五元组输入）将流量转发到其下一跳（可能是另一组Leaf或核心路由器）。

    • 极化发生： 问题就在这里！Leaf交换机已经基于五元组和H1把流A哈希到了Spine 1。当Spine 1收到流A的数据包后，它再次使用相同的H1算法和相同的五元组计算哈希，决定将流A发送到它的哪个下一跳。由于输入（五元组）和哈希函数（H1）都没变，Spine 1计算出的哈希结果（路径索引）极大概率会与Leaf计算出的哈希结果（选择Spine 1这个事实）具有某种相关性，甚至是相同的模式。

    • 结果： 原本在Leaf层被“均匀”分配到4个Spine的流量，在Spine层再次被哈希时，所有来自Spine 1的流量（无论它在Leaf层是从哪个端口来的）都可能被Spine 1的哈希算法再次集中分配到其少数几个下一跳路径上，而不是均匀分散到所有可用路径。 其他Spine上的情况类似。最终导致Spine交换机到其下一跳的链路上，只有少数几条承载了绝大部分来自其上游Leaf的流量，而其他链路则很空闲。这就是极化——流量在下一层被“集中”而非“分散”了。

  3. 流量模式的不均衡：

    • 哈希算法的均匀分布依赖于输入（流标识/五元组）本身的随机性。如果实际流量中存在大量具有相似特征的流（例如，大量流共享相同的源IP或目的IP），而这些特征恰好是哈希算法的主要输入，那么这些相似的流就非常可能被哈希到相同的路径上（哈希碰撞），导致该路径过载。

    • 即使没有层次化拓扑，仅在一个ECMP组内，如果流量模式本身高度偏斜（少数大流主导），哈希极化也会导致负载不均。

  4. 路径数量与哈希范围：

    • 哈希算法输出范围（桶的数量）需要与可用路径数量匹配。如果算法设计的哈希空间分布不均匀，或者路径数量不是2的幂次而哈希桶分配不合理，也可能导致某些路径被选中的概率更高。

Hash极化的影响

  1. 负载不均衡： 这是最直接的影响。部分链路拥塞，部分链路闲置，浪费了宝贵的带宽资源。

  2. 网络性能下降： 拥塞链路导致数据包丢失、延迟增加、抖动增大，影响应用性能（特别是对延迟敏感的应用）。

  3. 吞吐量瓶颈： 整体网络吞吐量受限于那些被过度使用的链路，无法达到理论上的多路径叠加带宽。

  4. 可靠性潜在风险： 过载的链路和设备故障风险更高。同时，当一条过载链路故障时，其承载的大量流量瞬间切换到其他链路，可能引发新的拥塞。

如何缓解Hash极化

  1. 使用不同的哈希因子： 这是最常用且有效的方法。为网络中的不同设备（或同一设备的不同ECMP组）配置不同的随机哈希种子。即使算法相同，不同的种子会导致相同的输入产生完全不同的哈希结果，打破了哈希结果在不同层级间的相关性。例如，Spine交换机使用与Leaf交换机不同的种子。

  2. 使用不同的哈希算法： 在支持的情况下，让不同层级的设备使用不同的哈希算法。

  3. 使用更丰富的哈希输入： 增加哈希算法的输入字段，如加入MAC地址、VLAN标签、MPLS标签、GTP TEID（移动网络）、NVGRE/VXLAN VNI（Overlay网络）、甚至包内特定偏移的字节等。这增加了输入空间的随机性，减少了因五元组相似导致的碰撞。现代设备通常支持灵活选择哈希字段。

  4. 层次化感知的哈希/负载均衡： 在Leaf层，除了五元组，可以加入Spine交换机的信息（如出端口ID或Spine的IP）作为哈希输入的一部分。这样，当流量到达Spine时，其哈希输入已经包含了路径信息，有助于Spine层更均匀地分布。这需要设备支持更复杂的哈希策略。

  5. 动态负载均衡： 超越静态的基于流的哈希，采用基于实时链路利用率或队列深度的动态负载均衡机制（如一些厂商的“自适应路由”或类似CONGA的思想）。这种方法直接感知拥塞并调整路径选择，能有效避免极化，但实现更复杂。

  6. 调整网络拓扑/路径数量： 有时增加路径数量或调整拓扑结构也能缓解问题，但成本较高。

Hash极化是ECMP在多层级网络（尤其是数据中心Clos架构）中使用相同哈希算法和参数时，流量在逐层转发过程中被反复集中到少数路径上，导致负载严重不均衡的现象。其核心原因在于哈希算法在不同层级设备上计算结果的相关性。解决的关键在于打破这种相关性，主要方法包括为不同设备配置不同的哈希种子、使用更丰富多样的哈希输入字段，以及采用更先进的动态负载均衡技术。理解Hash极化对于设计和优化高性能数据中心网络至关重要。

返回资源中心

最新动态

再谈 SONiC：生态现状与新场景扩展实践

关注星融元

SONiC（Software of Open Networking in Cloud，云端开放网络软件）由微软为其 Azure 数据中心开发，并于 2016 年开源，基于 Linux 发行版 Debian。

关于SONiC

SONiC 使用 SAI 将软件与底层硬件分离，使其能够在多供应商 ASIC 上运行。

据 Gartner 称，随着人们对 SONiC 的兴趣日益浓厚，SONiC 很有可能在未来三到六年内成为类似于 Linux 的网络操作系统。

SONiC 系统架构由各种模块组成，这些模块通过集中式和可扩展的基础架构相互交互。其中的核心基础设施是 Redis 数据库，它提供一个独立于语言的接口，支持在所有 SONiC 子系统之间进行数据持久存储、复制和多进程通信。

SONiC

Redis数据库采用“发布者/订阅者”消息传递方式，运行在SONiC系统内的各类应用程序可以只订阅所需的数据，并避免与其功能无关的实现细节，从而保持了各组件模块的独立性：每个模块放置在独立的 docker 容器中，且都是完全独立于平台特定细节而编写。

SONiC的发展前景

SONiC采用的开放、解耦的软件架构十分适应云计算对网络基础设施的需求，使得网络也开始作为一个可编程的对象，在更多新业务场景发挥出创造性的价值。

作为这样一个云原生的网络操作系统，SONiC采用的模块化方法可支持高效的故障恢复和在线升级，允许在不中断整个系统运行的情况下更换或增强特定组件。

举几个例子：用户可以升级操作系统更新、驱动程序等单个软件组件，或者动态添加新协议或应用程序，而不会影响其他模块或导致整个交换机宕机；用户也无需受限于传统单一供应商的产品路线图来推进自身的业务创新，而是可以自主控制系统的功能，并按需集成各类网络自动化和应用程序等重要工具。

SONiC 架构是否可靠？

根据由微软 Azure 网络技术研究员兼 CVP、SONiC 基金会管理委员会主席 Dave A. Maltz 领导的团队开展的一项研究，该团队对 Azure 数据中心的 18 万台交换机进行了为期三个月的跟踪。

研究发现：数据中心交换机自投入生产部署以来，至少有 3 个月保持不间断运行的概率为 98.5%；3个月后，SONiC 交换机的生存概率比非 SONiC 交换机高 1% ，并且随着时间的推移，可靠性方面的差距还在扩大。

Azure Kaplan-MeirerAzure 数据中心交换机的 Kaplan-Meirer 生存曲线

SONiC 的生态现状

SONiC 生态系统已形成多元化的社区和商业版本，暂无统一的公开统计，下面仅简要列举。

社区版

GitHub (https://github.com/sonic-net)

微软Azure SONiC

作为SONiC的原始创建者，微软的发行版广泛应用于Azure全球数据中心，是社区最核心的参考实现。

星融元 Asterfusion SONiC（AsterNOS）

提供基于SONiC的软硬件一体化的“交钥匙”商用解决方案，面向AI智算、通算云、园区网等场景深度优化，强调降低开放网络技术的使用门槛。

各大云服务商自研定制版

例如腾讯、阿里等云服务商均基于SONiC构建数据中心网络，运行了内部定制版本的SONiC。

Hedgehog Enterprise SONiC

来自初创公司Hedgehog，主要专注于企业边缘场景，提供简化部署的发行版，适配AI计算等新兴需求。

SONiC 的商用场景扩展：心远，路自宽

正如上文，研发资源充足的大型云服务商会为自己的超大规模数据中心定制开发 SONiC —— 尽管SONiC使用 SAI 实现了网络侧的软硬件解耦，但在不同的交换机硬件上完美运行SONiC，仍需要大量的深度硬件协同适配工作。

社区响应慢、开发门槛高，正是阻碍普通企业享用这一开放网络技术红利的直接因素。

星融元 Asterfuson 于 2017 年加入社区，是全球极少数有能力提供基于SONiC的、软硬一体的开放网络解决方案厂商，以“交钥匙”的方案降低SONiC操作和使用门槛：

一方面持续基于 SONiC 开放架构补充大量面向生产环境的功能增强，不断提升易用性和可靠性；另一方面也结合硬件设计能力，推出覆盖AI计算、云计算，企业园区全场景的系列化产品和完整方案，让开放网络变得“人人可用”、“开箱即用”。

AsterNOS

AsterNOS与社区版对比AsterNOS 与SONiC社区版主要能力对比-表1
AsterNOS与社区版对比AsterNOS 与SONiC社区版主要能力对比-表2

数据中心（AsterNOS-DataCenter）

主要提供 L2/L3/VXLAN/Routing/EVPN 等云数据中心所需的各种功能，以及对智算等场景的RoCE、智能路由等特性的增强支持（未来也将主要基于此版本平滑支持下一代以太网协议，例如超以太网）。

51.2T 800G AI智算交换机软硬件系统设计全揭秘

企业园区（AsterNOS-Campus）

将SONiC的核心原则——开放性、易用性和灵活性引入园区。提供VXLAN 和 BGP-EVPN 虚拟化，实现灵活的逻辑网络编排；选定型号上采用 MPLS，可实现运营商级场景的无缝 WAN 集成；部分型号采用 PTP（精确时间协议），为关键应用提供高精度时间同步的网络。

从数据中心场景到园区网络，这不仅仅是“更换操作系统”，而是一次深度集成和系统级重构。我们针对资源受限的硬件平台（甚至是 1G 端口的接入交换机）移植并优化了SONiC，并围绕其他开放网络技术（例如OpenWiFi/OLS）提供端到端的新一代云化园区网整体解决方案。

开源开放技术栈下的园区多租户网络方案设计

最新实践：边缘路由（AsterNOS-VPP*）
从硬件角度来看，业界已有很多强大的基础平台如各类 DPU 网卡、高性能服务器或虚拟化主机；在软件方面，VPP等数据平面解决方案也已经显著成熟，两者共同为构建开放路由平台奠定了坚实的基础。

然而，SONiC 仍难以在这些新平台上提供完整的路由功能——市场上明显缺乏一种能够真正取代昂贵的封闭式黑盒路由器的商用级、成熟且用户友好的开放式路由解决方案。

AsteNOS-VPP 则是目前我们围绕SONiC的最新实践。具体而言是将 SAI 接口集成到 VPP 上，使基于 SONiC 的 AsterNOS 能够从交换机 ASIC 平台扩展到具有完整路由功能的 DPU 和服务器平台（如星融元ET系列:ET2500 系列开放智能网关平台） 。

VPP

AsterNOS 的交付模式

软硬一体化交付

AsterNOS可以运行在星融元自研的交换机硬件上，形成一体化的整机系统交付使用，用户享有厂商提供的一站式服务。

软件化交付

AsterNOS也具备运行在业界主流的白盒交换机硬件上的能力，因此也能以独立的软件形态交付给用户使用。当前主要兼容Celestica 和 Accton 两大品牌。

虚拟化试用 （vAsterNOS）

该模式的主要目的是便于用户快速了解AsterNOS、体验实际操作。即在星融元的私有环境里部署AsterNOS的虚拟化版本（vAsterNOS），并由管理元针对用户的试用要求搭建模拟网络，将操控权限交给用户试用。

如需获取本地运行的vAsterNOS（数据中心/园区版本），可自行下载 vAsterNOS；AsterNOS-VPP 试用，请与我们联系。

【参考文档】

基于路径感知的动态智能选路技术赋能AI智算网络

近期文章

在传统数据中心网络（尤其是Leaf-Spine架构）中，东西向流量的高效调度是核心挑战。传统BGP协议虽能实现路由可达性，但缺乏对路径质量的动态感知能力，导致流量分配不均、高延迟链路未被规避等问题。为提升网络资源利用率，动态智能选路技术应运而生。该技术基于BGP扩展机制，通过实时收集路径质量指标，实现数据流的智能调度，显著优化高吞吐场景（如分布式存储、AI训练）的性能。

BGP扩展能力创新

  • 核心属性：定义 Path Bandwidth Extended Community（路径带宽扩展社区属性），类型字段值固定为 0x0005（高8位0x00保留，低8位0x05标识带宽属性）。
  • 数据结构：1️⃣ Global Administrator：4字节，存储发起路由宣告的AS号，用于标识路径源。2️⃣ 路径质量值：4字节，以 IEEE 754浮点数格式 存储带宽信息，单位为 GB/s，精确表征链路传输能力。

路径质量同步算法流程

算法逻辑

以NIC1与NIC2通信为例：

  1. 终端注册：NIC2向直连交换机Leaf2宣告自身IP地址；
  2. 质量加权：Leaf2计算 NIC2→Leaf2下行链路质量 × Leaf2下行口权重系数，附加至路由信息；
  3. 跨层传递：Leaf2将携带质量值的路由通告至Spine；Spine叠加质量：Spine→Leaf2链路质量 × Spine权重系数 + 已有路径质量值；
  4. 路由汇总：Spine将聚合后的路由通告至Leaf1，Leaf1最终生成含完整路径质量的路由表，指导流量转发。注：权重系数按端口类型动态配置，实现差异化路径评估。
  5. 交换机端口分类与系数配置：为精准量化路径质量，将端口划分为三类并赋予可调系数：

端口类型作用系数意义
Leaf上行口连接Spine影响跨设备链路质量权重
Leaf下行口连接服务器/终端决定终端接入链路质量权重
Spine口连接Leaf控制核心层链路质量聚合权重

灵活性：管理员可根据网络架构需求（如高带宽优先/低延迟优先）动态调整系数。

基于BGP扩展的动态路径优化

  • 精细化路径选择：通过浮点数精确量化带宽，替代传统“跳数”或静态成本值，避免ECMP（等价多路径）在非对称链路中的负载失衡问题。
  • 实时动态优化：链路质量变化（如拥塞、故障）可快速通过BGP更新传递，触发路径重计算，提升网络韧性。
  • 兼容性与扩展性：基于BGP扩展实现，无需改造底层协议，平滑兼容现有网络设备，支持大规模部署。

优化高吞吐场景

  • 分布式计算集群：优化AI训练任务中参数服务器与工作节点的通信路径；
  • 金融交易系统：确保低延迟链路优先承载订单流量；
  • 云数据中心：提升虚拟机迁移和存储复制的吞吐性能。

优化智算中心：动态智能选路新方向

动态智能选路技术通过扩展BGP的路径质量感知能力，解决了传统数据中心网络“只连通、不优化”的痛点。其分层加权算法与可配置端口系数设计，为复杂流量调度场景提供了高适应性解决方案，是构建高性能、自优化数据中心网络的关键演进方向。

【参考文献】
想了解更多智能选路技术，可访问

https://asterfusion.com/a20250528-flowlet-alb/

返回资源中心

最新动态

交换机上的 DHCP 侦听（DHCP Snooping）功能和配置示例

近期文章

什么是 DHCP 侦听

DHCP侦听（DHCP snooping）是一种部署在以太网交换机上的网络安全机制，用于阻止未经授权的 DHCP 服务器为客户端分配 IP 地址。该机制通过检查 DHCP 消息并仅允许来自受信任端口的 DHCP 消息通过，从而防止非法 IP 地址分配，确保网络环境安全稳定。

为什么需要DHCP侦听？

在企业、校园甚至公共网络中，与 DHCP 相关的问题并不少见，而且它们可能会造成严重的网络中断。有时，仅仅是配置错误的设备意外地充当了 DHCP 服务器，分配了错误的 IP 地址，导致连接中断。有时，问题更为严重，例如攻击者设置了恶意 DHCP 服务器，通过虚假网关或 DNS 服务器重新路由用户，从而为中间人攻击打开了方便之门。即使是客户端手动为自己分配静态 IP 地址，也可能造成混乱，引发冲突，并使网络安全管理更加困难。

项目 DHCP 静态 IP
分配方法 由服务器自动分配 手动配置
管理努力 低，适合大规模部署 高，需要单独设置
解决稳定性问题 每次设备连接时可能会发生变化 固定不变
设置效率 快速、即插即用 速度慢，需要手动输入
适合 最终用户设备、动态环境 服务器、打印机、关键设备
安全 需要配合保护机制（例如 DHCP 侦听） 更可控，但有手动配置错误的风险

DHCP 侦听的好处：

  • 阻止恶意 DHCP 服务器干扰网络。
  • 确保客户端收到准确的 IP 地址和网络配置。
  • 通过降低攻击风险来增强网络安全。

DHCP 侦听如何工作？

要真正理解DHCP 监听的工作原理，首先必须清楚了解DHCP（动态主机配置协议）的工作原理。当设备加入网络且尚未获得 IP 地址时，它会发起与 DHCP 服务器的对话——这是一个四步握手过程，包括：发现 (Discover )、提供 (Offer)、请求 (Request)和确认 (Acknowledge )。可以将其视为设备和服务器之间获取 IP 身份的快速协商过程。下图详细分析了此动态交换过程中每个步骤的具体细节。

在启用 DHCP Snooping 的网络中，交换机接口分为两个主要角色：可信端口和不可信端口。

  • 可信端口：这些端口连接到合法的 DHCP 服务器或上行链路设备（例如路由器或核心交换机），并被允许发送 DHCP 服务器消息（例如 DHCP OFFER、DHCP ACK）。
  • 不受信任的端口：这些端口连接到常规客户端（例如，PC 或打印机），并且仅限于发送 DHCP 客户端消息（例如，DHCP DISCOVER、DHCP REQUEST）。
  • 默认情况下，所有端口都是不受信任的；必须手动配置受信任的端口。

DHCP 消息过滤：

  • 来自不受信任端口的 DHCP 服务器消息（例如 DHCP OFFER、DHCP ACK）将被丢弃，以防止恶意 DHCP 服务器运行。
  • 客户端请求（例如，DHCP DISCOVER、DHCP REQUEST）可以来自不受信任的端口，但服务器响应只允许来自受信任的端口。

DHCP绑定表：

  • DHCP 侦听维护一个绑定表，其中记录每个客户端的 MAC 地址、分配的 IP 地址、租用期限、VLAN 和端口信息。
  • 该表用于验证后续流量，防止 IP 地址欺骗。

与 IP Source Guard 集成：

DHCP 侦听通常与 IP 源防护配合使用，根据绑定表过滤流量，仅允许分配的 IP 地址从客户端发送数据，阻止未经授权的 IP。

支持 DHCP  option 82（可选）：

DHCP 侦听可以插入或处理 DHCP option 82（中继代理信息），为 DHCP 服务器提供有关客户端端口和交换机的详细信息，从而实现更精确的 IP 分配。

DHCP 侦听可以防范哪些常见网络攻击

DHCP 侦听可有效缓解以下网络威胁：

恶意 DHCP 服务器攻击：

  • 工作原理：攻击者设置未经授权的 DHCP 服务器来分发不正确的 IP 地址、网关或 DNS 服务器。
  • 影响：客户端流量被重定向到攻击者的设备，从而实现 MITM 攻击、流量拦截或 DNS 欺骗。
  • 防御：DHCP 侦听会丢弃来自不受信任端口的服务器消息，仅允许受信任的端口发送 DHCP 响应。

DHCP 饥饿攻击：

  • 工作原理：攻击者利用 DHCPDISCOVER 请求淹没网络，耗尽 DHCP 服务器的 IP 地址池。
  • 影响：合法客户端无法获取IP地址，导致网络服务中断。
  • 防御：当与端口安全或每个端口的速率限制 DHCP 请求相结合时，DHCP 侦听可以防止过多的流量压垮服务器。

中间人（MITM）攻击：

  • 工作原理：恶意 DHCP 服务器分配虚假网关或 DNS 服务器，通过攻击者的设备路由客户端流量。
  • 影响：攻击者可以监控、修改或重定向客户端通信。
  • 防御：DHCP 侦听确保仅处理受信任的 DHCP 消息，从而阻止恶意配置。

IP欺骗攻击：

  • 工作原理：客户端手动配置未经授权的 IP 地址来冒充合法主机。
  • 影响：这可能导致 IP 冲突、网络中断，或成为进一步攻击的垫脚石。
  • 防御：通过与 IP Source Guard 和 DHCP 绑定表集成，DHCP Snooping 可以阻止来自未经授权的 IP 地址的流量。

DHCP 侦听的应用场景

  1. 公共网络：在咖啡店、酒店或共同工作空间等环境中，恶意用户可能会部署恶意 DHCP 服务器来窃取数据或发起攻击。
  2. 企业网络：具有多个部门或 VLAN 的大型网络依靠 DHCP 侦听来确保客户端连接到正确的 DHCP 服务器。
  3. 高安全性环境：在需要遵守数据保护法规和其他有保密等级要求的环境中，DHCP 侦听功能有助于防止未经授权的访问。
  4. 防范 DHCP 欺骗：它减轻了客户端被重定向到恶意网关的风险，增强了整体网络安全性。

配置示例

传统方式-手动配置

configure Terminal #进入系统配置视图
dhcp snooping enable{v4|v6} #启用DHCP Snooping功能，默认禁用。
interface ethernet  interface-id  #进入接口视图
dhcp-snooping enable #启用DHCP Snooping功能，默认禁用。
dhcp-snooping trusted #设置端口的信任状态，默认不信任。

sonic# configure terminal
sonic(config)# dhcp snooping enable v4
sonic(config)# interface ethernet 20
sonic(config-if-20)# dhcp-snooping enable
sonic(config-if-20)# dhcp-snooping trusted

云化配置方式 – 图形化配置

星融元的云化园区网络解决方案，通过一个开源、开放架构（基于OpenWiFi）的网络控制器来为有线无线网络设备下发配置，进行开局配置时在交换机上会默认开启DHCP Snooping，有效防止 DHCP Server 仿冒者攻击，使 DHCP 客户端能够通过合法的DHCP 服务器获取 IP 地址，管理员无需关注不同设备的信任接口与非信任接口，而是通过控制器的拓扑信息自动生成。

ACC

根据当前网络的所需的安全等级，管理员可在控制器界面上自行选择是否还需要开启ARP检测(DAI)和IP源攻击防护(IPSG)功能，该功能主要是通过全局的 DHCP Snooping 表项判断主机是否合法，不仅可以防止恶意主机伪造合法主机访问网络，同时还能确保主机不通过自己指定 IP 地址的方式来访问或攻击网络，造成可能的IP 地址冲突。

更多配置流程请参考：完整流程揭秘：30分钟搞定中大型园区网络业务开通，可行吗？

返回资源中心

最新动态

收藏备查！精要解读超以太网联盟（UEC）1.0 规范（2025Q2）

关注星融元

UEC（Ultra Ethernet Consortium） 在 Linux 联合开发基金会 (JDF) 下运营，并作为标准开发组织运作。UEC 主要基于以太网，同时借鉴了其他一些规范或行业经验来构建规范标准。

超以太网（Ultra Ethernet）系统概览

一个超级以太网系统的组成如下。一个集群（Cluster）由节点（Node）和网络（Fabric）组成，节点通过 Fabric Interface 连接到 UEC 网卡，一个网卡中可以有多个逻辑的网络端点（Fabric End Point，FEP）。网络由若干平面（Plane）组成，每个平面是多个 FEP 的集合，通常通过交换机互联。

uec

集群可以两种不同的模式来工作，分别是并行作业模型（下图左）和客户端/服务器模式（下图右），两者可以共存；job 代表一组分布在多个端点上的协作进程，虽然功能上与 VXLAN 类似，但它利用的是 UEC 网卡内的交换端点 (FEP) 来实现。

uecuec

超以太网网络结构使用等价多路径（ECMP）路由进行负载平衡，其中熵值由 UET （超以太网传输层）拥塞管理子层（CMS）管理。CMS 希望UE交换机支持 IETF RFC 3168中规定的显式拥塞通知（ECN），但有一个额外的限制，即在 dequeuing 而不是 enqueuing 时标记拥塞的数据包。

流量类型（Traffic Class）体现在网卡和交换机内用于区分数据包传输的不同机制和资源（例如队列、缓冲区、调度器），并且依此进行优先级排序。超以太网主要依靠 IP 报头中的 DSCP 字段来识别所接收数据包的流量类别，下图即展示了从应用程序请求的流量类别，到网卡和交换机上链路层可用的流量类别之间的映射关系。

uec

超以太网协议栈概览

根据下图协议栈框架，我们将按照自顶向下的顺序，分层挑出重点介绍。

对比去年年底的UEC草案框架，可以明显看到超以太网 1.0 版本删去了“在网集合通信”（INC, In-Network Collectives）、物理层的多通道200Gb/s传输（因为并非官方标准）。

揭秘超以太网联盟（UEC）1.0 规范最新进展（2024Q4）

uec

01 软件层

超以太网软件层的一个关键构建模块是开放架构接口 (Open Fabric Interfaces)，也称 LibFabric。

Libfabric 定义了一套面向高性能并行和分布式应用程序的通信 API，其主要目标是提供一个统一的接口，让开发者能够方便地构建应用，而无需关心底层具体的传输协议和硬件细节。现有的 LibFabric 已经可对接 AI 或 HPC 集群所需的各类高性能通信库，例如 NCCL（来自 Nvidia）、RCCL（来自 AMD）、MPI（原始超级计算并行通信）、Open SHMEM（共享内存）和 UD（不可靠数据报）。

uec

UEC 1.0 规范中确定的 Libfabric API 基线版本是 v2.0 ，并将与 Libfabric 社区保持合作，允许集群中的Endpoint（网卡）与 AI 框架和 HPC 工作负载进行交互；此外一些规范内的可选功能还需要交换机支持（例如数据包修剪），为此，网络操作系统（NOS）需要对应新增扩展。

  • 在网卡侧运行的软件栈： 在操作系统内核态实现网卡驱动，在用户态基于Libfabric扩展实现支持上层的xCCL、MPI、SHMEM等应用。

uec

  • 支持超以太网功能的交换机软件栈：可以看到大体是继承了SONiC的架构。这部分的主要关注在于控制平面上对控制器的支持，数据平面升级 SAI（Switch Abstraction Interface）API以支持增强的芯片级的超以太网特性。

uec

超以太网兼容交换机在两种类型的物理网络中运行：

  1. 数据平面网络：通过超以太网兼容的交换机将FEP彼此连接的网络。该网络承载各种工作负载的应用流量，并针对本规范进行了优化。
  2. 交换机管理网络：每个交换机至少提供一个专用以太网端口，用于连接如SDN控制器、Fabric管理器、遥测采集器、SNMP服务器和其他负责管理基础设施的设备。该网络对延迟不敏感，通常对带宽要求较低。

02 传输层（UET）

传输层是超以太网协议栈的核心，它分为了以下几个子层。

uecuec

语义子层 （SES）

SES子层旨在通过 Libfabric 映射集成到广泛部署的 A I框架和 HPC 库中，是 UET 和 Libfabric 之间的主要接口。它使用 Libfabric 的应用程序通过网络交换消息，并使用流行的零拷贝技术将这些消息直接放入彼此的缓冲存储器中。

数据包传输子层（PDS）

通过UET分层模型和相关库，应用程序可以选择最适合其需求的传输协议功能。PDS子层定义了一种具有多种操作模式的协议，提供可靠无序RUD、可靠有序（ROD）、幂等可靠无序（RUDI）、不可靠无序（UUD）几种组合模式的数据包传输服务。

拥塞控制子层（CMS）

UET 定义了一种端到端的拥塞管理解决方案 UET-CC（UET Congestion Control），用于解决有损以太网中的数据包缓冲区拥塞问题。其目标是实现较高的网络效率，减少数据包丢失，并确保竞争流之间的合理公平性。

拥塞管理可分为以下几个部分，由端侧硬件和交换机配合完成。

  • 网络遥测： 确定端侧和网络路径上的拥塞状态；该信息可在发起方、网络路径上的交换机节点或目的处收集和使用。
  • 基于发送方的窗口： 控制最大未确认数据量，以字节为单位。
  • 接收侧的Credit拥塞控制： 根据接收方的能力通知发送方调整速率。控制向特定目标传输数据的速率，以更直接地控制传输中断。
  • 多路径路径选择： 利用自适应的数据包喷洒修改数据包的传输路径，重新路由到其它路径上，绕过拥塞点。

传输安全子层（TSS）：

UET采用了新的密钥管理机制，允许在参与作业的大量计算节点之间高效共享密钥。推荐的加密算法是后量子（post-quantum） DES 密码。

03 网络层

超以太网的网络层功能规范是可选模块，没有对网络层进行任何更改（依然是运行IP网络），该部分主要讨论的是数据包修剪（Packet Trimming）。

网络交换机在繁忙的端口转发数据包之前，会将其存储在缓冲区中，且受到芯片面积的限制。如果缓冲区无法容纳到达的数据包，交换机要么丢弃数据包，要么向上游端口发出暂停流量信号。众所周知，这两种解决方案都存在性能问题。

数据包修剪功能即是超以太网定义的一种应对交换机缓冲区不足的机制，是拥塞通知的一种附加机制，用于在网络过载时减少数据负载。

简言之是允许交换机截断有争议的数据包，修改截断数据包的 DSCP 字段，并将截断数据包作为拥塞信号转发到目的地。数据包修剪提供的拥塞信息比ECN多得多。对于交换机来说，数据包修剪是可选的，而对于 FEP 来说，接收修剪后的数据包则是必须的。

修剪后的数据包通常由上层协议消耗，以确保快速重传丢失的数据包。因此，在启用修剪功能时，这些协议必须具有修剪感知能力，并且必须能够根据收到的修剪数据包识别出原始数据包。

数据包

所以，其中有个关键的 MIN_TRIM_SIZE 必须配置为一个合适的值，以确保在修剪后不影响下一步操作。这个值需要交换机根据每个数据包的封装类型动态地确定，设置为足够保留所有相关传输头所需的大小。

04 链路层

超以太网规定的链路层旨在通过链路级的数据包替换和交换机之间的流量控制来提升整体性能链路层，这些都是可选功能，并且距离完全支持这些功能的产品得以商用还需要较长的时间。

链路层重试（LLR）

LLR 机制基于帧。该机制下，从 MAC 客户端发出的的每个帧都要进行评估。如果 MAC 客户端不希望对帧进行 LLR，或该帧被归类为不符合 LLR 条件，那么该帧将作为标准以太网帧发送。如果帧符合 LLR 条件，则会被分配一个序列号，并存储在重传缓冲区中，以便在对端未收到帧时进行快速重传。

基于Credit的流量控制（CBFC）

UE 传输（UET）层的定义是利用从源端重传数据包，支持无序到达和拥塞控制等组件，来提供有损网络下的端到端可靠数据包传送（而逐跳链路是尽力而为的，允许因拥塞而丢弃数据包)。在许多情况下，按优先级进行链路层的无损数据包传送也很有用，例如小型网络和较低负载的场景由此可以简化网络管理和端侧配置及其缓冲区要求。

CBFC 是在逐跳基础上实现无损数据包传输的一种方法，可以消除端到端重传的可能以及与之相关的延迟，其大致机制是：发送方以credit为单位跟踪接收方的可用缓冲空间，只有当接收方有足够的缓冲空间时，发送方的数据包调度器才可以从无损 VC 队列中调度数据包进行传输。

uec

超以太网链路协商

该规范提倡使用描述所需和可选功能的“配置文件”，从而在所有网络实体之间检测、发现和达成共识，以便与配置文件支持的功能进行互操作。

05 物理层

规范中主要推荐遵循802.3/db/ck/df规范的多通道100Gb以太网，建议使用多个100Gb以太网通道，并遵循IEEE 802.3/db/ck/df标准。

星融元 与 UEC

作为 UEC 成员单位，星融元提供的超低时延数据中心交换机（CX-N系列）采用高性能的25G-800G 端口速率规格网络硬件，搭载为生产环境深度调优的企业级SONiC发行版和多项 EasyRoCE 特性，提供灵活、广大的升级空间，未来将平滑演进与新一代以太网标准保持同步。

RoCE

动态感知+智能决策，一文解读 AI 场景组网下的动态智能选路技术

关注星融元

1. AI时代的网络进化

1.1 传统网络为何无法承载AI流量？

拓扑

在传统数据中心网络中，数量众多的小流使得基于流的负载均衡技术，即使不感知网络的实际状态，仍能实现较好的负载均衡和拥塞避免效果。

而AI场景流量特征的巨大差异（高带宽利用率、少数大象流等）导致传统负载均衡技术失效，从而出现极端的负载分担不均衡，而且这种不均衡一旦引发网络丢包，就会对整体 AI 模型的任务完成时间带来显著的负面影响。因此业界越来越重视 AI 场景组网的负载均衡算法优化方案，以实现流量更加均衡的负载在多条路径中。

1.2 动态感知与智能决策的融合

动态智能选路技术是一种基于感知路由的负载均衡技术，通过使用组网中交换机感知到的路径质量，来调整本地交换机的路径选择，并支持动态加权负载均衡方式平衡流量负载。

考虑到数据中心以及运营商已经习惯使用 BGP 作为数据中心网络的底层路由协议，动态智能选路技术以 BGP 为基础，通过 BGP 扩展能力，定义了一个新的扩展社区属性，基于多维度高精度测量值综合评价路径质量，通过 BGP 协议的扩展社区属性进行传递，用于指导后续业务流量的转发，提高整网负载均衡效率，减少应用响应时间。

2. 如何实现智能流量调度

当前网络均衡的主流技术有以下三种：

  • 逐流 ECMP 均衡，是当前最为常用的负载均衡算法，基于流量的五元组进行 HASH 负载均衡，在流链接数量较多的场景下适用，它优势在于无乱序，劣势在于流数量较少时，例如AI训练场景下，存在 HASH 冲突问题，网络均衡效果不佳。
  • 基于子流 flowlet 均衡技术，它依赖于子流之间时间间隔 GAP 值的正确配置来实现均衡，但如果网络中全局路径级时延信息不可知，因此 GAP 值无法准确配置。
  • 逐包 ECMP 均衡，理论上均衡度最好，但实际在接收端侧存在大量乱序问题。

星融元CX-N系列RoCE交换机（SONiC-Based）选用的动态智能选路创新方案结合了逐流 ECMP 均衡和基于子流 flowlet 均衡提出动态WCMP（Weighted Cost Multipath）和基于flowlet 的 ALB（Auto Load Balancing），下面将介绍具体相关技术。

2.1 路径质量测量

基于过去在用户生产网 AI 集群的长期实践与观察，动态智能选路技术引入带宽使用情况、队列使用情况、转发时延等在AI集群网络中影响较大的参数，作为计算因子用于网络路径质量综合评价。

2.1.1 统计计数

带宽使用情况、队列使用情况基于 ASIC 硬件寄存器统计计数，精度可达百毫秒级。ASIC 硬件寄存器实时统计端口转发计数和队列转发计数，控制面 SONiC 软件系统通过 SAI 接口以亚秒级的精度读取 ASIC 计数并存入 redis 数据库，如下图所示。

统计计数

动态智能选路控制面程序使用 ASIC 统计计数进行接口质量衡量，并将结果通过 BGP 宣告出去。如果按照统计计数的亚秒级精度进行 BGP 宣告则整网控制面压力较大，所以目前使用秒级间隔进行 BGP 宣告，端口转发计数和队列转发计数均选取多个数据点进行加权平均（越靠近计算时间点的数据权重越高）。

2.1.2 带内遥测

转发时延计算因子基于INT（In-band Network Telemetry）技术，精度可达纳秒级。HDC（High Delay Capture）是一种能捕获 ASIC 中经历高延迟的数据包信息的 INT 技术。

通过使用 HDC，星融元交换机能够捕获任何超过用户指定延迟阈值的数据包的延迟信息，并将原始数据包的前150字节连同元数据（包含出入端口、时延等关键信息）作为 HDC 数据包发送到收集器。

INT

动态智能选路技术在星融元交换机上开启 HDC 功能，并将 CPU 作为 HDC 的收集分析器，通过分析 HDC 报文实现高精度测量交换机转发时延，并将时延信息作为路径质量评价因子，提高路径质量评价精度。

HDC

命令行配置 HDC 功能控制INT进程运行，之后通过 socket 连接进行收包循环，将收取到的报文进行解析并将关键信息（出入端口、转发时延等）写入数据库。

2.2 路径质量同步

动态智能选路技术以 BGP 为基础，通过 BGP 扩展能力，使用一个新的扩展社区属性（Path Bandwidth Extended Community），用来指示通往目的路径的质量和。该扩展社区属性扩展类型字段高八位的值为 0x00（暂未使用），低八位的值为 0x05。在Value Field字段中，Global Administrator 子字段的值表示 AS 号。路径质量使用4个字节，以 IEEE 浮点格式，单位为GB/s。

路径质量同步算法逻辑如下图所示：

算法逻辑

当 NIC1 与 NIC2 通信时，NIC2 首先将自身IP宣告给 Leaf2，Leaf2 携带对应链路质量（指向 NIC2 的链路质量乘以 Leaf2 下行口权重）将 NIC2 IP 宣告给 Spine，Spine 携带对应链路质量（指向Leaf2的链路质量乘以 Spine 权重加上路由信息中已经携带的值）将 NIC2 IP 宣告给 Leaf1，Leaf1 汇总路径质量并生成路由指导转发。

动态智能选路技术将两层 Leaf-Spine 组网中的交换机端口分为了三类：Leaf 上行口、Leaf 下行口和 Spine口，每种类型端口赋予不同的计算系数，且每种端口的计算系数可配。

2.3 动态WCMP

负载分担（Load Balance）是指网络节点在转发流量时，将负载（流量）分摊到多条链路上进行转发，要在网络中存在多条路径的情况下，比如all-to-all流量模型下，实现无损以太网络，达成无丢包损失、无时延损失、无吞吐损失，需要引入该机制。数据中心中常用的负载分担机制为等价多路径路由 ECMP。

WCMP 能够将流量按照比例在不同链路上进行转发，ECMP是它的特例。在动态智能选路技术中，WCMP 根据路径质量来动态调整路由的权重，从而实现更为灵活的负载均衡。

WCMP

如上图所示，当NIC1与NIC2通信存在两条路径时，假设根据 [2.2路径质量同步] 中的算法逻辑在 Leaf1 中计算出指向NIC2的红色路径综合质量为38，指向NIC2的绿色路径综合质量为80，最终下发WCMP时两条路径的权重比为3：7。

同时随着整网流量不停的变化，路径质量也会随之变化，这些变化最终都会转变成路径质量通过 BGP 汇总到每一台 Leaf，从而在 Leaf 上生成动态 WCMP 路由指导流量转发。

2.4 异常路径剔除

当路径的综合质量小于约定的系数时，我们认为该条路径在 AI 场景下不再可用，判定为异常路径，需要剔除，剩余路径继续实现动态 WCMP 进行流量转发，当路径综合质量正常后，恢复这⼀路径。剔除短期内此路径不可⽤，造成少量浪费，但是避免了异常路径导致的路径拥塞甚至丢包等更为严重的后果。

异常路径剔除

如图所示，当 Leaf1 与 Leaf2 通信存在四条路径时，假设根据 [2.2路径质量同步] 中的算法逻辑在 Leaf1 中计算出四条路径综合质量分别为4.5、55、65和75，此时红色路径会被剔除，剩下的三条路径根据各自路径质量形成 WCMP。

2.5 智能负载均衡

LB技术实现基于 flowlet 的负载分担，ALB 通过在 ASIC 中实时测量不同端口上负载和时延，将 flowlet 路由到负载更⼩或时延更低的链路上，在传统 ECMP 的基础上从⽽实现更精细的流量调度和负载均衡。

ALB

如图所示，通过ALB技术，在出端口感知瞬时、平均负载以及队列的瞬时、平均延迟，并将数据同步给 Ingress，进行出端口的选择。同时 ALB 还支持端口 fail-over，出端口链路故障，会主动触发端口流量的重分配。

2.6 虚拟化

前端⽹络通常要⽀持多租⼾，将不同的 GPU 分配给不同⽤⼾。动态智能选路技术采⽤ VRF 实现多租⼾的隔离，每个用户对应分配一个 VRF。

VRF

如图所示（NIC和GPU一对一，实际 Leaf 与 NIC直连，此处省去 NIC，下同），组网承载两个用户的流量，user1 对应 vrf1，使用1.1.1.0/24和2.2.2.0/24网段对应的两个 GPU，user2 对应 vrf2，使用3.3.3.0/24和4.4.4.0/24网段对应的两个GPU。

通过用户配置将使用的 GPU 对应的网段划分进用户VRF，通过ASIC中的 PRE ACL 对进入交换机的流量进行区分，所有源IP处于 1.1.1.0/24 和 2.2.2.0/24 网段的流量打上 vrf1 的标记，所有源IP处于 3.3.3.0/24 和 4.4.4.0/24 网段的流量打上 vrf2 的标记，使得对应用户流量只能在对应VRF中进行查表转发，实现租户隔离。

3. 应用场景

3.1 动态WCMP如何化解流量洪峰？

以 256 个400G的GPU端口数量为例，整体网络架构采用两层Clos网络架构，按照下行端口与上行端口 1:1 的收敛比设计。在保证网络高吞吐、高带宽的基础上，1:1 的带宽收敛比能够避免因为带宽不对称导致的性能问题。

产品型号可以选择星融元CX864E-N 或 CX732Q-N 两款，CX864E-N 提供更高的端口密度以及扩展性，CX732Q-N 在满足高带宽的接入需求同时，为用户提供更高的性价比。下面以 CX732Q-N 组网为例：

动态ECMP

假设 Server1 的 GPU1 要与 Server17 的GPU1通信，按照传统 ECMP 的逻辑，流量会选择Spine中的一个然后到达 Leaf17，传统 ECMP 不会感知路径实时状态，所以 AI 场景下的少量大象流极易被均衡到同一 Spine 上从而导致 Leaf1 上行端口拥塞甚至出现丢包。

动态WCMP-02

如果交换机开启了动态智能选路技术，当 Server17 将 GPU1 的路由信息通过 Leaf17 向整网通告时，首先 Leaf17 会将自身通往 Server17-GPU1 的路径质量附带在路由通告中发给所有 Spine，然后每个 Spine 将自身通往 Leaf17 的路径质量累积在路由通告中发给 Leaf1，Leaf1 将自身通往 Leaf17 的路径质量继续累积在路由信息中，此时 Leaf1 上有到达 Server17-GPU1 的全路径以及每条路径对应的路径质量，Leaf1 先去掉路径质量异常的路径（如质量较低路径认为不适合进行流量转发），再根据综合路径质量计算剩余路径的权重，形成 WCMP，指导流量转发。

3.2 Flowlet级负载均衡

以上述 256 个 400G 的 GPU 组网为例，如果使用了动态智能选路技术，但是不是每台设备都适合使用动态 WCMP，则交换机会动态选择基于 flowlet 的 ALB 进行流量的负载均衡。整网形成 ECMP 之后，ASIC的 ALB 功能会实时测量 ECMP 组中不同链路上负载和时延，将 flowlet 路由到负载更⼩或时延更低的链路上。

Flowlet 负载均衡

如图所示，Leaf1 上的多个指向Spine的链路同时负载流量，当红色接口负载流量较高，转发时延过长，此时 ASIC 基于 flowlet 做 ECMP 时，会自动跳过红色路径对应的出口，直到该出口负载和转发时延恢复正常值之后，ECMP 才会再选中该端口进行流量转发。

更多AI智算网络技术分享，请持续关注星融元
产品与方案咨询：400-098-9811

高效转发+智能管理：MPLS技术如何应对多业务挑战？

近期文章

随着现代企业园区网络和运营商级基础设施的不断发展，多协议标签交换 （MPLS） 已成为一项基础技术，这要归功于其高效的数据包转发、高级流量工程功能以及对多租户环境的强大支持。

什么是MPLS？

MPLS（多协议标签交换，Multiprotocol Label Switching）是一种基于标签的转发技术，结合了二层交换的简捷性与三层路由的灵活性。通过预分配的标签（Label）替代传统IP路由的逐跳查表，提升转发效率。

MPLS起源于IPv4（Internet Protocol version 4），其核心技术可扩展到多种网络协议，包括IPv6（Internet Protocol version 6）、IPX（Internet Packet Exchange）和CLNP（Connectionless Network Protocol）等。MPLS中的“Multiprotocol”指的就是支持多种网络协议。

由此可见，MPLS并不是一种业务或者应用，它实际上是一种隧道技术。这种技术不仅支持多种高层协议与业务，而且在一定程度上可以保证信息传输的安全性。

核心组件：LER（标签边缘路由器）、LSR（标签交换路由器）、FEC（转发等价类）。

工作原理

  1. 标签分配：入口路由器（LER）为数据包分配标签，标签对应转发路径（LSP）。
  2. 标签交换：中间路由器（LSR）根据标签转发表（LFIB）快速转发，无需解析IP头部。
  3. 标签移除：出口路由器（LER）剥离标签，恢复原始IP数据包。

MPLS工作原理

标签结构

MPLS 标签是一个紧凑的 32 位报头，包含四个关键字段：

MPLS标签结构

  • 标签 （20 位） — 标识通过 MPLS 网络的路径 （LSP）
  • EXP（3 位）— 用于 QoS（服务质量）标记或流量优先级
  • S （1 bit） – 堆栈标志的底部;指示这是否是堆栈中的最后一个标签
  • TTL（8 位）– 生存时间;通过限制数据包的生命周期来防止路由循环

为什么需要MPLS？

在传统IP网络架构中，基于三层路由的转发机制逐渐暴露很多问题。

首先，转发效率低下的问题尤为突出，由于每台路由器都需要逐跳解析IP报文头部并查询路由表，这种反复查表的机制在大流量场景下会产生显著延迟，难以满足数据中心或运营商核心网的高吞吐需求。

其次，传统路由技术对路径控制能力薄弱，完全依赖OSPF、BGP等动态路由协议自动选路，既无法主动规避拥塞链路，也无法为特定业务指定优化路径，导致网络资源利用率低下。

更棘手的是多业务隔离难题，VLAN受限于4096个ID的规模上限，ACL策略管理复杂度随业务增长呈指数级上升，这种基于二层的隔离方案难以支撑跨地域、多租户的现代组网需求。

MPLS技术的核心功能

服务质量（QoS）

MPLS在QoS中的应用主要体现在其对网络流量优先级管理的精细化能力上，而EXP字段（Experimental Bits，后更名为Traffic Class字段）是两者结合的核心纽带。MPLS如何实现QoS保障？在MPLS网络入口（LER），根据业务类型（如语音、视频、普通数据）为流量分配EXP值，可通过手动配置或自动映射（如将IP层的DSCP值转换为EXP值）。LSR根据EXP值分为不同优先级队列，优先转发低延迟流量（SP）和按比例分配剩余带宽（WFQ）。当链路拥塞时，低EXP值的流量可能被丢弃（如TCP流量），而高EXP值的流量（如VoIP）始终保障带宽，此外，再结合RSVP-TE等协议实现关键业务（如语音、实时视频）的带宽保障和低抖动传输，构建起从转发效率到业务体验的全方位优化体系。

流量工程（TE）

TE通过MPLS技术解决了传统IP网络无法实现的精细化流量控制需求，通过显式路径（Explicit Path）手动或策略驱动流量走向，均衡负载或避开瓶颈链路，从而优化网络性能。

业务隔离与VPN

传统VPN一般是通过GRE（Generic Routing Encapsulation）、L2TP（Layer 2 Tunneling Protocol）、PPTP（Point to Point Tunneling Protocol）等隧道协议来实现私有网络间数据在公网上的传送，而MPLS LSP是通过标签交换形成的隧道，数据报文不再经过封装或者加密，因此，用MPLS实现VPN具有天然的优势。

基于MPLS的VPN通过LSP将私有网络的不同分支联结起来，形成一个统一的网络，如图所示。基于MPLS的VPN还支持对不同VPN间的互通控制。这对于企业和运营商网络至关重要。

  • CE（Customer Edge）是用户边缘设备，可以是路由器，也可以是交换机或主机。
  • PE（Provider Edge）是IP/MPLS骨干网的边缘设备。
  • P（Provider）是IP/MPLS骨干网的骨干设备，不与CE直接相连。P设备只需要具备基本MPLS转发能力，不维护VPN信息。

业务隔离与VPN

如何基于业务场景与技术特性选择最优网络方案？
对比维度MPLS传统IP路由SD-WANSegment Routing
转发效率高（标签快速交换）低（逐跳查表）中（依赖隧道封装）高（类似MPLS）
路径控制支持显式路径和流量工程依赖动态路由协议动态智能选路灵活源路由
多业务隔离通过VPN实现逻辑隔离VLAN/ACL，扩展性差有限（依赖Overlay）需结合其他技术（如VXLAN）
部署成本高（依赖专用设备和运营商专线）低低（利用互联网链路）中（需升级硬件支持）
适用场景企业专网、运营商核心网中小型园区网络跨地域互联、云访问优化数据中心、大规模骨干网
服务质量（QoS）强（基于EXP/DSCP优先级标记）弱中（依赖链路质量监测）中（需策略配合）

AsterNOS：软件定义架构下的MPLS转发技术革新

SONiC（Software for Open Networking in the Cloud） 是开源社区的网络操作系统，其核心目标是构建开放、解耦的云数据中心网络架构。作为全球首个完全开源的网络操作系统，SONiC基于Linux内核设计，支持标准化硬件（如白盒交换机）与容器化微服务架构，通过模块化组件（如SAI——交换机抽象接口）实现灵活的功能扩展。其开源特性吸引了全球云服务商、运营商及企业的广泛参与，逐步成为云原生网络的事实标准。

尽管社区版 SONiC 通过模块化设计为云数据中心提供了开放灵活的基础架构，但其在复杂协议支持上的短板始终制约着企业级场景的深度应用。以MPLS为例，社区版本需依赖第三方扩展或定制化开发，导致功能碎片化、性能不稳定，难以满足金融专网、跨云互联等高可靠性需求。

AsterNOS基于 SONiC 的开放式园区交换机的完整产品组合现在完全支持 MPLS，它提高了数据包转发速度，支持精细的流量控制，并支持多协议环境，使其成为电信、企业 WAN 和云数据中心中的大规模网络不可或缺的工具。

这种“开源基因+商业级能力”的融合，使得AsterNOS既能继承开源生态的灵活性，又能以超前技术布局填补开源生态与商业需求间的鸿沟。

返回资源中心

最新动态

实时解析和可视化呈现 GPU 集合通信路径

关注星融元

“黑盒”状态的集合通信

智算集群通常都是以GPU服务器为最小单位构建的，服务器内部安装了若干块GPU计算单元，在此之上会有CUDA、NCCL、PyTorch等软件系统协同构建AI大模型的训练/推理任务的基础环境。NCCL

目前最广泛应用的是英伟达的开源集合通信库 NCCL（NVIDIA Collective Communication Library），可以在英伟达的 GPU 芯片之间进行高效的数据交换和协同工作。其他云和 GPU 厂商也推出了一批 xCCLs，例如 HCCL、ACCL、TCCL 和 oneCCL 等

大模型的训练调优过程中，我们经常会遇到例如集群性能表现不如预期、训练任务中断现象，其原因除了来自模型自身或 GPU 服务器内部配置问题等等，还有可能是网络层面的数据传输。

然而，集合通信库位于开发框架之下，对于 GPU 集群的使用者来说，集合通信路径是透明无感知的黑盒状态。

EPS 是什么？

EasyRoCE – EPS （E2E Path Scheduler，端到端路径规划）的主要功能是把集合通信库运行时不对外展示的各项关键信息，例如数据通信路径、任务中选用的 GPU、网卡状态等呈现给用户，帮助 GPU 集群的使用者快速定位问题，更好地利用集群的硬件资源，并基于此进行最佳路由规划。

对于 EPS 给出的推荐路由配置，用户可以自行决定是否下发。若确认选用推荐路由，EPS 可以调用 星融元 RoCE 交换机 提供的 REST API 完成配置自动下发。

  • 通信环可视化：自动解析通信链路信息，透传底层状态
  • 路由自动生成：算法和路径相关的路由推荐机制，配置自动下发
  • 辅助决策：底层通信信息集中到统一面板展示

EPS-EasyRoCE

如何使用 EPS？

本文提供的演示环境下，EPS 工具将会被部署在集群的 Master 节点（即产生 NCCL 日志文件的位置），并以 systemd 守护进程的方式在后台实时监控日志文件——每当日志更新，EPS 自动会解析最新的信息，转换为便于阅读和理解的形式推送到统一监控面板（如 EasyRoCE-UG ）中集中呈现。

EPS 是星融元 EasyRoCE Toolkit 之一，以下仅展示基础功能，完整功能和最新版本请联系项目销售/售前人员。

1. 安装配置EPS

演示环境中的 Master 节点为一台独立的 CentOS 服务器，项目指定的工作目录为 /home/admin/EPS

安装配置EPS

2. 配置监控面板

演示使用 EasyRoCE Toolkit 内的统一监控面板（UG，Unified Glancer），在此之前需要提前完成该平台的部署，请参阅：一文解读开源开放生态下的RDMA网络监控实践 中的“监控平台配置”部分。

我们只需要为 UG 再添加一个呈现 HTML 的 Pannel，并完成 HTML 源的配置（如下图所示），EPS 解析出来的集合通信环信息就将作为各类 RDMA 网络相关监控指标信息的补充，辅助集群设施调优决策。

配置

完成以上所有步骤，我们就可以在 UG 看到实时更新的集合通信库运行信息，手动更新NCCL 日志文件，可以看到 UG 中呈现的解析信息也同步刷新。

配置

INT-based Routing：AI时代的智能路由

关注星融元

AI时代，传统路由不堪重任

在AI技术蓬勃发展的今天，互联网发生天翻地覆的变革。作为整个互联网演进的重要缩影，路由技术不可避免的卷入这一变革的洪流之中。

底层原因是，AI引发了网络流量的阶跃式变革：

  • 网络流量形态千变万化。在AI数据中心中，从对延迟极端敏感的老鼠流到对带宽要求极高的大象流，前所未有的混杂在同一个网络之中。
  • 网络流量剧烈震荡。由AI并行计算驱动，网络流量发生周期性剧烈震荡，其流量、振幅和频率都是前所未见。一个训练epoch就能产生相当于整个互联网2-3天的流量，一次典型的AI推理需要每秒2万次以上的通信。
  • 网路拥塞空前严重。伴随剧烈震荡的网络流量，网络拥塞，尤其是In-cast拥塞达到了目前技术难以克服的程度，成为制约AI发展的瓶颈。
  • 网络应用日新月异。AI模型一日千里，AI Agent遍地开花，新的模型、新的应用不断对网络带来新的冲击。
  • 流量转发技术更新换代。为了适应AI带来的新流量，一些新的流量转发技术已经被逐步部署，如flowlet, packet spray等，以替代过时的基于流的ECMP和拥塞控制等。

为了应对这些空前的变化，作为网络控制平面核心的路由技术，将不得不迎接新的挑战。从最早的静态配置，到今天高度智能化、自适应、实时响应，我们可以大致把路由协议的发展分为以下几个阶段：

一、静态路由阶段（Static Routing）

1960s–1970s。手动配置每条路由，适用于小规模网络（如ARPANET）。不具备动态拓扑变化的应对能力。

二、动态路由阶段（Dynamic Routing）

1989年，OSPF和BGPv1分别发布。它们能够动态感知网络拓扑的变化，并基于拓扑信息（如OSPF的链路带宽，BGP的AS PATH）计算最佳路径。为了适应更复杂的需求，它们也逐步添加了各种路由策略和负载分担技术。

三、SDN路由探索阶段

2008年后，由于网络设备的内嵌CPU处理能力有限，老的路由协议难以应对网络业务的动态变化，SDN路由兴起。它部署在集中式的通用服务器上，用全局视角来观察网络拓扑，并根据业务需求灵活调度流量。然而由于它与网络设备分离，很难及时跟踪网络拓扑和流量的变化，调度策略赶不上流量的变化，并没有达到取代动态路由协议的目标。

四、动态路由与控制器协同阶段

2012年后，为了解决数据中心内多租户的主机间路由问题，提出了BGP EVPN overlay路由技术；2013年后，为了解决传统路由难以灵活调度流量的难题，提出了SR(Segment Routing)等技术，叠加TI-LFA(Topology-Independent Loop-Free Alternate)技术还可以提供备份路由。这些技术的共同特点是与控制器能良好协同，实现流量的更精细化的调度。如BGP EVPN与云管理器协同，自动化部署虚拟网络，实现虚机间的流量转发；SR与网路管理器协同，实现流量工程等。

从上面的发展历程，我们可以看出，路由技术的发展是流量驱动的，但受到对网络的感知和计算能力的制约，从静态、到感知拓扑，再到感知流量，逐步向更智能和更自动化的方向发展。

INT-based Routing—新一代智能路由技术

那么，如果网络具备了更高级的感知能力和计算能力，是否能解决AI时代的流量调度难题呢？

答案是肯定的，这就是星融元研发的INT-based Routing（In-band Network Telemetry based Routing，基于在网遥测的路由），作为全新一代的动态路由技术，它不仅感知网络拓扑的变化，还能动态感知网络流量和设备负载的变化，是真正全动态的智能路由技术。

01、INT——动态感知网络流量

INT（In-band Network Telemetry）是现代网络自感知、自优化演进中一个关键的里程碑。它是“P4可编程数据面 + 遥测驱动网络”兴起的自然产物，2014年由Barefoot Networks提出，随着P4生态的发展和主流交换ASIC芯片的支持，它逐步在大型数据中心得到广泛应用。

相比传统的网络测量技术，INT技术的特点有：

  • 自记录。INT的基本思想是，在真实业务包中“嵌入”一段 metadata，沿路记录下关键节点的状态。从而减小测量误差。
  • 实时。INT可以实现逐包级别的遥测，从而达到μs级的测量间隔，配合PTP(Precision Time Protocol)，测量精度更是能达到10ns级。
  • 丰富的元信息。INT metadata记录了丰富的可选信息，如Node ID, Interface ID, Timestamp, Hop Latency, Queue Depth, Buffer Occupancy, Egress interface Tx utilization等。

为支持以上能力，INT需要通过ASIC、DPU或服务器级别的CPU实现。在主流的交换ASIC芯片中，Marvell的Teralynx在INT支持方面表现突出，提供了全面的P4 -INT支持和高级遥测功能。Broadcom 的 Trident 系列通过 IFA 2.0 等技术也提供了强大的遥测能力。NVIDIA 的 Spectrum 系列则实现了类似INT 的 WJH (What Just Happened)技术，增强了网络事件的可视性和诊断能力。

总之，INT用“包内自记录”的方式彻底改变了网络感知能力，是从“监控网络”到“网络自我感知”的技术飞跃。

02、精细的流量调度粒度

传统网络中，流量调度的单位是“路由”，也就是一个网络地址段，去往这个目的网络地址段的流量都遵循同样的转发路径。随后出现了基于“流”的调度技术，如策略路由、ECMP等。一个“流”对应了传输层的一个会话，如IP五元组（源地址、目的地址、源端口、目的端口、协议号）。在此基础上，上层应用可以假设去往同一流的所有包沿着同样的路径，遵循严格的顺序，相应的流控技术（如TCP流控）也在据此构建。

（以太网流控机制看这一篇：解锁AI数据中心潜力：网络利用率如何突破90%？）

“流”这个调度粒度仍嫌不足，因为网络中出现了大量“长连接”的流，如视音频、分布式存储、AI训练等。因此近年出现了两个分支技术，包喷洒和flowlet。

包喷洒技术允许将同一个流的不同包转发到不同路径上。由于这种方式会导致目的地接收到的报文乱序，因此需要修改传输协议，在目的地重新组装为完整的消息，带来了额外开销。

Flowlet技术是根据流中的“空闲”时间间隔将一个流划分为若干片段。不同的flowlet转发到不同路径上，但又保证了报文不会乱序到达，传输层无需修改。

可以看到，随着网络设备（包括交换机和网卡）计算能力的逐步增强，更精细粒度的流量调度成为可能。但由谁来决定如何将这些单位流量调度到不同的路径上呢？

03、基于遥测的智能路由

考虑到 flowlet 或数据包的数量和频率，实现手动的策略显然不可行。

有些人又回到了SDN的思路，让一个“上帝”来指导每个 flowlet 或者数据包的调度，但考虑到网络流量变化如此迅速，高高在上的SDN控制器根本来不及感知网络流量和设备负载的实时变化，无法承担这一重任。

又有些人尝试在主机侧的SmartNIC上实现流量调度，虽然它们可以通过遥测技术获得网络转发路径的一些信息，但由于它们不感知网络拓扑，也不能与网络设备协作，仅能够在网卡有限的几个端口上实现流量调度或控制，无法充分利用网络内部的链路和带宽。

反观网络交换机，随着INT技术的普及，具备了感知网络拓扑、网络流量和设备负载的全面能力，将这些信息汇总到交换机的大脑——NOS（Network Operation System）中，在日益强大的控制CPU/DPU的加持下，足以实时处理大量的INT信息，从而计算出最佳的流量调度方案。这种计算虽然是分布式的，但由于交换机之间通过动态路由协议和INT相互交换了信息，每个交换机都具备全网感知能力，这样它们计算的结果不仅仅是局部最优的，同时也是全局最优的。

AsterNOS正是这样做的。

它结合OSPF、BGP和在网遥测（INT）技术，为网络中任意一对节点之间计算多条路径，每个路径的开销是通过INT测量的路径延迟等网络负载信息。OSPF擅长在链路级别感知网络拓扑，BGP则擅长在AS级别感知网络拓扑，它们的结合让交换机具备宏观视野，又不失微观洞察。但仅仅基于相对静态的网络拓扑来实现动态流量的调度是不够的。INT通过逐跳嵌入元数据，彻底解决了原来单个交换机无法动态感知整个路径上流量和负载的问题。它们的结合释放出强大的流量调度能力。

以一个典型的Spine-Leaf拓扑的数据中心网络为例。

INT Routing

如上图所示，Server0和Server1分别连接到两个Leaf交换机，这一对Leaf交换机间存在4个路径。

在Server侧看不到这4个路径，因此智能网卡无法实现流量调度。

在Leaf交换机上，如果仅依赖OSPF，能看到4条静态的等价路径，但它们的负载实际上是不同的。

如果借助INT的感知能力，Leaf1交换机上现在就能够知道去往Server0有4条时延不相等的路径。这样Leaf1交换将能够选择更优的策略将流量分配到这4条路径上，如最小时延路径或者WCMP(Weighted Cost Multiple Path)，从而实现完全自适应的路由，让网络流量和网络负载完全匹配，最大化网络的吞吐量、最小化尾部延迟，最大化网络利用率。

INT-Based Routing可以与Packet Spray和flowlet结合，实现逐包级别或逐flowlet级别的流量调度。借助OSPF和BGP的拓扑发现能力，它能够在任意拓扑的网络上应用。

相比传统的ECMP技术，INT-Based Routing可将网络利用率提升到90%以上，网络吞吐量提升20~45%， P99 tail latency 降低50%以上，从而显著提高AI训练的作业完成时间（JCT）。

新路由范式将带来新一轮网络设备升级

AI的发展告诉我们，当我们做更多更有效率的分布式计算，就可以改变世界。网络本身又何尝不是如此。当我们在交换机中对网络拓扑、网络流量和设备负载进行实时分布式计算后，我们就能大幅改善网络的性能。

然而，要实现这一点，我们需要对网络设备进行新一轮升级，让它不仅仅具备强大的转发能力，也要具备强大的计算能力，并有机的将这两个能力结合 在一起。这就是星融元近期推出一系列Smart Switch（智能交换机）背后的逻辑。

Smart Switch的基本构成是“可编程的ASIC数据平面 + DPU化的控制平面 + 控制平面到控制平面的高速数据通道”。

INT-Routing

例如，星融元CX864E-N采用了Marvell Teralynx 10可编程ASIC，支持Flowlet，P4-INT，WCMP，PTP，Multicast Replication等高级特性。控制平面则采用了服务器级别的Intel XEON处理器，在AsterNOS中支持ePBF/DPDK/VPP等DPU技术，让它能够以毫秒级别感知网络并计算最新的流量调度方案；更可以通过M.2接口扩展支持AI加速模块，对网络流量进行AI分析和预测，让调度更加精准。在控制平面和数据平面间，采用DMA和高速以太网通道来传递数据，使得它们紧密联系成为一个整体。

关于星融元 CX864E-N：51.2T 800G AI智算交换机软硬件系统设计全揭秘

即将推出的 CX306P-N 数据中心Leaf交换机则采用了Marvell Falcon可编程ASIC和Marvell OCTEON 10 DPU，并通过2 x 100G以太网将两者互联，在AsterNOS + VPP的调度下，实现INT-based Routing和集中式vRouter，vFirewall等新一代AIDC特性。

总之，Smart Switch 是“网络智能化”的结构性演进。它不再依赖主机上的智能网卡、也不依赖集中控制器，而是将 “实时感知 + 智能调度” 嵌入网络最核心的物理单元Switch中，使网络成为分布式计算平台，具备自感知、自调度能力，从而自适应处理毫秒级的流量变化，是网络应对AI时代的关键变革。

在此基础上，INT-Based Routing应运而生，推动网络控制面进一步走向智能化，是路由技术的最新范式。它把AIDC的网络利用率提升到90%以上，进一步释放AI集群的计算潜力。可以说，INT-Based Routing 是为AI而生的智能路由！

对星融元产品感兴趣？

立即联系！

电话咨询
联系表单
返回顶部

如何联系我们？

产品中心

快速导航

订阅我们获取最新资讯。

订阅邮件

关注星融元

企业二维码

© 星融元数据技术（苏州）有限公司 苏ICP备17070048号-2