标签：技术实现

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 的映射

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

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

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

借助 EasyRoCE 工具配置

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

从 AID 工具（AI基础设施蓝图规划，AI Infrastructure Descriptor）读取网络基础配置信息。
运行 PPD 工具，生成路由配置文件。
在 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 工具界面概览

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

关注星融元

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

关于SONiC

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

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

SONiC 系统架构由各种模块组成，这些模块通过集中式和可扩展的基础架构相互交互。其中的核心基础设施是 Redis 数据库，它提供一个独立于语言的接口，支持在所有 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-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 与SONiC社区版主要能力对比-表1

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 系列开放智能网关平台）。

AsterNOS 的交付模式

软硬一体化交付

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

软件化交付

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

虚拟化试用（vAsterNOS）

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

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

【参考文档】

优化WiFi体验！新一代园区网有自己的“流量瘦身术”

关注星融元

无线空口资源是连接物理层与网络性能的纽带，直接影响无线通信系统的容量、速率、稳定性、能效和覆盖能力。

让我们从“空口”说起

无线空中接口（Air Interface）简称“空口”，也称为无线电接口或 RF 接口，最早是来自电信领域的重要概念，指的是基站和移动设备相互通信的射频 (RF) 频谱。

我们可以类比有线网络去理解空口的概念。有线网络是通过线缆连接不同设备上的物理接口来实现信号传输，无线网络则是通过电磁波在空气中传播的，所以“空中接口”便是指的无线信号传输的接口，而在“空口”之间建立的链路就是无线链路。

无线空口技术涵盖了很多不同的技术和标准，如 LTE、Wi-Fi、蓝牙等，用以支持设备和网络基础设施之间语音、数据和视频的传输。

在常见的企业无线局域网场景下，空口可以被简单理解为 AP 和各类无线终端/STA，以及和其他AP之间的虚拟逻辑接口。IEEE 802.11 标准在空口上定义了一组无线传输规范，包括每个无线信道的使用频率，带宽，接入定时和编码方法等等。

空口资源为什么重要？

无线空口资源是连接物理层与网络性能的纽带，直接影响通信系统的容量、速率、稳定性、能效和覆盖能力。

首先，可用频谱是物理上有限的自然资源，且需通过国际协调和各国政府授权分配。高频段带宽大但覆盖差，低频段覆盖广但容量低，需平衡使用。

其次，空口资源分配策略直接影响同时服务的用户数和数据传输速率。如果空口上的多个用户同时发送数据包，产生了信号冲突会造成通信失败；此外，如果终端距离AP过远，无线信号微弱，网络吞吐量急剧下降，占用了空中接口时间，也会影响无线通信整体性能。

我们之前整理过的 Wi-Fi 6 核心技术，例如 1024-QAM 调制，改善多用户并发接入的OFDMA 和 MU-MIMO 等本质上都是在空口资源上做文章。

相关阅读：一文读懂：企业园区无线网技术及部署指南

空口利用率：无线网性能的关键指标

空口利用率是用来是指在一定时间内空口被有效数据占用的比例，也可以理解为无线信道的利用效率。一般50%左右的空口利用率是大多数常规企业局域无线网场景的一个合理阈值。

良好的空口性能需要综合采取一系列保护措施，例如避免碰撞，避退，降低冲突概率，调整 AP 无线信道，减少干扰，以及其他智能漫游和负载均衡等技术。

一般而言，采用更先进的无线标准协议，增加接入带宽和优化 AP 部署点位都能有效改善无线体验。但除此之外，无线网络场景还存在一些广播和组播报文，它们并不传输用户业务数据，却也会占用空口资源。具体有如下几类：

Probe Request 帧：由无线客户端发送，用于主动扫描周围的无线网络。也就是终端搜索信号的过程;
Probe Response 帧：由 AP 回应客户端的 Probe Request 帧，提供网络的具体信息。AP 响应中断的过程。达到负载也可能在这个环节拒绝终端的连接请求
DHCP 广播报文：设备通常通过 DHCP 协议获取 IP 地址 Discover、Offer、Request 和 ACK 报文都是广播报文，用于在无线网络中分配 IP 地址
ARP 广播报文：ARP (地址解析协议)广播报文用于将IP地址解析为 MAC 地址。在无线网络中， ARP 广播报文会占用空口资源，尤其是在设备较多的场景中
组播报文：通常用于向多个设备发送相同的数据，如视频流或音频流，组播报文在无线空口以低速发送，且没有 ACK 机制保障，因此可能会占用较多的空口资源
广播数据报文：如某些网络管理协议或服务发现协议(如 mDNS )会通过广播方式发送数据

用“减法思维”重构园区网络架构

通过引入云网中的先进理念和开放网络技术，星融元推出的云园区网络构造了一个全三层无广播的新一代云园区网络，从多维度节省了宝贵的无线空口资源，同时也降低整网的带宽波动和资源消耗、让网络更快更稳更安全。

广播丢弃：终端发出的广播报文，除了 ARP 等协议报文会上送至交换机 CPU 处理，其余广播报文均会被丢弃；此举同时也隔离了发生在终端间的二层广播攻击，让网络更安全
网关ARP代理：Leaf 层设备开启 ARP 代理(代答)功能，使用自身MAC地址快速对终端的请求完成代理，终端的访问均由网关转发，进一步抑制广播在网络中的传播（从连接终端的接口向上都是三层）。交换机不再进行大量广播泛洪动作，减低相关场景因为广播带来的资源消耗，进一步提升业务转发效率
ARP-TO-HOST：凭借 ARP-TO-HOST 能力，交换机将 ARP/NDP 表项转换为精确路由条目后进行路由转发
DHCP中继：终端的 DHCP 交互均通过交换机以单播形式代理转发，中继到 DHCP Server
严格转发：AP 上使能严格转发，无线侧接口到的除组播报文外的所有报文均转发至上行口，避免无线侧的终端在 AP 上直接互访学习到终端真实的 MAC 地址，降低被攻击的风险
广播转单播：AP 将从上行接口接收到的广播报文，查找本地的 IP 地址和 MAC 地址对应关系转换为单播报文，减少大量广播报文对空口资源的占用。如果终端不是直接连接在该 AP 下，就不再转发该报文，避免资源浪费

项目合作和产品方案咨询，欢迎拨打下方热线400-098-9811

或右下角小窗口联系我们～

开源开放技术栈下的新一代园区网可视化运维实践

关注星融元

前言：近期我们已梳理过新一代园区网的主要概念和实现原理，介绍了这套方案区别于传统数通网络的新架构和理念，以及在真实场景中的效率表现。

前篇：

新一代云化园区之旅进入这一阶段，我们已为一个中大型园区搭建好了云化后的基础网络，此后的管理维护工作将贯穿系统全生命周期。接下来我们将从可视化运维能力展开，分为以下三部分逐项介绍：

网络可视
告警管理
巡检升级

网络可视

新一代云园区方案我们可提供两种不同层级的可视化能力。

一是对网络基础设施性能和运行状态的监控，借助控制器的图形界面得以呈现；

二是更细粒度的网络流量可视化，则是基于SONiC的 NPB 2.0 方案实现，该方案包含运行在交换机上 docker 应用和可选的开放架构的后端分析系统。

网络运行状态的集中呈现

星融元云化园区网络配套的 ACC 控制器（Asteria Campus Controller）擅长提供实时、多维度的监控，管理员能够在一处平台集中查看有线+无线网络的状态和配置信息。

我们使用 |健康值| 来评估各类网络设备的状态，这个数值由ACC综合评估各项指标进行智能计算得出。评估维度主要有：资源利用率，流量负载，硬件状态和运行情况；当监控指标超过指定阈值，则会自动生成告警信息通知管理员。

登录ACC后，在任意组织/场所界面下点击 |监控| 标签即可查看其下所有在网设备的健康状态，包含有线终端和无线终端。

有线、无线终端状态集中呈现

终端生命健康状态、在线状态
终端异常检测。例如终端仿冒会导致异常漫游，终端类型发生变化后根据策略将禁止上网和发送告警）
关键操作回溯，便于定位故障，不用手动抓包

网络设备状态

接口统计信息
PoE供电状态
光模块运行状态
……

基于SONiC的网络可视化：NPB 2.0

部分园区网络还要具备对网络流量的分析能力以满足更高的监控需求，传统方式一般是引入专门的NPB网络。

网络数据包代理（NPB）安装在流量采集点（或 SPAN 端口）与后端的安全和监控工具之间，其基本功能是协调网络数据包数据，以确保后端分析工具准确获得其所需的数据。

而在新一代云园区网中，我们支持在不改变现有网络架构的情况下，直接利用云园区交换机上的 |软件强化| 去配置一套实用的网络可视化系统，而无需再采购专门的网络硬件（例如TAP/分流器）单独部署NPB能力。

显而易见，这将会为园区网络节约一大笔短期建设支出，并降低专项运维成本。

那么什么是所谓的软件强化呢？简单说来即是在交换机运行的 SONiC NOS（例如星融元 AsterNOS）上新增一个 Docker 形态部署的“NPB APP”，让园区交换机“身兼二职”——它既能是常规的交换机，完成L2/L3转发动作，同时也作为网络可视化前端设备，承担流量采集和向后端的策略分发工作。

而后端分析系统则可以采用开放硬件平台（如星融元ET系列和CX102S-DPU等）与开源 ntopng 工具协同提供服务。

ntopng是一个开源的网络流量探针软件，提供360°的网络可视性；它能够从流量镜像、Netflow导出设备、SNMP设备、防火墙日志、入侵检测系统收集流量信息。

告警管理

谈及告警管理，我们需要再次回到ACC控制器界面。

进入 ACC ｜组织/场所｜下最右侧的｜运维配置｜标签，管理员可对特定范围配置需要关注的告警信息、阈值，以及接收通知的邮箱地址，并将已有告警设置一键同步到其他指定组织/场所。

所有告警信息可以在左侧面板的告警栏目下统一查看，包括当前告警和历史告警信息。

目前最新的控制器版本已支持的告警内容包括接口状态切换，接口模块状态，带宽利用率、用户表项（ARP、主机路由、MAC）资源的利用率，RADIUS 服务器、Portal服务器状态，BGP、BFD连接状态，以及CPU风扇电源等硬件信息等。

巡检与固件管理

设备巡检功能旨在定期检查和监控网络设备，以确保其正常运行并及时发现潜在故障。其主要功能包括:

设备状态监控：检查CPU使用率、内存使用率、存储情况和端口状态
日志与告警管理：收集设备日志，分析异常事件，并触发告警机制
关键进程状态检查：监控关键进程的运行状态
自动化巡检任务：按照固定时间间隔定期执行巡检任务，生成巡检报告
所有告警信息可以在左侧面板的告警栏目下统一查看，包括当前告警和历史告警信息。

定期升级设备固件有助于维持网络系统的性能和安全，ACC具备的固件管理功能可对上传到控制器的不同版本镜像和补丁文件进行自动化的信息整理、解析验证，最后在管理员确认后完成批量下发。

工作原理

ECN需要主动队列管理AQM策略结合才能发挥作用。路由器在队列溢出前检测到拥塞，在IP报头中设置Congestion Experienced (CE) Codepoint代码点来指示正在发生拥塞。

IP层对ECN的支持

在网络层一个发送主机必须能够表明自身能支持ECN与否，路由器在转发时必须能够表明它正在经历拥塞。ECN 使用 IPv4 首部或 IPv6 首部中 ToS (Type of Service，位于首部第 9 到 16 比特位) 字段的两个最低有效位（最右侧的位编码）来表示四个状态码。

IP 报文头部中的DSCP 字段有2 Bit 用于标识ECN。这2 个Bit 分别是：ECT（ECN Capable Transport）用来标识发送端设备是否支持ECN功能和CE（Congestion Experienced）用于标识报文在传输路径上是否经历过拥塞。

图1：IP Header中的ECN Bit

当ECT为0，CE为0时，表示IP报文不支持ECN
当ECT为0，CE为1时，表示IP报文支持ECN
当ECT为1，CE为0时，表示IP报文支持ECN
当ECT为1，CE为1时，表示IP报文支持ECN，且发生了拥塞

当两端支持 ECN 时，它将数据包标为 ECT(0) 或 ECT(1)。如果分组穿过一个遇到阻塞并且相应路由器支持 ECN 的活动队列管理（AQM）队列，它可以将代码点更改为CE而非丢包。这种行为就是“标记”，其目的是通知接收端即将发生拥塞。在接收端，该拥塞指示由上层协议（传输层协议）处理，并且需要将信号回传给发送端，以通知其降低传输速率。

因为 CE 指示只能由支持它的上层协议有效处理，ECN 只能配合上层协议使用。例如 TCP 协议，它支持阻塞控制并且有方法将 CE 指示回传给发送端。

IP层ECN报文交互

ECN 是报文在网络设备出口发生拥塞时，将使能ECN（当IP 报文的ECN 字段为01 或10，表示使能ECN）的IP 报文头部的ECN 字段标记ECN=11，表示该IP 报文遇到网络拥塞，且该IP 报文不会被WRED 机制丢弃。如果接收服务器发现IP 报文的ECN 字段被标记成11，就立刻产生CNP 拥塞通知报文，并将该报文发送带源服务器，CNP 消息里包含了拥塞的数据流信息，远端服务器接收到后，通过降低相应的数据流发送速率，环节网络设备拥塞，从而避免发生丢包。

发送端发送IP 报文标记ECN(ECN=10)
交换机在队列拥塞的情况下收到该报文，将ECN 字段修改为11 并转发出去
接收服务器收到ECN 为11 的报文发送拥塞，正常处理该报文
接收端产生拥塞通告，周期发送CNP（Congestion Notification Packets）报文，ECN字段为01，要求报文不能被网路丢弃
交换机收到CNP 报文后正常转发该报文
发送服务器收到ECN 标记为01 的CNP 报文解析后对相应的数据流限速算法

CNP报文格式

CNP作为拥塞控制报文，也会存在延迟和丢包，从发送端到接收端经过的每一跳设备、每一条链路都会有一定的延迟，会最终加大发送端接收到CNP的时间，而与此同时交换机端口下的拥塞也会逐步增多，若发送端不能及时降速，仍然可能造成丢包。建议拥塞通告域的规模不要过大，从而避免因为ECN控制报文交互回路的跳数过多，而影响发送端无法及时降速，造成拥塞。

图3：CNP协议报文格式

TCP层对ECN的支持

TCP支持使用TCP头中的三个标记来支持ECN。第一个标记是随机和（Nonce Sum，简称NS），用于防止TCP发送者的数据包标记被意外或恶意改动。另两位用于回传拥塞指示和确认接收到了拥塞指示回应。这即是ECN-Echo（ECE）和Congestion Window Reduced（CWR）位，图4为TCP Header中的CWR和ECE flag。

图4：TCP Header中的CWR和ECE flag

TCP SYN握手包会包含两个额外的flag： ECN-echo(ECE)和Congestion Window Reduced (CWR) 。这样双方就可以协商在数据传输期间是否可以正确的处理设置了CE位的数据包。
发送方在所有发送的数据包中设置ECN Capable Transport (ECT) 位。
如果发送方收到一个TCP数据包，报头中设置了ECE flag，则发送方将调整其拥塞窗口，就像它从丢失的数据包中快速恢复一样。发送方下一个数据包设置CWR flag，向接收方表明它已对拥塞做出反应。发送方在每个RTT间隔最多做出一次这种反应。
当接收方接收到设置了CE 位的数据包时，接收方将在所有数据包中设置 ECE flag。这将一直持续到它收到一个设置了CWR flag的数据包，表明发送方已经对拥塞做出了反应。 ECT 标志仅在包含数据有效载荷的数据包中设置。发送不包含数据有效载荷的 TCP ACK 数据包时，应清除 ECT 位。

TCP层ECN报文交互

当在一个TCP连接上协商ECN后，发送方指示连接上的TCP段携带IP分组传输流量，将支持ECN的传输用ECT码点标记。这使支持ECN的中间路由器可以标记具有CE码点的IP分组而不是丢弃它们，以指示即将发生的阻塞。

当接收到具有遇到阻塞码点时，TCP接收者使用TCP头中的ECE标记回传这个阻塞指示。当一个端点收到TCP带有ECE位的段时，它减少其拥塞窗口来代替丢包。然后，它设置段的CWR位来确认阻塞指示。节点保持传输设置有ECE位的TCP段，直到它接收到设置有CWR的段。

图5：TCP层ECN报文交互示意图

发送端主机发送Segment 1-5到接收端，这些Segment全部都设置了ECT
Segment 2由遇到阻塞的支持ECN的路由器转发，路由器将IP头设置CE代码点，这里检测到拥塞后的策略并不是直接丢弃数据包
接收端收到Sgement 2后，它会发送带有ECE flag的ACK
交换机收到报文后正常转发该报文
发送端收到带有ECE flag的第一个ACK时，它会降低其传输速率并发送带有CWR flag的下一个Segmemt 6，就好像检测到了丢包一样。同时接收端收到Segment 6后，因为已经解除拥塞所以发送的后续ACK将清除ECE flag

两个ECT Codepoints机制

在RFC2481中，ECN字段被分为ECN-Capable Transport(ECT) bit和CE bit。ECT对应着ECT(0) codepoint。ECT(1)在RFC2481中没有定义，所以在只支持单个ECT codepoint的时候，应该使用ECT(0)。
在RFC3168中，两个ECT codepoint的主要动机是提供一位ECN nouce随机数，路由器在设置CE codepoint时必须“擦除”这个随机数(擦除 CE codepoint的路由器在重建原始随机数时将面临额外的困难，因此终端节点更有可能检测到CE codepoint的重复擦除)。ECN nouce允许为发送方提供一种机制，验证网络元素没有擦除掉CE，并且接收方正确地向发送方报告接收到了带有CE codepoint的数据包。
发送方检测有缺陷网络元素的另一种方法是不定期的发送CE codepoint数据包，以查看接收方是否报告接收到。如果这些数据包在网络中遇到拥塞，路由器可能不会更改数据包，因为 CE codepoint已经设置，所以发送方无法确定路由器是否打算在这些数据包中设置 CE codepoint。并且与ECN随机数相比，对有缺陷网络元素和接收器的检查效率较低。
TCP设置ECN的规则
如果Host收到过ECN-setup SYN packet，那么它才能发送ECN-setup SYN-ACK packet
Host不能在packet上设置ECT，除非它已发送过ECN-setup SYN或ECN-setup SYN-ACK packet，并且已收到过ECN-setup SYN或ECN-setup SYN-ACK packet，并且没有发送过non-ECN-setup SYN 或non-ECN-setup SYN-ACK packet
如果Host收到过non-ECN-setup SYN或non-ECN-setup SYN-ACK packet，则它不应在packet上设置 ECT
如果Host曾在packet上设置ECT，则它必须正确设置/清除连接中所有后续packet中的CWR TCP bit
如果Host发送过ECN-setup SYN 或 ECN-setup SYN-ACK packet，并且没有收到 non-ECN-setup SYN 或 non-ECN-setup SYN-ACK packet。那么如果Host收到ECT 和CE设置了的packet，那么它必须按照支持ECN连接指定的方式处理这些packet
Host如果不愿意在TCP连接上使用ECN，则它应该清除packet中的ECE和CWR标志
Host不能在SYN 或SYN-ACK packet上设置 ECT

Fast ECN

当交换机队列中缓存数据包超过ECN阈值时，交换机会将拥塞信息标记报文的ECN字段，并携带到发送端服务器以通知其网络拥塞。接收端服务器接收到带有ECN字段的数据包后，发送CNP通知发送端服务器调整发送速率。

图6：传统ECN处理机制

如上图所示，当数据报文进入队列排队时，传统的显式拥塞通知（ECN）判断队列使用的缓存是否超过ECN阈值。如果超过ECN阈值，交换机将数据报文IP头部中的ECN字段标记为11。发送端服务器接收带有ECN字段标记的数据报文的时间为交换机队列的数据包转发时间加上网络中标记的数据包转发时间。如果网络存在严重的网络拥塞，则ECN的反馈不及时可能会加剧队列拥塞。

图7：Fast ECN处理机制

Fast ECN通过在数据报文出队列时，标记数据报文的ECN字段，从而缩短了入队列标记ECN的数据包转发时延，接收端服务器可以在最小的时延接收到ECN标记的数据报文，从而加快发送端速率的调整。

配置实例

网络拓扑

图8：ECN物理网络拓扑

服务器端配置

Server1

[root@server1 ~]# modprobe 8021q
[root@server1 ~]# vconfig add ens1f3 100
[root@server1 ~]# ifconfig ens1f3.100 1.1.1.2/24 up
[root@server1 ~]# route add -net 1.1.0.0 netmask 255.255.0.0 gw 1.1.1.1

Server2

[root@server2 ~]# modprobe 8021q
[root@server2 ~]# vconfig add ens1f3 200
[root@server2 ~]# ifconfig ens1f3.200 1.1.2.2/24 up
[root@server2 ~]# route add -net 1.1.0.0 netmask 255.255.0.0 gw 1.1.2.1

交换机端配置

配置CISCO-LIKE命令行

在交换机配置时，需要先配置CLI模式。然后进入CISCO-LIKE视图，使用CISCO-LIKE命令行进行配置操作。

admin@sonic:~$ sudo config cli-mode cli
admin@sonic:~$ sudo sonic-cli
sonic#

交换机A

sonic# configure terminal
sonic(config)# vlan 100
sonic(config)# vlan 200
sonic(config)# interface ethernet 0/9
sonic(config-if-0/0)# switchport trunk vlan 100
sonic(config)# interface ethernet 0/10

发送流量包

sonic(config-if-0/0)# switchport trunk vlan 200
sonic(config)# interface vlan 100
sonic(config-vlanif-100)# ip address 1.1.1.1/24
sonic(config)# interface vlan 200
sonic(config-vlanif-100)# ip address 1.1.2.1/24

Server1和Server2配置了Mellanox网卡，在Server2建立服务端，Server1建立客户端发送IB流量。

Server2：
[root@server3 ~]# ib_send_bw -R -x 5 -d mlx5_0 -F –report_gbits -f 2 -D 800 -S 3
Server1：
[root@server1 ~]# ib_send_bw -R -x 5 -d mlx5_0 -F –report_gbits -f 2 -D 800 -S 3 1.1.2.2 -T 12

交机限速

对交换机A出口做端口限速处理，发包时容易产生拥塞。

sonic# configure terminal
sonic(config)# policy-map table-policy
sonic(config-pmap-table-policy)# port-shape 8000000 12800
sonic(config)# interface ethernet 0/10
sonic(config-if-0/4)# service-policy table-policy

观察拥塞情况

交换机A

观察交换机A出口的拥塞情况，可以看到在限速的情况下发IB流量包，交换机A出口没有配置ECN的情况下发生了拥塞

sonic# show counters queue 0/10

Server1

观察服务器Server1的IB发包带宽, 可以看到服务器Server1在没有配置ECN发生拥塞的情况下，发包的平均带宽为4.59Gb/s。
[root@serveer1 ~]# ib_send_bw -R -x 5 -d mlx5_0 -F –report_gbits -f 2 -D 800 -S 3 1.1.5.2

配置交换机ECN功能

交换机A

sonic# configure terminal
sonic(config)# wred ecnname
sonic(config-wred-ecnname)# mode ecn gmin 15000 gmax 150000\
gprobability 20
sonic(config)# class-map ecn1
sonic(config-cmap-ecn)# match cos 0
sonic(config)# policy-map ecn2
sonic(config-pmap-enc2)# class ecn1
sonic(config-pmap-enc2)# wred ecnname
sonic(config)# interface ethernet 0/9
sonic(config-if-0/9)# service-policy ecn2
sonic(config)# interface ethernet 0/10
sonic(config-if-0/10)# service-policy ecn2

Server1

[root@Server1 ~]# echo 1 > /proc/sys/net/ipv4/tcp_ecn
[root@Server1 ~]# cma_roce_mode -d mlx5_0 -p 1 -m 2

Server2

[root@Server2 ~]# echo 1 > /proc/sys/net/ipv4/tcp_ecn
[root@Server2 ~]# cma_roce_mode -d mlx5_1 -p 1 -m 2
[root@Server2 ~]# echo 41 > /sys/class/net/enp2s0f1/ecn/roce_np/cnp_dscp

观察ECN功能

清空流量包计数

清空交换机A的流量包计数。

sonic# clear counters queue
Clear saved counters

发送IB流量

Server1和Server2配置了Mellanox网卡，在Server2建立服务端，Server1建立客户端发送IB流量。
Server2：[root@server3 ~]# ib_send_bw -R -x 5 -d mlx5_0 -F –report_gbits -f 2 -D 800 -S 3
Server1：
[root@server1 ~]# ib_send_bw -R -x 5 -d mlx5_0 -F –report_gbits -f 2 -D 800 -S 3 1.1.2.2 -T 128

交换机A

观察交换机A入口是否收到CNP的返回流量，cnp_dscp的值设置为41，对应通道UC5。
同时观察交换机A出口的拥塞丢包情况。

sonic# show counters queue 0/10

sonic# show counters queue 0/9

Server1

同时观察到交换机A出口配置ECN的情况下拥塞几乎消失，交换机A入口的队列5收到了CNP的返回流量。Server1发包的平均带宽为5.9Gb/s。

[root@server1 ~]# ib_send_bw -R -x5 -d mlx5_1 -F –report_gbits –rate_limit=100 -f 2 -D 800 -S 3 1.1.2.2

参考资料

返回资源中心

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

关注星融元

30分钟，从无到有，为中大型园区开通有线无线两张业务网，并在一个平台集中管理？

以上绝非夸夸其谈，如果是星融元新一代云化园区网，简直易如反掌！

我们使用全盒式SONiC交换机（Asterfusion CX-M系列）构建了深度云化的园区网络：采用更精简的Spine/Leaf 架构+统一的BGP路由 作为底层网络，依靠单一的云园区控制器（Asteria Campus Controller，ACC）即可快速完成整网的有线无线业务配置——体感近似于“即插即用”。

只需三步

前篇我们已经介绍了一些概要，如果你此前对 TIP OpenWiFi 和 ACC 没有了解，建议先回顾一下：

完整揭秘：新一代园区网络运维管理全流程

配置前，园区网管理员需要将设备信息导入控制器指定组织/场所，按照拟定的网络规划给设备插线上电，后续操作都已高度自动化。

整网设备连接控制器（借助 DHCP option 自动获取控制器IP地址）
根据所选场景模板，控制器自动生成拓扑并完成基础网络配置（对用户屏蔽了技术细节，控制器自动计算BGP互联地址并完成整网路由配置）
开通有线网和无线网业务（基于控制器预置/自定义模板，图形界面一键批量下发）

第一步：设备自动连接控制器

设备上电后，可分两种情况讨论：

网络中已有DHCP Server —— 自动连接

星融元Asterfusion所有设备（包括交换机和AP）都可以作为 DHCP 客户端，出厂默认配置下即会自动发起DHCP请求，从网络中的DHCP Server 获取到地址和控制器 IP 地址。

#为了保证设备能获取到控制器的IP地址
#DHCP Server 需要能响应 option138 字段
#以下是 sc-dhcp-server 的配置参考
subnet 192.168.1.0 netmask 255.255.255.0{
range 192.168.1.100 192.168.1.200;
option routers 192.168.1.1:
option subnet-mask 255.255.255.0:
option capwap-ac-v4 “192.168.10.1” #控制器IP地址

网络中没有DHCP Server ——手动连接

很多初始状态的园区网络场景并没有DHCP服务器，此时我们只需串口接入一台Spine交换机，使能交换机上运行的ucentral-client 容器，并指定控制器IP。

该交换机连接上控制器后会自动从控制器处拿到用来配置其他Leaf交换机的文件，从而让整网设备都同控制器建立起连接。

sonic# config
sonic(config)# ucentral-client enable
sonic(config)# ucentral-client server 192.168.10.1 #控制器IP地址

第二步：自动生成拓扑和基础网络配置

完成设备与控制器连接后即可进入到控制器的规划拓扑标签下新建场景。

ACC控制器内置了名为中小型园区和中大型园区两种场景模板，两者都为Spine-Leaf架构的三层IP路由网络。

区别主要是后者在Spine和Leaf之间添加了一层Aggregation，从而轻松将Leaf交换机数量横向扩展到千台以上来适应更大规模的园区网络。

管理员仅需根据已拟定好的网络规划选择适合的模板，并设置交换机的对应型号、Spine/Leaf角色和数量，即可自动生成上述典型场景的推荐拓扑。

如下图所示，在生成的拓扑图上点击设备旁的编辑按钮即可继续设置各个互联端口。

最终效果可参考下图：场景组网下的设备上线状态、链路和接口关系一览无余。

此时点击右上方的基础网络配置，即可配置业务网的静态出口路由，或者Spine上行出口链路所使用的动态路由，例如BGP、OSPF、路由汇聚等。

整个过程，用户除了提供IP地址等基础信息，无需关注其他技术细节，ACC控制器将会根据网络拓扑动态生成所需配置。

第三步：批量配置无线和有线业务

无线业务配置

ACC允许用户在设备上线前创建预置配置模板。

点击无线配置标签下的Wi-Fi设置，为无线 AP 配置业务开通必要的基础信息，如 SSID 设置、安全策略等。控制器可以根据管理员的输入，自动生成相应的配置脚本。

控制器支持配置多个无线业务配置，并通过标签区分 (上图示例为default)。无线 AP 接入PoE交换机自动上线并连接到控制器后，便会根据导入库存时设定的标签信息自动拉取与标签一致的配置。

对于特定场景，管理员也可在高级配置中自定义更改AP的默认配置。

当部分 AP（比如面板型 AP）提供的有线接口接入了有线终端，用户也可以在LANs处配置诸如上下行接口、VLAN tag、VLAN ID 等信息。

有线业务配置

与无线业务类似，ACC控制器可在有线业务配置标签下快捷完成配置脚本的生成和下发。可选设置项包括交换机的 VLAN、 DSCP 中继、ACL、DAI/IPSG、802.1x 用户认证信息等。

点击上图“配置”按钮，等待所有执行完毕，我们就已完成园区有线无线业务的开通。根据客户现场测算，以上操作平均用时在30分钟左右。此时整网的交换机、无线AP以及各类终端状态信息皆可在控制器内统一、集中地呈现，用以辅助日常运维管理。

关于新一代云园区网的可视化运维管理功能，例如设置告警、执行巡检等等我们将在下一篇详细介绍，请持续关注。

A-Lab 杂谈 | 自动化+可视化的智算中心多租户网络配置工具

关注星融元

A-Lab 是星融元服务于新一代网络运维工程师的资讯专栏，你可以在这里找到各类基于开放网络技术架构的配置指导和技术分享。访问地址：https://asterfusion.com/alab-for-netdevops/

论是在通用云数据中心和智算中心，多租户网络的目标都是要允许多个用户或租户共享同一物理基础设施，同时保持各自的隔离和安全性。

多租户网络依赖于虚拟网络技术（如 VLAN、VXLAN 或 NVGRE）实现逻辑隔离。随着部署规模的增大，这些技术的配置和维护可能变得复杂，如果配置不规范，可能导致租户间冲突影响业务运行甚至严重的数据泄露。

今天我们分享的是一款用于多租户网络的配置工具：EasyRoCE-MVD（Multi-Tenant VPC Deployer ）。作为星融元AI智算网络方案的附加能力之一，MVD 帮助用户快速实现租户隔离，参数、存储、业务的多网联动和自动化部署。

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

根据配置脚本自动批量部署，支持图形化界面呈现配置细节并远程下发
MVD工具可独立运行在服务器上，也可以代码形式被集成到第三方管理软件

业务架构

多租户网络架构由 Underlay 网络和 Overlay 网络组成。

Underlay 网络指的是物理网络设施，由交换机、光缆等网络硬件构成，负责底层数据的物理传输，运行高效的路由协议（如 BGP）实现互联，通常采用 Spine-Leaf 架构组网，负责提供提供稳定带宽、低延迟和高可靠性，这是多租户网络的基础。

Overlay 网络是在 Underlay 网络之上构建的虚拟网络，解耦了物理网络与业务需求，为每个租户提供独立的网络空间（如子网、IP 地址、路由）用于实现租户隔离和自定义网络配置，是多租户网络实现的技术核心。

网络设计规划

首先是必不可少的网络规划，这一步需由工程师基于实际业务需求设计逻辑隔离，一般是采用 VLAN、VXLAN 技术划分虚拟网络，规划 IP 地址池及子网，避免地址冲突。VLAN 适合较小规模，而 VXLAN 扩展性更好，适合大规模部署。

作为示例，我们在EasyRoCE-AID（AI基础设施蓝图规划）工具引导下快速完成网络设计，并自动生成包含了以下信息的 JSON 配置文件(mvd.json) 作为 MVD 工具的输入。

自动生成配置

MVD 工具将解析上一步骤得到的JSON文件中的设备信息、BGP邻居信息，并为集群中的交换机生成对应配置。运行过程示例如下：

可视化呈现和远程下发

MVD 运行时会以 Exporter 形式将以上配置信息暴露于http监听端口（如18080,18180），该数据可被 Prometheus 调用并将其呈现在 Grafana 界面上，供用户直观浏览现网设备的拓扑信息。

用户点进配置文件可看到配置下的具体信息，对其进行二次核对后再自行决定下一步操作，比如选择批量下发或针对某一设备单独下发。

相关产品

星融元（Asterfusion）AI智算网络解决方案采用基于SONiC的开放NOS（AsterNOS）+ 100G-800G 超低时延以太网交换机硬件，全端口支持 RoCEv2 & EasyRoCE Toolkit。如需了解产品详情或项目定制方案请与我们联系。

完整揭秘：新一代园区网络运维管理全流程

关注星融元

前言：传统网络面临的结构性挑战显而易见，尤其是多地多分支机构的大型园区网络，哪怕引入了一个大而全的SDN控制器，但底层仍沿用着复杂的园区网络架构，有线无线两张网分离控制，真实使用体验依旧差强人意。

新一代的园区网应该是什么样的？且不论未来如何，在放眼可见的当下，除了承载常规的办公网业务，园区的网络基础设施已然在面对诸如物联网智能终端接入，频繁的无线漫游，以及各类公有云、本地私有云业务融合等等挑战。

园区网络的云化转型已成必然趋势。论及云化，不单是更高的带宽速率，更是要配合现代化的网络架构和灵活的运维方式，解决复杂业务和管理效率之间的矛盾。

TIP：电信业“开源运动”领导者

TIP（电信基础设施项目）成立于2016年，由Meta（原Facebook）联合多家全球电信运营商、技术公司和行业组织发起，是一个开放协作的行业联盟。其核心目标是推动电信基础设施的开放解耦化和软件化，通过技术创新降低网络部署和运营成本，加速全球通信网络的普及与升级。

TIP 推出的 OpenWiFi 和 OpenLAN Switching为企业园区网络场景带来了基于通用硬件和开源软件的解决方案。

uCentral 作为 OpenWiFi 通信框架的关键核心，是一种标准化数据模型，它定义了网络中关键配置数据的结构和语义，以确保整个网络的一致性和互操作性，并且该协议是开放可扩展的，随社区技术发展平滑演进。

OpenLAN Switching（OLS）将 OpenWiFi 的管理框架延展到了有线网络，显著扩展了OpenWiFi 的功能。实现形式是在交换机内部以容器形式运行一个客户端（uCentral Client），将有线网络纳入统一管理框架中。

OpenWiFi、OLS、局域网（LAN）

OpenWiFi和OLS 在局域网（LAN）中扮演各自不同角色，通过统一的北向接口与上层管理系统（Cloud SDK ）对接，并可复用成熟的开放网络组件（例如SONiC NOS）形成有线+无线、完整的端到端开放网络解决方案

Asteria Campus Controller（ACC）是星融元基于SONiC+ OpenWiFi/OLS 的云化网络的核心组成部分。

作为一款基于TIP社区标准的轻量级控制器软件，ACC 为园区有线网络和无线网络的统一管理提供了全面的解决方案。它可以无缝管理无线AP（包括第三方白盒AP）和所有搭载着星融元AsterNOS的SONiC交换机，自动执行网络配置和管理等关键任务。正常情况下，为一个中大规模的园区开通网络业务仅需30分钟。

部署方式

ACC支持三种部署方式：

本地部署（以docker形式部署在开放计算平台/服务器）
虚机部署（部署在虚拟机内，网络设备较多时适用）
云上部署（通过访问IP/域名，随时随地查看整网运行状态）

01、ACC 界面概览

登录ACC控制器后我们首先会看到一张全景地图，可以看到控制器纳管的网络自顶向下分为“根节点-组织-场所-设备”四个逻辑层。

（点开查看gif）

根节点作为系统默认节点，不可调整；
根节点下可建立“组织”，可以简单理解为一个管理域（例如一家公司或园区运营者可支配的管理范围）；
“组织”下可建立“场所”，对应着不同的办公区域或者分支机构；“组织”支持嵌套结构，即建立子组织，并继续建立子组织下的“场所”；
“场所”之下是设备层，展示了分配在该场所的物理网络设备，一般是按照有线设备（交换机）、无线设备（AP）分组。

02、内生的资产管理能力

值得一提的是，控制器内部自带了较为完善的资产管理能力，标准使用流程下即可自动完成数据整理并生成设备清单。

具体来说，我们购入新设备做的第一件事便是进入预计安装部署的组织或场所，比如下图的“1号办公楼”，在库存栏目点击按键选择手动导入设备或者基于模板批量导入。

此处导入的信息主要是设备的角色类型（Spine或Leaf）和序列号。待设备上电，控制器会自动根据设备的MAC将其纳入所属的组织/场所，并无额外操作。

导入完成后便可获得下面这张设备清单，它包含了设备所在场所、型号、名称、管理IP、许可证状态等信息字段。管理员可在此选择特定字段筛选，并在同一界面编辑调整清单信息。此处的“标签”字段对应的是控制器的配置模板，后续设备将据此标签信息从控制器拉取对应配置文件，做到真正的即插即用。

03、ACC带来的运维效率提升

上文已经提到，使用ACC为一个中大规模的园区开通网络业务仅需30分钟，开局效率的大幅提升主要来自于以下几点：

基于场景模板（全三层的Spine-Leaf 架构）自动生成规划拓扑
屏蔽实现细节，由控制器自动计算并通过ZTP机制下发基础网络配置
借助DHCP option 128 为交换机和无线AP同时提供“即插即用”的能力
图形化界面+自定义脚本，一键配置VLAN业务，DHCP中继，以及其他安全协议

下一篇我们将围绕上述内容详细展开，请持续关注。

A-Lab 杂谈 | 十年老网工，为啥这次没把智算服务器一次配通？

关注星融元

十年弹指一挥，当年的爆款热词“云计算”已然能搭上“传统” 二字当前缀；

十年弹指一挥，机房滚滚轰鸣声中，网工小王不知不觉熬成了老王；

老王不解啊，十年弹指一挥，咱亲手上架的服务器不说上千也有大几百，不就多了几张网卡，配个智算服务器怎会卡了壳？！

客官别笑，通用云计算中心与智算中心在主机侧网络架构层面的确存在显著差异，老网工偶尔走点弯路也是在所难免的啦。今天就让我们快速捋一捋其中缘由。

为啥出错？

传统CPU服务器多采用单网卡出口设计，通过OS内核协议栈实现网络报文转发，其网络拓扑相对简单，主要满足虚拟化资源的弹性调度需求。

源于AI训练任务对网络带宽的严苛要求，智算中心的GPU服务器普遍采用多网卡出口架构，用于接入参数网、存储网、业务网和带外管理网，其中通常会有8张网卡用于接入参数网，或称计算后端网络。而跨服务器的通信大多发生在同轨（Rail）的网卡/GPU之间。（请参考：关于智算的“多轨道网络架构”）

多轨道网络架构

老王遇到的机间通信失败问题主要发生在以下两种场景：

场景1：

智算业务报文从管理网段发出。两台GPU服务器A和B的8张网卡都接入到一张参数网，对应的网卡A1到A8、B1到B8，它们都分配到不同的网段，同轨网卡之间有互通需求（A1-B1，A2-B2…）

如果没有进行路由规划，通常在GPU服务器A的系统上会看到默认路由是业务网的，8个子网A1～8会产生8条对应的网段路由，报文会命中A的默认路由从管理网段发出，此时A1和B1是无法直接通信的。

场景2：

回程通信失败。如果网卡A1到A8、B1到 B8 都分配到同一个网段下的不同IP，在这种情况下在服务器B上通过B1尝试与A1通信，会发现报文可以到达A1，但是回包会命中默认路由之外的代价最低的路由，很可能会从其他7张网卡中的一张出去，导致通信失败。

通信失败情况下可能的系统路由配置：

路由配置

应对思路

当传统路由设置方法在智算环境下失效，一个可行的应对方式是提前规划GPU服务器内的路由，借助Linux的多路由表和策略机制实现更加灵活、精细的流量控制和路由管理功能。

具体而言：在Linux内增加一个自定义路由表，并通过策略路由告知系统，特定源地址的报文根据这张自定义路由表转发，并在该表中增加一条指定目的网段的表项（例如前往10.0.5.0/24的报文从指定网卡发出）。

多路由表（Multiple Routing Tables）：Linux支持多张路由表，这些路由表可以通过不同的标识符来区分，每张路由表中可以包含一组路由规则。Linux系统默认会存在一个主路由表，当不特别指定的时候路由规则会写入默认路由表。
策略路由机制（Policy Routing）：根据数据包的源目的IP、网卡等条件来选择合适的路由表进行转发。

更高效的实现方式

更高效的办法，当然是用脚本工具批量自动配置啊！

星融元（Asterfusion）AI智算网络解决方案中包含的EasyRoCE Toolkit – IRM工具（In-Node Route Map，GPU服务器内部路由规划）正是用于解决多网卡路由问题——根据已有的IP地址规划表，自动生成并对集群内所有GPU服务器下发内部路由规划和配置。

IRM工具运行过程中需要通过SSH和集群中的所有GPU服务器进行交互，一般运行在管理节点上。

GPU服务器内部路由规划

网工老王仅需完成三步微操：

1、将IRM工具上传到管理节点；

2、指定需要解析的路由规划信息文件。该文件可在EasyRoCE-AID （AI Infrastructure Descriptor，AI基础设施蓝图规划）工具引导下手动填写，形式为下图所示的excel表格，主要包含IP和接口地址规划、Rail平面划分等构造智算网络的必备信息；

IP和接口地址规划、Rail平面划分

3、运行IRM工具脚本。等待上述规划信息完成转换重组后，IRM工具会生成包含路由配置的JSON文件并下发到集群，随后网络运维人员即可查验到所有GPU服务器内部的策略路由都已成功生效，同一个Rail平面内的网段按照预期正常互通。此外，该阶段生成的JSON文件亦可复用于其他客户自定义/第三方工具。

DeepSeek优化徒劳？揭秘99%的AI推理集群都适用的组网设计

关注星融元

DeepSeek的优化，精细但门槛极高

作为开源周的“彩蛋”，DeepSeek于上周六展示了采用混合专家模型（MoE）DeepSeek-V3 / R1 所使用的推理架构的整体方法——从增大吞吐和降低时延的目标出发，再次优化了PD分离架构，不过暂时没有开源代码。

（MoE）DeepSeek-V3 / R1

与Llama等采用张量并行（TP）的Dense（稠密）模型不同，混合专家（MoE）模型通过组合多个专家模型来处理复杂任务，每个专家模型专注于输入数据的不同部分，每次计算任务只需激活特定专家（而非整个神经网络）。

DeepSeek-V3 / R1 的推理系统架构一方面引入了更复杂的跨节点和多节点的传输提升计算效率和改善内存墙，同时也通过异步通信和流水线调度设计，确保由此增加的通信开销被计算任务掩盖。

值得注意的是，根据官方公布的信息，若要充分发挥DeepSeek MoE 模型的能力，起步资源是320卡，且不论在未开源的情况下面临的技术挑战。

综合成本和需求考量，上述面向专家并行的推理系统优化仅在部分toC云计算场景具备一定研究意义。现阶段toB行业大模型以及边缘计算场景仍以Dense模型为主，需要高并发的大集群平台部署可延续现有主流的算力网络设计思路，面向本地低并发需求则可采用大内存单机部署方案。

回顾：AI推理集群的PD分离和流量特征

大模型的推理任务一般分为两个阶段，一是Prefill，处理所有输入的 Token，生成第一个输出 token 和 KV cache，是算力密集型；二是Decode，利用 KV Cache 进行多轮迭代，每轮生成一个 token，需要反复读取前面所有token的 Key 和 Value，瓶颈在于内存访问。

从用户实际体验层面看，推理过程中最关键的指标是 “第一个Token的延迟” （Time To First Token, TTFT）和后续token输出的延迟（Time Per output Token, TPOT）。

如果 Prefill 和 Decode 两个阶段在同一张GPU卡上运行，则容易发生资源争抢影响到 TTFT 和 TPOT 表现，尤其是当用户输入一段长 prompt 时，不光需要较多算力来支撑prefill运算, 也需要大内存来存储 KV Cache。

Prefill-Decode

因此，业界通常采用 Prefill-Decode 分离的架构：用高算力卡做 Prefill（prefill server）, 低算力卡做 Decode（decode server）, Prefill节点在完成计算传输 KV cache 后即可释放本地显存。

参阅：一文揭秘AI智算中心网络流量 —AI推理

AI推理系统的 Scale-out 组网设计

推理集群的工程部署方面，由于 Prefill 和 Decode 采用的GPU并行方式不一样，Prefill和Decode集群是相互独立的，但两个集群间需要互联以同步KV cache。从两个阶段的输入输出来看，Prefill 流量的特征是低频大流量，要求大带宽；Decode 阶段流量的特征是高频小流量，要求低时延。

1、分离网络架构

分为Prefill网络和Decode网络，分别负责本集群内流量，两个集群之间的流量通过互联网络实现
两个网络分别运维管理，但Prefill和Decode GPU之间的流量至少需要3跳

2、统一网络架构

单个网络同时负责集群内和集群间流量
网络统一运维管理，Prefill和Decode GPU之间流量可一跳直达

统一网络架构

我们推荐采用统一网络架构，借助 QoS、自适应路由技术对 Prefill 和 Decode 流量分别处理。

Rail-only 拓扑

Rail-Only

GPU服务器内部：每四个GPU作为一组，共享一个并行推理网卡，连接到同一个PCI Switch,两组GPU之间的通信通过两个PCI Switch之间的直连通道完成；
GPU服务器之间：同一组号的GPU之间的通信通过交换机直接完成；不同组号的GPU之间的通信，先通过PCI Swtitch将流量路由到另一组的网卡，然后通过交换机完成

小规模并行推理网络拓扑

每台推理服务器有8张GPU，2张400G网卡，双归连接到两台CX732Q-N
16个推理服务器（128张GPU）和2个CX732Q-N组成一个PoD。Prefill和Decode服务器可能属于不同PoD
可横向扩展至64个PoD

中大规模并行推理网络拓扑

每台推理服务器有8张GPU，2张400G网卡，双归连接到两台CX864E-N
64个推理服务器（512张GPU）和2个CX864E-N组成一个PoD，Prefill和Decode服务器在同一个PoD，服务器间一跳可达
可横向扩展至64个PoD

拓扑设计仅供预览参考，方案均采用星融元（Asterfusion）提供的CX-N系列 AI智算网络产品：基于SONiC的开放NOS（AsterNOS）+ 100G/200G/400G/800G 超低时延以太网交换机硬件，全端口支持 RoCEv2 & EasyRoCE Toolkit。了解产品详情或项目定制方案请与我们联系。

云化园区

网络操作系统（SONiC）

可视交换机

开放硬件平台

标签： 技术实现

关注星融元

什么是哈希极化？

主动路径规划配置逻辑

借助 EasyRoCE 工具配置

PPD 2.0 升级了什么？

使用演示

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

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

第三步：选择下发配置

关注星融元

关于SONiC

SONiC的发展前景

SONiC 架构是否可靠？

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

SONiC 的生态现状

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

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

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

数据中心（AsterNOS-DataCenter）

企业园区（AsterNOS-Campus）

最新实践：边缘路由（AsterNOS-VPP*）

AsterNOS 的交付模式

软硬一体化交付

软件化交付

虚拟化试用 （vAsterNOS）

关注星融元

让我们从“空口”说起

空口资源为什么重要？

空口利用率：无线网性能的关键指标

用“减法思维”重构园区网络架构

关注星融元

网络可视

网络运行状态的集中呈现

有线、无线终端状态集中呈现

网络设备状态

基于SONiC的网络可视化：NPB 2.0

告警管理

巡检与固件管理

近期文章

名词解释

背景

工作原理

IP层对ECN的支持

IP层ECN报文交互

CNP报文格式

TCP层对ECN的支持

TCP层ECN报文交互

两个ECT Codepoints机制

Fast ECN

配置实例

网络拓扑

服务器端配置

交换机端配置

配置CISCO-LIKE命令行

交换机A

发送流量包

发送流量包

交机限速

观察拥塞情况

交换机A

Server1

配置交换机ECN功能

交换机A

Server1

Server2

观察ECN功能

清空流量包计数

发送IB流量

交换机A

Server1

参考资料

最新动态

关注星融元

只需三步

第一步：设备自动连接控制器

标签：技术实现

虚拟化试用（vAsterNOS）