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

标签： 技术分享

一文通览！从分布式存储的网络设计选型到性能测试

关注星融元

本文将从以下几个维度梳理相关知识信息，篇幅较长，建议先转发收藏。

  • 存储架构沿革
  • 分布式存储网络协议选择
  • 交换机硬件设备选型
  • RoCE无损网络配置和管理（手动配置和自动化配置）
  • 性能测试方案（关键指标、测试工具和参数解读）
  • 最佳实践

传统集中式存储和分布式存储的对比

传统集中式 SAN/NAS 存储起步早、技术成熟，具备高IOPS、低时延、数据强一致性等优势，适合金融、医疗等行业的核心业务系统的数据库存储场景，但集中式的架构同时决定了它的扩展能力受限于存储机头，无法很好地支撑大规模数据存储和高并发访问场景。

随着云计算技术快速迭代，AI智算的逐步落地应用推广，计算能力与上层业务规模的急速扩展推动着存储基础设施转变为分布式存储架构。

分布式存储作为新一代的存储技术，使用分布式存储软件将算力服务器本地的硬盘组成统一的存储资源池，从架构层面解决了传统集中式存储的扩展性问题，规模可扩展至上千个节点，容量可扩展到PB甚至EB级，并且性能可随容量线性提升。

在分布式存储中，网络通信方面若采用传统的TCP/IP以太网会占用大量的CPU资源，并且需要额外的数据处理。进入全闪存储时代，传统的以太网通信协议栈已无法再满足存储网络需求。

集中式架构

分布式硬件架构

对比表格

分布式存储网络的搭建

网络协议的选择

为了解决分布式存储I/O路径长和传统TCP协议带来的性能瓶颈，业界已经广泛采用高带宽低时延的RDMA网络与集群内外部的互联。

RDMA可以简单理解为利用相关的硬件和网络技术，服务器A的网卡可以直接读写服务器B的内存，应用程序不需要参与数据传输过程，只需要指定内存读写地址，开启传输并等待传输完成即可。

网络协议

当前主流的RDMA网络分为了InfiniBand和RoCEv2两大阵营。

IB网络因其性能优异早已广泛应用到 HPC 场景，但需要专用的网卡、交换机配套线缆和管理平台。

RoCEv2使用开放和标准化协议在以太网上传输IB流量，整体部署成本优势明显，采用厂商优化的RoCE网络设备，端到端性能足够稳定替代IB。以下是星融元CX-N系列RoCE交换机与同规格IB交换机的存储集群组网，测试结果甚至局部超越IB，后文会提供更详细的测试信息。

测试数据

组网架构

在计算和存储分离的部署场景中，我们推荐部署2张Spine-Leaf 架构的物理网，存储后端网将单独使用一张物理网，以保证分布式存储集群能够快速无阻塞地完成多副本同步、故障后数据重建等任务，而存储前端网和业务则可用一张物理网。

组网架构

另外，存储节点对网络接入侧的可靠性要求相对较高，因此存储集群中的节点，一般推荐使用双归或多归（Multi-homing）方式接入。

双归、多归接入

网络硬件选型

存储网络的硬件选型方面一般要满足如下几点：

  1. 高密度的100G/200G/400G接口，尽量减少交换机台数
  2. 支持IB/RoCE协议，500ns以内的端口转发时延，支持PFC/ECN等无损网络特性
  3. 全盒式设备形态，提供灵活、扁平的横向扩展能力（支持多达数千个存储/计算节点，并可保证同集群下的任何两台存储服务器之间的通信不超过三跳）

RoCE 无损网络的配置和管理

NVIDIA IB网络的配置和管理已经高度系统化和整体化，此处不加赘述。

与IB相比，未经优化的RoCE网络需要在交换机上手动配置调整，步骤会相对复杂；不过在部分交换机上(星融元CX-N系列)也可以借助于其开放的软件架构和API，引入自动化工具简化RoCE配置，并提供与UFM类似的网络监控和管理能力。

一般手动方式

在完成基础的连接与配置后，需要先根据业务场景对全网的流量优先级进行规划，并对所有的交换机使能PFC与PFC死锁监控功能，让不同的业务流量进入不同的队列进行转发，使基于RoCEv2的存储业务流量优先转发。

同时，使能所有交换机的ECN功能，保障存储队列的低时延和高吞吐。需要注意的是，交换机和服务器网卡上共同的参数需要保持一致，对于队列划分、缓存、PFC门限及ECN门限等配置需要结合业务情况动态调整，以达最佳性能表现。

#确保服务器网卡工作在 RoCEv2 模式下
#为业务流量配置 PCP 或 DSCP，并启用 ECN。

#设置网卡RDMA CM的工作模式
[root@server ~]# cma_roce_mode -d mlx5_0 -p 1 -m
#设置网卡的优先级类型为DSCP
[root@server ~]# mlnx_qos -i enp1s0f0 –trust=dscp
DCBX mode: OS controlled
Priority trust state: dscp
#在队列3上开启PFC
[root@server ~]# mlnx_qos -i enp1s0f0 -f 0,0,0,1,0,0,0,0
#在队列3上开启DCQCN
[root@server ~]# echo 1 > /sys/class/net/enp1s0f0/ecn/roce_np/enable/3
[root@server ~]# echo 1 > /sys/class/net/enp1s0f0/ecn/roce_rp/enable/3
#设置CNP DSCP
[root@server ~]# echo 48 >

#在交换机端口配置以启用 PFC 和 ECN 功能并指定队列
#在交换机的指定队列（与服务器上的队列匹配）上启用 PFC 和 ECN
#调整缓冲区和阈值

# 设置PFC门限值
sonic(config)# buffer-profile pg_lossless_100000_100m_profile
sonic(config-buffer-profile-pg_lossless_100000_100m_profile)# mode lossless dynamic -2 size 1518 xon 0 xoff 46496 xon-offset 13440
sonic(config-buffer-profile-pg_lossless_100000_100m_profile)# exit
# 在3、4队列开启PFC功能（AsterNOS的PFC功能默认使能3、4队列，无需配置）
sonic(config)# priority-flow-control enable 3
sonic(config)# priority-flow-control enable 4
sonic(config)# exit
# 设置ECN门限值
sonic(config)# wred roce-ecn
sonic(config-wred-roce-ecn)# mode ecn gmin 15360 gmax 750000 gprobability 10
sonic(config-wred-roce-ecn)# exit
# 配置Diffserv map
sonic(config)# diffserv-map type ip-dscp roce-dmap
sonic(config-diffservmap-roce-dmap)# ip-dscp 48 cos 6
# 配置Class map
sonic(config)# class-map roce-cmap
sonic(config-cmap-roce-cmap)# match cos 3 4
sonic(config-cmap-roce-cmap)# exit
# 配置Policy map
sonic(config)# policy-map roce-pmap
sonic(config-pmap-roce-pmap )# class roce-cmap
sonic(config-pmap-c)# wred roce-ecn
sonic(config-pmap-c)# priority-group-buffer pg_lossless_100000_100m_profile
sonic(config-pmap-c)# exit
sonic(config-pmap-roce-pmap )# set cos dscp diffserv roce-dmap
sonic(config-pmap-roce-pmap )# exit
# 进入以太网接口视图，绑定策略，将RoCE网络配置在接口上使能
sonic(config)# interface ethernet 0/0
sonic(config-if-0/120)# service-policy roce-pmap

基于网络自动化工具

以下能力均来自于星融元 EasyRoCE Toolkit 内相关组件模块，当前该工具套件对签约客户免费。详情访问：https://asterfusion.com/easyroce/

EasyRoCE

  1. 1条命令行启用和模板化配置RoCE ：针对无损网络优化的命令行视图和业务级的命令行封装，实现一条命令行启用；基于芯片规格和应用场景，预设最佳参数模版
  2. 关键RoCE指标导出和可视化呈现：在交换机内运行一个容器化的监控采集前端（RoCE Expoter），将RoCE业务相关网络指标采集给开源监控方案Prometheus，为运维团队提供一个开箱即用的RDMA网络监控方案
  3. RoCE 网络参数集中呈现：RoCE相关的配置调试信息组织起来集中展示到Prometheus面板，简化排障流程提高效率

UG

存储性能测试的关键指标和软件工具

关键测试指标

存储性能测试项整体上分为IO时延和IOPS两个纬度，每个维度中又会按照读/写、数据块的大小分别进行测试。

通常情况下随机IO的性能远低于顺序IO、写入性能远低于读取性能。

  • IO：单个读/写请求
  • IO时延：发起请求到收到存储系统的响应消息所花费的时间
  • IOPS：每秒存储系统能处理的IO请求数。
  • 顺序IO：大量的IO请求连续相邻的数据块，典型的业务有日志、数据备份恢复、流媒体等。顺序IO的性能通常就是最高性能
  • 随机IO：IO请求的是随机分布在存储介质各个区域的数据块，比如高并发读写大量小文件，就会导致IOPS和吞吐的性能下降，典型的业务有OLTP、交换分区、操作系统等。随机IO的性能通常是最低性能

此外，数据块大小对存储的性能表现直接的影响。

  • 小IO，如1K、4K、8K
  • 大IO，如32K、64K甚至更大

较大的IO会带来更高的吞吐，较小的IO会产生更高的IOPS。大多数真实的业务场景中，IO的大小是混合的。

性能测试步骤和工具

  1. 存储网络的性能测试。主要关注网络单链路的吞吐和时延，常用的工具是iperf、ib_read/write_bw、ib_read/write_lat；
  2. 会进行存储系统的基础性能测试。这里关注的是存储系统的时延和吞吐，常用的工具是fio；
  3. 业务级别的兼容性、稳定性以及性能测试。兼容性方面主要测试交换机的API是否能满足业务系统的要求，稳定性方面的测试则是网络设备级和链路级别的高可靠，性能测试则会用业务场景专用的测试工具进行压测，比如：数据库一体机常用的工具是swingbench和hammerdb，对象存储场景中常用的工具是cosbench。

测试参数说明

以下是国内某数据库厂商分别使用 Mellanox SB7700与星融元CX532P-N组网，使用测试工具fio得出的结果概要：

测试参数

测试时延时使用的是1v1的方式，测试存储系统IOPS时分别用1v1、2v1的方式进行压测。目标是测试服务器在假设的小IO业务场景中（100% 随机，70% 读，30% 写，IO size 4K）的性能表现。

[root@server ~]# fio \
-filename=/root/randrw_70read_4k.fio \
-direct=1 \
-iodepth 1 \
-thread \
-rw=randrw \
-rwmixread=70 \
-ioengine=psync \
-bs=4k \
-size=5G \
-numjobs=8 \
-runtime=300 \
-group_reporting \
-name=randrw_70read_4k_local

`-filename=/root/randrw_70read_4k.fio`
支持文件、裸盘、RBD image。该参数可以同时制定多个设备或文件，格式为：-filename=/dev/vdc:/dev/vdd（以冒号分割）。

`-direct=1`
direct即使用直接写入，绕过操作系统的page cache。

`-iodepth=1`
iodepth是设置IO队列深度，即单线程中一次给系统多少IO请求。如果使用同步方式，单线程中iodepth总是1；如果是异步方式，就可以提高iodepth，一次提交一批IO，使得底层IO调度算法可以进行合并操作，一般设置为32或64。

`-thread`
fio默认是通过fork创建多个job，即多进程方式，如果指定thread，就是用POSIX的thread方式创建多个job，即使用pthread_create()方式创建线程。

`-rw=randrw`
设置读写模式，包括：write(顺序写)、read(顺序读)、rw(顺序读写)、randwrite(随机写)、randread(随机读)、randrw(随机读写)。

`-rwmixread=70`
设置读写IO的混合比例，在这个测试中，读占总IO的70%，写IO占比30%。

`-ioengine=psync`
设置fio下发IO的方式，本次测试使用的IO引擎为psync。

`-bs=4k`
bs即block size(块大小)，是指每个IO的数据大小

`-size=5g`
测试总数据量，该参数和runtime会同时限制fio的运行，任何一个目标先达到，fio都会终止运行。在做性能测试时，尽量设置大点，比如设置2g、5g、10g或者更大，如果基于文件系统测试，则需要需要小于4g。

`-numjobs=8`
本次作业同时进行测试的线程或进程数，线程还是进程由前面提到的thread参数控制。

`-runtime=300`
测试总时长，单位是s。和size一起控制fio的运行时长，在做一般性性能测试的时候，该时间也尽量设置长点，比如5分钟、10分钟。

`-group_reporting`
多个jobs测试的时候，测试结果默认是单独分开的，加上这个参数，会将所有jobs的测试结果汇总起来。

`-name=randrw_70read_4k_local`
本次测试作业的名称。

最佳实践

星融元（Asterfusion）为中国TOP3公有云打造媲美IB的低时延网络。

需求背景

该公有云用户作为中国TOP3云计算服务市场的重要参与者之一，为政府、企业和个人用户提供安全可靠的云计算解决方案。2022年需要对存储业务区域进行扩容，进一步提升网络服务质量。

  • 设备时延要低，满足分布式存储的业务需求
  • 具有良好的供应链保障机制
  • 能够提供及时且专业的技术支持

方案介绍

通过星融元CX664D-N（64x200GE）大容量低时延以太网交换机提高应用响应速度，同时为业务提供无损传输保障，满足高可靠、低时延的需求。

  • 整网采用RoCEv2，通过PFC、ECN、DCBX保障业务无损，提供与IB媲美的性能和无损网络
  • 超低时延提高业务并发量，加快数据传输速度，提升业务响应效率，抢占市场先机
  • 更低的技术门槛和运维成本，可以在传统以太网上实现超低时延、零丢包、高性能的网络传输

智能路径调度：AI驱动负载均衡的异常路径治理实践

近期文章

AI流量往往具有突发性、大象流（大规模数据流）占比高的特点，极易造成网络拥塞热点。一条质量不佳（如高延迟、高丢包、带宽受限）的路径，不仅自身无法有效传输数据，如果ECMP继续向其分发流量，还可能导致该路径上的拥塞加剧，形成恶性循环，进而“污染”整条路径上的流量，波及更多正常应用。因此，构建一个能够实时感知路径质量、动态规避异常路径的智能负载均衡机制，成为支撑高性能AI计算的关键基础设施之一。

为了解决上述挑战，我们引入了基于路径综合质量的动态权重成本多路径（Weighted Cost Multipath, WCMP）机制。该机制的核心在于持续评估并利用路径的综合质量作为流量调度的核心依据。

路径综合质量评估

系统持续监控每条可用路径的关键性能指标，这些指标通常包括但不限于：

  • 延迟 (Latency): 数据包端到端传输耗时。
  • 丢包率 (Packet Loss Rate): 传输过程中丢失的数据包比例。
  • 带宽利用率 (Bandwidth Utilization): 路径当前占用带宽与其理论容量的比值。
  • 错误率 (Error Rate): 如链路层错误等。
  • 通过预设的算法（如加权计算、机器学习模型评分等），将这些原始指标融合计算为一个综合质量得分（通常是一个数值）。这个得分量化地反映了该路径在当前时刻传输流量的“健康度”或“优良程度”。得分越高，代表路径质量越好；得分越低，代表路径质量越差，越接近异常状态。

异常路径判定与剔除

系统设定一个约定的质量阈值系数。该阈值代表了我们认为一条路径可以承载正常AI流量的最低可接受质量水平。

  • 判定逻辑： 当系统计算出的某条路径的综合质量得分低于此约定阈值时，即认为该条路径在当前AI场景下不再可用，判定为异常路径。
  • 处理动作： 立即将这条异常路径从当前有效的负载均衡路径池中剔除（Prune）。这意味着后续的流量调度将暂时不再考虑此路径。

异常路径剔除

如图所示，当Leaf1与Leaf2通信存在四条路径时，假设根据（智算网络路径质量三要素：带宽/队列/时延在智能选路中的协同优化）中的算法逻辑在Leaf1中计算出四条路径综合质量分别为4.5、55、65和75，此时红色路径会被剔除，剩下的三条路径根据各自路径质量形成WCMP。待红色路径质量恢复达标后，它将重新加入路径池并参与负载均衡。

路径的动态WCMP调度

剔除异常路径后，系统使用剩余的健康路径来承载流量。根据剩余每条健康路径的综合质量得分，动态计算并分配其流量转发权重。质量越高的路径，获得越高的权重，意味着它能承载更大比例的流量；质量相对较低（但仍高于阈值）的路径，则获得较低权重。这种基于实时质量动态调整权重的WCMP策略，确保了流量能够最大程度地流向当前最优的路径，优化整体传输效率和性能。

路径恢复与重新引入

被剔除的路径并非永久废弃。系统会持续监控其综合质量。一旦该路径的质量得分恢复到约定阈值之上并保持稳定一段时间（避免抖动），系统会将其重新引入有效路径池。重新引入后，该路径将根据其最新的综合质量得分，参与后续的动态WCMP权重计算，重新分担流量。

在AI驱动的数据中心网络环境中，传统的“尽力而为”和“无差别均分”负载均衡策略已力不从心。基于路径综合质量的动态WCMP机制，通过实时感知路径状态、果断剔除异常、智能调度“健康”资源，有效解决了AI流量对网络高可靠、高性能的核心诉求。虽然存在少量的短期资源闲置作为代价，但相较于避免路径拥塞乃至业务中断所带来的巨大损失，这一机制是支撑AI计算基础设施稳定高效运行的关键优化手段。

返回资源中心

最新动态

A-Lab | 主动规划+自动化配置工具，简单应对AI智算网络 ECMP 负载不均

关注星融元

智算环境组网采用的 Clos 架构下，各交换节点基于常规的 ECMP 路由（分布式运行和自我决策转发）往往无法完全感知全局信息，容易导致多层组网下的流量发生 哈希（HASH）极化 现象，导致某些路径负载过重（拥塞），而其他路径负载很轻（闲置），严重拖慢智算集群整体性能。

什么是哈希极化？

哈希极化，又称哈希不均，其根本原因在于哈希算法的一致性与网络拓扑结构和流量模式特性之间的相互作用。

一般情况下，网络设备通常使用相同或非常相似的哈希算法和相同的输入参数（如标准的五元组）。

当网络中存在大量具有相似特征的流（例如，大量流共享相同的源IP或目的IP），而这些特征恰好是哈希算法的主要输入，那么这些相似的流非常有可能不像预期那样被分布到所有可用的等价路径上，而是呈现出明显的偏向性。

此外，当流量经过多个使用 ECMP 的网络设备（原本在leaf层被“打散”的流量，经过Spine 层转发又被集中到少量链路上），以及流量模式本身的特征（由少数大流主导），都会加剧哈希极化现象。

主动路径规划配置逻辑

在不引入动态负载均衡技术的情况下，我们可以通过增加参与哈希计算的因子，以及主动规范流量路径的方式来应对 AI 算力集群规模化部署的痛点（例如负载均衡和租户隔离等），主动路径规划需要网络工程师按照如下转发逻辑去配置 RoCE 交换机：

1. 智算服务器上每张网卡都对应一个接口，服务器产生跨 Spine 的上行流量会在Leaf交换机判定并执行策略路由转发给对应 Spine

  • 在1:1无收敛的情况下，Leaf 交换机的每个下行端口绑定一个上行端口
  • 在 n:1 的情况下，上下行端口以倍数关系（向上取整） 形成 n:1 的映射

ppd

2. 跨 Spine 上行流量在 Spine 上按照标准 L3 逻辑转发在智算环境下的轨道组网中，多数流量仅在轨道内传输，跨轨传输流量较小，网络方案可以暂不考虑在 Spine 上拥塞的情况；

3. 跨 Spine 下行流量进入 Leaf 后根据 default 路由表指导转发。

可以看到，以上配置逻辑若完全以手动输入命令行的方式下发到所有交换机，会是一件相当繁琐且耗时的事情，也容易引入配置失误。

借助 EasyRoCE 工具配置

为加速智算场景下的路由优化配置，此前我们有介绍过 PPD 工具（主动路径规划，Proactive Path Definer）的1.0 版本。如今经过一段时间的实践打磨，PPD 工具迎来了一轮迭代，升级到2.0版本，其主要运行步骤如下：

  1. 从 AID 工具（AI基础设施蓝图规划，AI Infrastructure Descriptor）读取网络基础配置信息。
  2. 运行 PPD 工具，生成路由配置文件。
  3. 在 UG 工具 （统一监控面板，Unified Glancer）中展示配置文件，用户核对并确认配置下发。

作为 EasyRoCE 工具套件的构成部分，PPD 可以独立运行在服务器上，也可以代码形式被集成到第三方管理软件中。

EasyRoCE Toolkit 是星融元依托开源、开放的网络架构与技术，为AI 智算、超算等场景的RoCE网络提供的一系列实用特性和小工具，如一键配置RoCE，高精度流量监控等…所有功能对签约客户免费开放。
详情访问：https://asterfusion.com/easyroce/

PPD 2.0 升级了什么？

PDD 2.0 版本主要带来了以下几点的显著提升：

  • 改善 AID 与 PPD 工具的对接流程，完全实现网络基础信息的自动化填充
  • 优化 PPD 工具的图形界面操作体验，配置下发进度和结果可即时呈现，便于管理员快速排查异常原因
  • 自动集成到统一监控面板（UG），与其他 RDMA 网络配置信息在一处集中查看和管理

使用演示

第一步：导入基础网络信息

AID 工具是 PPD 的“数据源”，其中有一个专门的工作表存储了 PPD 工具所依赖的所有基础网络信息，主要是 GPU server 各网卡的 IP 地址、交换机接口互联关系和其对应的 IP 地址等，以上都支持一键自动填充；此外，该工作表内还预留有与多租户网络配置相关的标识信息（InstanceID和 Description），管理员可按需手动填写以便于后续管理、使用。

第二步：运行PPD工具生成路由配置

上传PPD相关工具到管理服务器，解压后程序结构如下：

生成路由配置

运行 start_ppd.sh 命令即可启动PPD。

第三步：选择下发配置

此时，所有与主动路由规划相关的信息已经自动集成到了统一监控面板，管理员登录UG面板可以看到 PDD 工具界面。

点击左上配置生成按钮，会出现设备可用的配置文件（XXXX.cfg）。管理员可以查看生成配置文件详情二次核对，确认勾选，再点击上方批量下发即可等待工具自动下发配置。

待配置全部下发完成，界面即时显示设备当前部署结果，失败设备提供报错信息，排障后可尝试二次下发。

动态演示

EasyRoCE-PPD 工具界面概览

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既能继承开源生态的灵活性，又能以超前技术布局填补开源生态与商业需求间的鸿沟。

返回资源中心

最新动态

对星融元产品感兴趣？

立即联系！

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

如何联系我们？

产品中心

快速导航

订阅我们获取最新资讯。

订阅邮件

关注星融元

企业二维码

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