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

标签: 技术实现

告别手动开号!基于 OAuth 协议的企业Wi-Fi准入进入“自动驾驶”时代

基于OAuth的企业网络智能准入新方案

基于Oauth的接入认证,企业WiFi准入方案

传统的企业网络管理中,IT 管理员常被繁琐的准入配置所困扰:

  • 入职离职忙断腿: 员工入职要开账号,离职要销账号,稍有延迟就存在安全风险。
  • 设备杂乱难管理: 手机、电脑、摄像头、访客,所有终端混在一起,权限划分全靠口头通知。
  • 认证体验差: 静态密码容易泄露,且员工总在忘记密码。

今天,我们分享一种基于 OAuth 协议的企业级准入认证方案,让网络管理与企业办公系统(飞书、钉钉、企业微信)深度融合。

什么是 OAuth?

OAuth,全称为 Open Authorization,或开放授权。它是一种安全的授权开放网络标准,允许用户在不提供真实密码的情况下,通过第三方应用颁发临时且具备特定权限的安全令牌,来完成认证授权交互。与传统 Radius 的用户名+密码认证不同的是,它相当于给第三方应用发了一张“临时通行证”,而不是把家门钥匙(账号密码)直接交给它。

图片来源:Oracle

例如我们在各大 APP 登录界面常见的 “使用微信/QQ/微博账号登录” 或 “允许某APP读取您的联系人”,背后就是 OAuth 在起作用,用户不需要在每个新 APP 上都单独注册、背诵一套新密码,既提升了体验,又保护了核心隐私。

基于 OAuth 的园区网接入认证

既然办公软件的账号已经包含了所有的员工信息和所属部门,为什么不把这套已经管理好的账号权限数据直接搬到企业园区网认证系统里?

简单来说,在企业园区网内支持 OAuth 认证相当于将接入网络的“钥匙”交给了你已经拥有的、支持 OAuth 协议的企业办公软件账号,像是飞书/钉钉/企微等等。

当前 星融元园区智网解决方案 已支持基于 OAuth 的接入方式。

无感身份确认:当员工连接到企业网络,无需再手动输入网络密码。系统会自动拉起飞书或钉钉进行身份确认,秒级读取该用户在企业组织内的办公身份。

自动化维护账号生命周期:只要现有办公软件里有该员工的账号,就能允许其上网。一旦员工离职、在办公系统中被停用,其网络访问权限也会同步秒级失效!

OAtuth认证界面示例,联动飞书应用

星融元园区智网的控制器也采用OAuth登录,可支持通过GitHub/飞书/Microsoft/Google 等第三方平台账号,免注册在线体验。

点击下方阅读原文跳转,或访问地址:https://app.cloudswitch.io/

安全性保障:动态 VLAN 授权

在OAuth 解决“能不能上网”的基础上,面对账号权限数量多的复杂场景,动态 VLAN 授权技术则进一步解决了根据不同用户身份让其“上对网”的问题。

动态 VLAN 通过认证服务器中已建立的“用户组”与“VLAN”的映射关系,在终端接入的瞬间,自动将其划分到对应的隔离网络中,实现真正的精细化权限控制:

  • 财务部员工:OAuth 认证通过后,认证服务器自动识别其账号对应的用户组,将其终端划入财务专用 VLAN,使其能访问财务专用系统,其他部门无法探知。
  • 研发部员工:自动划入研发 VLAN,拥有访问代码仓库和测试服务器的权限。
  • 行政和其他部门:仅能访问公司内部公共系统和互联网,从逻辑上做到网络隔离。

多场景智能接入:灵活组合,内外有别

除了办公电脑等终端,园区网内还存在大量的“非员工设备”。为了彻底告别“终端杂乱、权限靠口头通知”的乱象,我们支持多种认证方式灵活组合,因地制宜地实施精细化准入:

内部员工

采用 OAuth 认证,绑定办公账号,享有最高级别的安全防护,权限与办公账号绑定动态调整,人员离职自动销户。

访客接入

采用 Portal 认证,支持深度自定义 Portal 认证页面。企业可自主上传品牌 LOGO、配置专属背景、发布企业公告,让每一次访客连网都成为一次高品质的品牌展示。访客可通过手机号码自主登录划分至隔离的“访客 VLAN”,限制其访问企业内网资源,确保行为可审计、内网绝对安全。

哑终端

针对摄像头、打卡机、打印机等设备采用 MAC 地址白名单认证。后台精准识别、无感接入,并自动绑定至专属的物联 VLAN,一旦检测到接入的终端信息与录入信息不一致,立刻产生告警,邮件通知管理员,避免MAC地址假冒。

结语

从传统的“静态账密”走向基于 OAuth 的现代化认证架构,不仅是认证技术层面的迭代,更是网络管理理念的一场升级。相比于传统认证方式,采用 OAuth 认证能为企业带来以下三大核心价值:

1. 从“多次繁琐登录”到“一次认证,全网通行”

打破信息孤岛。用户只需在现有的办公系统(飞书/钉钉/企微)认证一次,即可安全访问授权范围内的所有网络资源,员工再也不会因为“忘密码”而投诉 IT。

2. 从“密码暴露风险”到“Token 令牌级安全”

OAuth 引入的“令牌(Token)”机制,认证过程不暴露核心凭证,且令牌具备时效性与精细化的权限控制,极大收敛了企业的安全攻击面。

3. 从“烟囱式人工维护”到“自动化生态联动”

配合星融元园区智网控制器的 RestAPI 能力,让网络的准入权限、动态 VLAN 下发与企业的 HR/办公系统自适应联动,彻底终结了管理员人工开户、销户的“断腿”日常。


产品型号:云化园区交换机
功能特性:DHCP Snooping,动态ARP检测,ND Snooping,IPSGv4/v6,PTP……
应用场景:校园网,企业网,分布式网关,网络接入认证……
最后更新:2026-05-22…


相关文章

星融元数据技术有限公司是领先的开放网络解决方案提供商,产品包括网络操作系统、数据中心交换机、AI智算交换机、园区交换机、开放式企业级路由和新一代网络可视化产品等。为行业企业、数据中心和云运营商提供基于通用解耦硬件和 SONiC 软件框架的全场景交钥匙网络解决方案,帮助用户构建AI时代中立、透明,易于运维、高性价比的基础网络。

?关注 @星融元Asterfusion 微信公众号
WeChat QR Code

释放极致算力:AI智算后端网络架构设计与实践指南

从架构选型到无损网络,构建32至8192 GPU的高效RoCEv2集群

AI后端网络设计的封面图

前言

AI集群涉及三种网络:Frontend Fabric、GPU Backend Fabric和Storage Backend Fabric。其中,Frontend Fabric指前端网络,用于连接互联网或存储系统,加载训练数据;GPU Backend Fabric指GPU后端网络(又称计算网),用于支撑GPU间的通信,提供无损连接并实现集群规模扩展,是承载GPU节点间训练数据交互的核心;Storage Backend Fabric指存储后端网络,负责海量数据的存储、检索和管理,实现GPU与高性能存储设备之间的通信。

本文聚焦不同规模下的400G AI智算GPU后端网络设计,以星融元数据中心400G/800G高密度接口交换机为核心硬件载体,采用Clos组网,基于Rail-only、Rail-optimized两种架构,提供标准化部署的解决方案。

读者对象

本手册主要适用于方案规划设计及现场实施人员,相关人员应具备以下能力:

  • 熟悉Asterfusion数据中心网络交换机产品
  • 了解RoCE、PFC、ECN等技术

1 概述

AI/ML(Artificial Intelligence/Machine Learning,人工智能/机器学习)应用的快速演进推动大规模AI集群的需求持续攀升,其核心挑战在于:AI训练属于典型的网络密集型工作负载,GPU节点间需高频交互海量梯度数据与模型参数,对网络基础设施提出“高带宽、低时延、抗干扰”三大核心诉求。

传统通用型数据中心网络难以适配AI训练中大象流主导、低熵值的流量特征,易引发带宽瓶颈、传输拥塞及时延抖动等问题,无法满足AI训练的严苛需求。后端网络作为AI集群的“算力传输中枢”,直接决定GPU算力的释放效率。因此,亟需一套高效的集群组网方案,满足低时延、高吞吐的机间通信。

2 AI后端网络架构

2.1 Rail-Only架构

连接到不同服务器同编号GPU的Leaf节点,被定义为一个Rail(轨道)平面,即Rail N通过第N台Leaf交换机实现所有N号GPU的互联。如下图,每台服务器上的GPU编号为0~7,对应Rail 1~Rail 8。同轨传输是指源GPU与目标GPU的对应网卡接入到同一台Leaf交换机。LLM(Large Language Model)训练通过混合并行(数据并行、张量并行、流水线并行)策略优化流量分布,使得大部分流量集中在节点内和同轨道内。

Rail-only架构

图1 Rail-only架构

Rail-only架构采用单层组网设计,将整个集群的网络在物理上划分为8个独立的轨道,不同节点的GPU间通信均为同轨传输,轨道内通信可实现“一跳直达”。

相较于传统Clos架构,Rail-only架构省去了Spine层,通过减少网络层级节省交换机和光模块数量,进而降低硬件成本,是专为AI大模型训练量身定制的低成本、高性能网络架构,适用于小规模计算集群。

2.2 Rail-Optimized架构

在Rail概念的基础上,把由一组Rail组成的基础构建单元视作一个Group,其中包含若干台Leaf交换机与GPU服务器。当集群规模扩大时,可通过水平堆叠多个Group来扩展,从而支撑更大规模的集群部署。

可将计算网想象成一套铁路系统:计算节点是装载算力的“车站”,Rail是连接各站同号GPU的“专属铁路线”保障高速直达;Group则是整合多条轨道及其配套交换机的“标准站台区”单元。通过这种模组化的堆叠,智算中心能像搭积木一样横向扩展,既保证了单条轨道内的极速通信,又实现了万卡集群的高效互联。

Rail-optimized架构

图2 Rail-optimized架构

如上图,Rail-optimized(轨道优化)架构的核心设计思路是将每台服务器的同号网卡接入同一台Leaf交换机,确保GPU间的多机通信尽可能经过最少跳数内完成。在这种设计下,GPU节点间的通信可利用自身的NVSwitch¹内部通路,只需要经过一跳即可到达,而无需跨多台交换机,避免产生额外时延。具体如下:

  • 服务器内互联:8张GPU通过NVLink总线连接至NVSwitch,实现服务器内部GPU间的低时延通信,降低Scale-Out网络传输压力;
  • 服务器-网络互联:所有服务器遵循统一的连线逻辑,网卡按“NIC1-Leaf1、NIC2-Leaf2……”的规则,分别接入多台Leaf交换机;
  • 网络层互联:Leaf与Spine交换机采用全互联模式,采用2层Clos架构。
¹ NVSwitch为NVIDIA推出的承载高速NVLink的交换芯片,在Scale-Up网络实现多GPU以NVLink能够达到的最高速度进行通信。

在多级Clos架构设计中,需要合适的收敛比(Oversubscription Ratio)。收敛比是指下行总带宽(Leaf节点到GPU服务器)和上行总带宽(Leaf节点到Spine交换机)的比值(如下图)。若收敛比大于1:1,当下行流量达到线速时,Fabric将没有足够的容量来处理GPU间的流量,可能引发拥塞或丢包。

Rail-optimized架构中的收敛比

图3 Rail-optimized架构中的收敛比

图3 Rail-optimized架构中的收敛比

简言之,收敛比越小,通信越无阻塞,但成本越高;收敛比越大,成本越低,但易出现拥塞。在高性能AI智算网络中,一般建议使用收敛比1:1的无阻塞网络设计。

2.3 流量路径分析

上述两种架构在节点内、轨道内通信路径类似。下面以Rail-optimized架构为例,详细分析不同情况下的GPU间通信路径。

  • 节点内通信

机内GPU间的通信通过NVSwitch完成,无需经过外部网络。

节点内GPU通信示意图

图4 节点内GPU通信示意图

  • 同轨通信

同轨GPU间的通信经过一台Leaf交换机转发。

同轨GPU通信示意图

图5 同轨GPU通信示意图

  • 跨轨(不开启PXN)及跨组通信:

未开启PXN(PCIe x NVLink)²,则跨轨GPU间的通信需要跨Spine传输。跨组的GPU间通信也是如此。

 跨轨(不开启PXN)及跨组GPU通信示意图

图6 跨轨(不开启PXN)及跨组GPU通信示意图

² PXN是NCCL中的一项关键技术,使GPU能够先通过NVLink将数据聚合到节点内与网卡直连的GPU,再由该GPU通过PCIe高速发送到网卡,提升跨节点集体通信的效率。
  • 跨轨(开启PXN)通信:

配合PXN技术,则无需跨Spine,单跳完成传输。

跨轨(开启PXN)GPU通信示意图

3 支撑无损网络的技术

3.1 DCQCN技术

RDMA(Remote Direct Memory Access,远程直接内存访问)技术作为一种基于网络的内存访问技术,被广泛应用于超算、AI训练、存储等多个场景。RDMA最初在InfiniBand网络上实现,后来发展出通过以太网承载RDMA的网络协议——iWARP和RoCE(RDMA over Converged Ethernet,以太网RDMA)。

RoCEv2是基于无连接的UDP协议,其无损传输依赖端到端拥塞控制机制,因此需要PFC(Priority Flow Control,基于优先级的流控)和ECN(Explicit Congestion Notification,显式拥塞通知)技术来保证数据传输的可靠性。然而,如果仅依赖PFC可能会导致交换机过早停止转发流量,影响转发性能;如果仅依赖ECN,由于ECN反馈路径较长,可能会导致端侧降速不及时,进而出现丢包。为此需要一种协同机制,让PFC和ECN发挥互补作用,实现无损传输。

(请参阅:一文梳理基于优先级的流量控制(PFC))

DCQCN(Data Center Quantized Congestion Notification,数据中心量化拥塞通知)正是这样一种混合拥塞控制算法:在拥塞初期触发ECN机制,让GPU网卡平缓降低发送速率;当拥塞加剧时,将PFC作为兜底手段,逐跳快速阻断上游交换机的对应流量。

DCQCN的协同逻辑严格遵循特定顺序:

  • ECN在前,柔性控速

当交换机队列开始积压时,会触发WRED阈值并对数据包进行打标。接收端收到ECN置位的数据包,开始向发送端反馈CNP(Congestion Notification Packet,拥塞通知报文)。发送端收到CNP后,平滑降低发送速率,将拥塞控制在一定范围内。此时网卡仅放缓发送速度,流量仍保持传输,避免突然中断。

  • PFC在后,及时刹车

若拥塞持续加剧,导致交换机缓冲区占用达到xOFF阈值,交换机会向上游设备发送pause帧。上游设备收到后会临时停止对应优先级队列的传输,防止丢包。

  • 流量恢复

当缓冲区水位下降至xON阈值以下,交换机会发送恢复指令,通知上游设备可恢复对应队列的流量传输。

配置合适的PFC、ECN参数至关重要,既要保证ECN能够在拥塞早期触发及时调整速率,避免不必要的PFC触发,同时要保证PFC在必要时及时触发,防止丢包。这对网络部署或运维工程师提出了较高要求。一般建议遵循如下原则:WRED Min<WRED Max<PFC xON<PFC xOFF。

为简化无损以太网部署和运维的难度,星融元在AsterNOS网络操作系统上推出“一键RoCE”功能。该功能针对RoCEv2场景的配置需求,支持自动生成RoCE参数,实现了业务级的命令行封装,大幅提升RoCEv2场景下的可维护性和可用性。

3.2 负载均衡技术

ECMP(Equal-Cost Multi-Path,等价多路径)逐流负载均衡,是数据中心网络中应用最广泛的选路策略。通过对数据包的固定字段(如源/目的MAC地址、IP五元组等)作为哈希因子,利用哈希算法生成哈希值,在多条路径中随机选路。这种基于数据包的特征字段的负载均衡方式也称为静态负载均衡。

然而,逐流负载均衡在流量特征单一时易引发负载分担不均,尤其当“大象流”出现时,会加剧所选中成员链路的拥塞,严重影响网络性能,甚至引起丢包。深度学习模型高度依赖于All-Reduce、All-Gather、Broadcast等集合通信操作,这类操作会在各GPU间产生密集流量交互,传输速率通常高达每秒数太比特(Tbps)。同时,大模型参数同步依赖的集合通信存在木桶效应——若流量分布不均,即使只有一条路径发生拥塞,也可能拖慢整个训练任务的进度,放大负面影响。因此,传统逐流负载均衡方式并不适用于基于RoCEv2的AI后端网络。

针对这一问题,本文介绍三种替代传统逐流负载分担的技术方案:基于子流(Flowlet)的负载均衡技术、智能选路技术,以及包喷洒技术。

3.2.1 自适应路由切换

ARS(Adaptive Routing and Switching,自适应路由切换)是一种基于Flowlet(子流)的负载均衡技术。其借助ASIC提供的硬件ALB(Auto-Load-Balancing)³ 能力,能够在减少乱序的同时实现近乎逐包负载分担的均衡性。该技术通过将哈希值相同的数据流按一定时间间隔分割成一系列Flowlet,再通过实时感知端口的带宽利用率、队列深度等链路质量指标,将Flowlet主动分配至空闲路径,从而提升整体网络带宽利用率。

(请参阅:一文看懂ARS(自适应路由切换):基于 Flowlet 的动态负载均衡技术)

3.2.2 智能选路

智能选路技术根据负载均衡实现的方式分为动态和静态两种。

动态智能选路是一种基于感知路由的负载均衡技术,综合评估带宽使用、队列占用、转发时延等关键参数,精准判断网络路径质量。其中,带宽和队列使用基于ASIC硬件寄存器统计,精度达百毫秒级;转发时延基于INT(In-band Network Telemetry,带内网络遥测)技术,精度达纳秒级。各交换机实时检测路径质量,通过BGP扩展属性传递信息,并结合逐流的动态WCMP(Weighted Cost Multipath,加权多路径),将流量动态分配至最佳路径,避免网络瓶颈,提升带宽利用率。

静态智能选路是一种基于预设策略的负载均衡技术,将GPU发往Leaf不同下行接口的流量通过业务隔离与定向转发,结合PBR(Policy-Based Routing,策略路由)将流量重定向至指定的Leaf上行接口,从而进入预设的Spine设备,实现1:1收敛下的上行负载均衡。该技术将特定流量与物理路径强绑定,适用于对路径稳定性要求较高、流量模型相对固定的场景。

(请参阅:动态感知+智能决策,一文解读 AI 场景组网下的动态智能选路技术)

3.2.3 包喷洒

包喷洒⁴是一种逐包负载均衡技术,通过将数据包均匀喷洒到各条链路上,避免单一路径拥堵。包喷洒技术包含两种算法:

  • Random算法:将数据包随机分散至各条链路;
  • Round Robin算法:按顺序将数据包逐一、等量地分散至各条链路。

尽管逐包负载均衡在理论上能实现网络利用率最大化,但也面临显著挑战——实际组网中,当数据包通过不同链路能到达目的地时,由于各链路的转发时延不同,造成接收端报文出现乱序,影响整体性能。因此,逐包负载均衡技术需要硬件层面的强力支持,即端侧高性能网卡需具备乱序重排能力。

(请参阅:51.2T 800G AI智算交换机软硬件系统设计全揭秘)

³ ⁴ CX864E-N型号产品具备该能力

4 搭建400G AI后端网络

AI集群大小根据工作负载的要求不同存在差异,综合考虑硬件成本及可扩展性,不同规模GPU集群下的方案设计建议如下:

表格 1 不同规模GPU集群下的方案设计建议

GPU集群规模 方案设计建议
32~256 GPUs 选用CX732Q-N作为Leaf节点,采用单层Clos组网Rail-only架构,最多支持256个GPU接入。
256-1024 GPUs 选用CX864E-N作为Leaf节点,采用单层Clos组网Rail-only架构,最多支持1024个GPU接入。
1024-2048 GPUs 选用CX732Q-N作为Leaf节点,CX732Q-N或CX864E-N作为Spine节点,采用2层Clos组网Rail-optimized架构,最多支持2048个GPU接入。即使只有一组Leaf,考虑到故障容错,也建议至少部署2个Spine节点。
2048-8192 GPUs 选用CX864E-N作为Leaf、Spine节点,采用2层Clos组网Rail-optimized架构,最多支持8192个GPU接入。

下面将详细介绍标准化组网方案和设备选型。

4.1 小规模集群组网设计

4.1.1 标准化组网方案

小规模400G AI后端网络标准化组网

小规模400G AI后端网络标准化组网

上图为一个32计算节点(256个GPU)的400G AI后端网络Rail-only架构组网图,部署8台CX732Q-N作为Leaf节点,其核心设计原则如下:

  • 每个GPU连接专用网卡,每台服务器的网卡按照“NIC1-Leaf1、NIC2-Leaf2……”的规则接入到Leaf交换机,为每个Rail规划独立子网,Leaf交换机作为Rail内的默认网关。
  • 网络采用单层Clos架构;
  • Leaf交换机启用一键RoCE,提供无损网络。

4.1.2 设备选型

建设小规模400Gbps RoCEv2网络,可选用星融元数据中心交换机CX864E-N或CX732Q-N进行部署。以NVIDIA DGX H100 GPU服务器为例,每台服务器搭载8个NVIDIA H100 Tensor Core GPU。不同型号交换机的最大接入能力如下表所示:

表格 2 Rail-only架构下不同型号交换机的最大接入能力

型号 单台最多接入的GPU数量 8台设备最多接入的GPU数量 8台设备最多接入的服务器数量
CX732Q-N 32 256 32
CX864E-Nv 128 1024 128

说明:CX864E-N配备了64个800GE接口,通过接口拆分,最多可提供128个400G接口。

举例:假设要构建一个64台H100服务器(512个GPU)的GPU集群,选用CX864E-N作为Leaf节点。则:

  • Leaf节点数量 = 512÷128 = 4
  • 最大可扩展的Leaf节点数量 = 8
  • 最大可扩展的GPU数量 = 8×128 = 1024

对于Leaf节点的计算及可扩展的最大规模,有如下总结:

  • Leaf节点数量 = 集群所需的GPU数量÷单台设备最多可接入的GPU数量
  • 最大可扩展的Leaf节点数量 = 每台服务器的GPU数量
  • 最大可扩展的GPU数量 = 每台服务器的GPU数量×单台设备最多可接入的GPU数量

4.2 中大规模集群组网设计

4.2.1 标准化组网方案

中大规模400G AI后端网络标准化组网

图9 中大规模400G AI后端网络标准化组网

上图为一个128计算节点(1024个GPU)的400G AI后端网络Rail-optimized架构组网图,部署24台CX864E-N(8台Spine节点,16台Leaf节点),包含两个Group,每个Group 8台Leaf节点。其核心设计原则如下:

  • 每个GPU连接专用网卡,每台服务器的网卡按照“NIC1-Leaf1、NIC2-Leaf2……”的规则接入Leaf交换机,为每个Rail规划一个子网,Leaf交换机作为Rail内的默认网关。
  • 网络采用2层Clos架构,Spine与Leaf全互联,利用IPv6 link-local特性建立unnumbered BGP邻居,宣告各Rail的网段路由,实现路由交换,无需为Leaf-Spine互联接口规划IP地址;
  • Leaf下行与上行容量的比值应严格遵循1:1收敛比,保证无阻塞传输;
  • Leaf、Spine交换机启用一键RoCE及负载均衡特性,构建无损网络。

4.2.2 设备选型

建设中大规模400Gbps RoCEv2网络,推荐选用星融元数据中心交换机CX864E-N、CX732Q-N,核心依托两款设备的超低转发时延特性——CX864E-N端到端转发时延低至560ns,CX732Q-N更可达500ns,可实现同轨传输约600ns超低时延,跨轨传输(Leaf-Spine-Leaf)三层转发的端到端网络时延控制在2μs以内,充分满足RoCEv2网络对低时延的严苛要求。

在Rail-optimized组网中,单Group内的Leaf节点数量与每台服务器的GPU数量(即Rail数量)相关。以NVIDIA DGX H100 GPU服务器(每台搭载8个GPU)为例,一个Group需配置8个Leaf节点,对应8个Rail。

每个Group可接入的服务器最大数量与Leaf节点的接口形态相关。为保证1:1收敛比,Leaf节点的一半接口用于连接GPU服务器,另一半接口则连接Spine节点,因此每个Group最多可接入的GPU服务器为Leaf节点可用接口数量的一半。不同型号交换机的最大接入能力如下表所示:

表格 3 Rail-optimized组网下不同型号交换机每个Group的最大接入能力

Leaf节点型号 每台设备可用的400G接口数量 每个Group最多可接入的GPU/服务器数量
CX732Q-N 32 128/16
CX864E-N 128 512/64

说明:CX864E-N配备了64个800GE接口,通过接口拆分,最多可提供128个400G接口。

Spine节点数量与Leaf节点的接口数量相关。假设Leaf、Spine节点分别提供了M、N个400G接口,则所需的Spine节点的数量=(总Leaf节点数量×M÷2)÷N。若Leaf、Spine选用同一款机型,则Spine节点的数量 = Leaf节点数量÷2。

举例:

假设要构建一个512台H100服务器(4096个GPU)的GPU集群,选用CX864E-N作为Leaf、Spine节点。则:

  • 每个Group中的Leaf节点数量 = 8
  • 每个Group最多可接入的服务器数量 = 128÷2 = 64
  • 每个Group最多可接入的GPU数量 = 64×8 = 512
  • Group数量 = 4096÷512 = 8
  • 总Leaf数量 = 8×8 = 64
  • 总Spine数量 = 4×8 = 32

设计计算网络时,需同步考虑可扩展性。为保证全连接,该网络最多支持的Group数量受限于Spine节点的可用接口数。以CX864E-N为例,最多可连接128台Leaf节点,每个Group含8台Leaf,则最多支持16个Group。选用CX864E-N作为Leaf、Spine节点时,可扩展的最大规模如下:

  • 最大支持的Group数量 = 128÷8 = 16
  • 最大支持的服务器数量 = 16×64 = 1024
  • 最大支持的GPU数量 = 16×512 = 8192

下表分别为选用CX864E-N、CX732Q-N部署不同GPU数量后端网络的节点配置需求:

表格4 选用CX864E-N部署不同GPU数量的后端网络所需的节点配置需求

总GPU数/服务器数 Leaf节点数量 Spine节点数量 每台Leaf与Spine之间的400G链路数
256/32 4 2 32
512/64 8 4 16
1024/128 16 8 8
2048/256 32 16 4
4096/512 64 32 2
8192/1024 128 64 1

表格 5 选用CX732Q-N部署不同GPU数量的后端网络所需的节点配置需求

总GPU数/服务器数 Leaf节点数量 Spine节点数量 每台Leaf与Spine之间的400G链路数
128/16 8 4 4
256/32 16 8 2
512/64 32 16 1

针对节点配置需求,有如下总结:

  • 每个Group中的Leaf节点数量 = 每台服务器的GPU数量
  • 每个Group最多可接入的服务器数量 = Leaf节点的可用接口数÷2
  • 每个Group最多可接入的GPU数量 = 每个Group最多可接入的服务器数量×8
  • Group数量 = 集群所需的GPU数量÷每个Group最多可接入的GPU数量
  • 总Leaf数量 = 每个Group中的Leaf节点数量×Group数
  • 总Spine数量 = 总Leaf数量×M÷2÷N

针对可扩展的最大规模,有如下总结:

  • 最大支持的Group数量 = Spine节点的可用接口数÷每个Group中的Leaf节点数量
  • 最大支持的服务器数量 = 最多支持的Group数量×每个Group最多可接入的服务器数量
  • sGPU数量 = 最多支持的Group数量×每个Group最多可接入的GPU数量

5 结语

本方案采用Rail-only、Rail-optimized架构设计,减少集群中GPU间通信的跳数,加速all-to-all性能并缩短训练时间。本方案可有效支撑不同规模的AI集群计算网部署,如想了解具体配置实施案例,请后台回复“AI智算后端网络最佳实践”。

方案白皮书下载地址:AI智算后端网络设计指南


产品型号: 星融元(Asterfusion)CX864E-N (64 x 800G OSFP)
功能特性:RoCEv2, PFC, ECN, DCBX ……
应用场景:GPU算力集群,分布式存储
最后更新:2026-05-18



产品型号: 星融元(Asterfusion)CX732Q-N (32 x 400GE QSFP-DD/QSFP56/QSFP28/QSFP+)
功能特性:RoCEv2, PFC, ECN, DCBX ……
应用场景:GPU算力集群,分布式存储
最后更新:2026-05-18


相关文章

星融元数据技术有限公司是领先的开放网络解决方案提供商,产品包括网络操作系统、数据中心交换机、AI智算交换机、园区交换机、开放式企业级路由和新一代网络可视化产品等。为行业企业、数据中心和云运营商提供基于通用解耦硬件和 SONiC 软件框架的全场景交钥匙网络解决方案,帮助用户构建AI时代中立、透明,易于运维、高性价比的基础网络。

🔺关注 @星融元Asterfusion 微信公众号
WeChat QR Code

EasyRoCE 工具上新:基于INT的流量路径预览


关注星融元


目前智算中心场景中的网络成为了影响模型训练效率的关键制约因素。在 RDMA 网络里,微小丢包或拥塞即可导致系统整体通信性能的显著下降,而传统网络运维方式无法感知微秒级延迟变化。

由此,基于交换机的软硬件能力,星融元设计并实现了一款基于带内网络遥测(INT)技术的网络运维与监控工具 —— EasyRoCE – TPE,旨在为一线网络运维工程师提供决策优化的实用信息。

什么是 TPE?

EasyRoCE-TPE(流量路径预览,Traffic Path Explorer)的实现基础来自于星融元交换机具备的一种名为 IPT(Inband Path Telemetry)带内网络监控技术:

IPT技术通过复制特定业务流量的报文并携带流量经过的每一跳交换机的相关信息,从而获取端到端转发的统计信息。

INT

IPT相关技术原理参阅:一文读懂!INT技术之IPT如何实现端到端路径质量的精准监控

交换机启⽤IPT功能后,对于到达入口节点(Ingress Node)的每个特定流量原始数据包,交换机都会⽣成⼀个探测数据包,这个探测数据包是原始数据包的克隆(payload部分被截断),携带探针标记(probe marker)。

INT

  • 无侵入:不会影响既有业务,且整个TPE独立部署于单独的机器不会影响集群网络交换机;
  • 容器化部署:整个TPE以容器方式部署,不影响监控服务器的其他服务;
  • 可视化界面:用户全程在图形化界面操作,并且网络信息以图形化方式呈现;操作简单,直观查看交换机状态。

TPE 由两部分组成:IPT 控制页面和 IPT 可视化页面。

TPE 控制页面

TPE提供了一个可视化界面来配置IPT的规则,用户完成交换机的规则配置后,打开IPT开关即可通过SSH完成相关配置的下发工作。

TPE 可视化界面

完成交换机的配置后,可视化界面将基于之前配置的规则生成拓扑,并同时检测服务器的网络接口。

当使能了 IPT 功能的交换机发送 IPT 报文给 TPE 时,TPE会解析并在可视化界面进行展示,此时在拓扑上可呈现每个交换机节点的最新的状态信息。

部署与使用

最新版本的TPE工具请联系项目销售/售前人员获取;部署TPE工具的服务器必须接入管理网络和交换机的INT网络中。

编辑AID,添加交换机的INT信息

EasyRoCE-AID

我们需要在EasyRoCE-AID(基础设施蓝图规划)工具里按照真实的网络拓扑规划添加交换机信息,以便 TPE 能够在运行时自动获取到正确的设备信息。

  • 设备名称:交换机的hostname,全局唯一
  • 网络类型:按现网真实拓扑来划分交换机类型,分计算网络、存储网以及管理网
  • 设备角色:Spine、Leaf类型,按设备真实角色填写即可
  • 设备型号:设备的真实类型,须如实填写以确保工具解析正确
  • 管理地址:用于配置下发

在服务器上安装 TPE 工具

#上传TPE的容器镜像到服务器中
scp tpe-v1.0.1.tgz root@10.240.3.5:/tmp/

# 导入镜像
docker load -i tpe-v1.0.1.tgz

# 运行容器
docker run -d --name=tpe --network host --privileged -v /tmp/tpe/data:/app/data tpe:v1.0.1

现在可以通过Grafana面板URL:http://10.240.3.5:3000/d/xxxxxx (示例) 来访问操作TPE。

访问和操作 TPE 工具

EasyRoCE

以上 TPE 配置页所呈现的效果,便于演示,此处我们已预先添加了一些交换机的 IPT 规则,实际使用时用户可在配置界面自行添加所需规则。

手动配置IPT规则

手动添加IPT规则需要遵循如下要求:

  • 一条完整的业务路线需要按照实际拓扑添加入节点、传输节点以及出节点;
  • 入节点需要添加业务进入的设备端口,出节点需要添加业务进入的端口以及INT地址;
  • 所有设备的Switch ID唯一且同一链路的Probe Marker必须保持相同。

配置交换机角色:Ingress/Egress/Transit

主要配置项:

  • Switch ID:纯数字,全局唯一,与AID一致
  • Ports:交换机仅对已配置接口的报文进行监控采样
  • Probe Marker:为64位配置值,同一链路的ProbeM arker必须保持相同,最⾼2字节必须为0
  • Trigger Mode: 分为 Sampling Mode (全量报文概率采样)和按照 DSCP 过滤采样两种
  • Source IP:对于Egress角色,需填写交换机Source IP(INT接口地址),该IP作为源IP地址用于IPT报文最外层IPT头封装,目的IP为TPE所在服务器IP。egress 节点会按照三层路由将 IPT 报文发送给 TPE 服务器用于最终的解析呈现

完成每个节点的配置,打开行末的开关即可完成配置下发工作。

查看 TPE 可视化界面

完成配置后点击可视化按钮 Visual Interface 即可跳转报文解析页面。

EasyRoCE

此时可以看到根据之前配置的信息生成的一条IPT路径。

点击图上设备或者线路则能显示最新的IPT报文所展示的交换机的状态信息,下方则是 TPE 所解析的最新的 IPT 报文详情。

EasyRoCE

一文读懂!INT技术之IPT如何实现端到端路径质量的精准监控

赋能大模型训练:基于 IPT 技术的超大规模 GPU 集群时延与队列监控

INT技术之IPT的精准监控的封面图

随着AI大模型训练、分布式计算等高性能应用的快速发展,智算网络对端到端路径质量的监控需求日益提升。近年来 INT(In-band Network Telemetry,带内网络遥测)作为新一代网络质量分析技术,也已从前瞻性学术研究领域走向了真实网络环境下的应用。

星融元现有方案中应用到的 INT 技术包含 BDC、HDC 以及 IPT 。其中 BDC 和 HDC 相关技术和工具应用我们之前已有专题文章介绍,? 请参阅:基于INT的网络拥塞监控和告警工具

INT 技术对比

方案 BDC HDC IPT
触发条件 队列缓冲区超限丢包 队列转发时延达到设定阈值
遥测信息 队列占用情况 转发时延 队列深度及转发时延
采样机制 概率捕获、微突发捕获 概率捕获、微突发捕获 概率捕获
聚焦场景 缓冲区丢包捕获与报告 无损网络的高延迟异常诊断 大型网络中的问题定位,全路径质量监控

什么是IPT?

IPT,全称 In-band Path Telemetry,带内路径遥测。

通过前文的对比表格可以看到,作为 INT 技术的标准方案之一,IPT 侧重于实现端到端路径质量的精准监控。

IPT 报文由多层头部构成,包含外层L2/L3封装、GRE头部、IPT Shim头部、探针标记(Probe Marker),IPT Base Header,及各节点统计信息(IPT Hop Information)等字段。

IPT报文构成

在遥测域的每个交换节点之间(包括入口和出口节点),每跳统计信息都会被插入到IPT 探测数据包中,以下是记录统计信息的报文格式和字段描述。

IPT Hop Information

  • Switch ID 节点设备
  • Dev Class 识别设备芯片的唯一编码,用于解码数据包中的信息。
  • Queue Size Info 报文转发时队列实时占用大小队列占用大小
  • Dinfo 2IPT 数据包从该跳节点转发出去的出口队列信息。
  • Dinfo 1IPT 数据包从该跳节点转发出去的出接口信息
  • Egress Timestamp InfoIPT 数据包从该跳节点转发出去的时间戳信息
  • SinfoIPT 数据包进入该跳节点的入接口信息
  • Ingress Timestamp InfoIPT 数据包进入该跳节点的时间戳信息

IPT 的工作原理

IPT工作流程图

IPT 通过在遥测域内配置入口节点、出口节点及传输节点,利用探针标记(Probe Marker)唯一标识遥测域,沿原始路径生成探测数据包并收集各节点统计信息,最终封装至收集器,为网络运维提供整网路径质量的多维分析能力。

我们可以将其工作流程简要拆解如下:

入口节点(Ingress Node)

这是 IPT 技术的核心环节,重点在于流量采样、复制与探测包构造。

  1. 识别与采样:通过采样或者配置DSCP来指定队列的方式识别目标流量,而非对所有流量进行复制。
  2. 复制与截断:克隆原始业务报文,保留报文的二三层首部(Header),并截断原始负载(Payload),以降低遥测流量对带宽的占用。
  3. 探测包封装:在 UDP 或 TCP 首部的 前 16 字节之后 插入 IPT 专有字段。
  4. 插入标记与头信息:包含 探针标记(Probe Marker) 用于后续节点识别、IPT Base Header(标识版本和跳数等)以及该入口节点的统计信息。
  5. 同路径转发:探测包被赋予与原始报文相同的转发特征,确保它在网络中走过完全一致的路径。

传输节点 (Transit Node)

中间节点不再需要处理庞大的业务流量,只需专注处理探测包,对其进行识别、追加与透传。

  1. 精准识别:节点通过识别报文特定偏移位置的 Probe Marker,迅速判定该报文为 IPT 探测包。
  2. 元数据追加:在不改变报文原有结构的基础上,将本节点的路径统计信息(如设备 ID、入/出接口、实时时延等)追加到 IPT 数据段中。
  3. 硬件透传:利用硬件转发面的能力,确保探测包的累加处理不会引入额外的计算开销,从而保证时延数据的真实性。

出口节点 (Egress Node)

当探测包到达 IPT 域的出口节点,将会执行最终节点的数据收集与路径遥测数据的封装转发。

信息补全:写入最后一个节点的元数据,形成完整的端到端路径视图。

探测包终结和封装:出节点不再转发该探测包,而是将其从业务转发路径中“摘除”将收集到的全路径元数据封装并发送给采集器(Collector)。

由于探测包已经包含了原始报文的首部信息,分析平台可以轻松地将遥测数据与对应的业务流关联起来。

方案优势

与直接修改业务报文的“染色”方式相比,基于采样和生成独立的探测报文的遥测方式,实现遥测流量与业务流量的分离,同时又能真实模拟业务报文在网络中的转发行为。

  • 业务零干扰:由于修改的是复制出的探测包,即便遥测逻辑出现异常,也不会影响原始业务数据的完整传输。
  • 低带宽压力:通过截断 Payload,极大减小了探测包的体积,适合大规模部署。
  • 部署灵活性:在不支持 IPT 的设备上,探测包可以作为普通报文透传,而在支持的节点上则进行数据采集,具备更好的兼容性。

典型应用场景

在某超千卡GPU集群的大模型训练场景中,集群依赖高性能网络实现节点间数据同步(如All Reduce操作),路径质量直接影响训练效率。IPT技术可在以下环节优化路径性能:

端到端路径时延监控

如下图所示,训练过程中,梯度数据需经多台Leaf/Spine交换机转发。IPT通过探测数据包采集各节点转发时延,结合入口到出口的总时延,定位高延迟节点(如某Spine交换机转发时延异常升高),辅助调整流量转发路径,避免因单节点延迟导致整体训练效率下降。

IPT技术辅助定位高延迟节点

队列状态动态感知

如图所示,当多台GPU服务器通过同一交换机端口发送数据时,出方向队列可能因流量激增出现拥塞。IPT探测数据包携带队列占用大小、QP(Queue Pair)等信息,运维人员可快速识别拥塞队列,调整缓冲区分配策略(如增加突发流量处理容量),保障数据同步稳定性。

IPT技术辅助快速识别拥塞队列

可视化呈现

基于IPT技术的EasyRoCE小工具即将发布,敬请期待。

基于IPT技术的小工具界面截图


产品型号:星融元(Asterfusion)CX864E-N (64 x 800G OSFP)
功能特性:RoCEv2, PFC, ECN, DCBX ……
应用场景:GPU算力集群,分布式存储
最后更新:2026-04-17


相关文章

星融元数据技术有限公司是领先的开放网络解决方案提供商,产品包括网络操作系统、数据中心交换机、AI智算交换机、园区交换机、开放式企业级路由和新一代网络可视化产品等。为行业企业、数据中心和云运营商提供基于通用解耦硬件和 SONiC 软件框架的全场景交钥匙网络解决方案,帮助用户构建AI时代中立、透明,易于运维、高性价比的基础网络。

?关注 @星融元Asterfusion 微信公众号
WeChat QR Code

深度解析AsterNOS基于Geo-Engine的流量识别与调度


关注星融元


随着网络带宽向 100G 演进及云服务的普及,企业网络边缘正面临新挑战:传统的基于 IP 五元组(源 IP、目的 IP、端口、协议)的路由策略在处理各类企业 SaaS 应用和 CDN 内容时显得力不从心,具体来说网络工程师经常面临以下痛点:

  • IP 动态化: 服务器 IP 频繁变化,静态 IP 列表维护极其困难。
  • IP 复用: 单个 CDN IP 可能承载多个不同服务,仅靠 IP 无法实现精确识别。
  • 性能瓶颈: 在高吞吐环境下,复杂的匹配规则会导致严重的转发性能下降。

应对以上挑战,AsterNOS-VPP(什么是AsterNOS-VPP?) 通过 GeoSite/GeoIP 技术提供了一个快捷准确的流量调度方案:摒弃臃肿的 DPI 插件,通过仅解析报文头实现了线速转发,并完美适配 TLS 1.3 时代的加密环境,将流量控制权交还给网络工程师。

AsterNOS Geo-Engine 工作逻辑

AsterNOS 将网络策略的重心从传统的“地址”转向了身份(Identity)与来源(Origin),其工作流遵循简洁的“三步法”:

GeoEngine

1、识别 利用 Geo-Engine 实时分类流量,无需手动维护 IP 列表

  • GeoIP: 按区域(如 CN, US)识别
  • GeoSite: 按应用(如 YouTube, 游戏,办公应用)识别

2、定义: 关联标准功能模块确定处理动作,如策略路由(PBR)、安全策略(ACL的允许或拒绝)或带宽限速(QoS策略)

3、执行: 将策略绑定至物理或逻辑接口

为什么不使用传统 DPI?

AsterNOS 选择了 GeoSite 路径而非传统的 L7 DPI(深层数据包检测),主要基于以下技术维度的考量:

维度传统DPIAsterNOS-VPP
检测深度L7 载荷L4-L7 报文头/握手信息
性能影响高,需要流重组和正则匹配,CPU 负担重极小,仅解析报文头部特征,维持线速转发性能
加密流量差,面对 TLS 1.3 的全加密载荷,DPI 基本失效优,基于 SNI 和 DNS 关联,原生兼容加密流量
规则透明黑盒,用户不可见且不可修改,依赖厂商维护白盒,兼容开源 .dat 格式,完全自定义且可从 GitHub 社区自行获取更新

技术实现:基于 VPP 的多协议域名提取机制

为了在数据面线速识别流量,AsterNOS 开发了 geosite_plugin.so 插件,将其作为 geosite_input_node 集成在 VPP 节点中。

域名提取

与深层数据包检测(DPI)不同,该技术专注于不同协议的报文头特征字段的提取:

  • HTTPS/TLS: 在 TLS 握手阶段解析 Client Hello 包,提取SNI(Server Name Indication) 字段

GeoEngine

  • HTTP/1.1: 解析请求头中的Host字段

GeoEngine

  • DNS: 当设备作为 DNS 代理或网关时,直接从 Query Name 字段提取域名

GeoEngine

  • SOCKS5: 提取 ATYP 为域名类型时的 DST.ADDR

GeoEngine

匹配算法和数据结构

提取域名和IP地址特征后,系统需将其与规则数据库(.dat文件)进行比对,借助高效的数据结构确保线速的转发性能。

  • IP 匹配: 通过 PATRICIA Trie 管理IP掩码规则,支持最长前缀匹配(LPM)。即使单个IP匹配多条规则(如同时属于Google和US),系统仍能根据优先级返回准确结果。

Patricia Trie(帕特里夏树)是一种专门处理字符串匹配的高效索引结构。它通过合并只有单一子节点的路径来“压缩”空间,像一棵去掉了冗余分叉的树。在网络路由中,它能以极速实现最长前缀匹配,即从成千上万条路由规则中瞬间锁定最精确的那一条 。

  • 域名后缀匹配: 支持根域名匹配,通过 Trie 树结构加速检索

业务流处理

数据包进入VPP的 ip4/6 输入节点后的处理流程如下:

  1. 域名提取:数据包进入geosite_input节点,根据协议类型提取域名。
  2. 会话查询:系统查询现有会话表。若存在匹配结果则直接复用,减少重复解析开销。
  3. 规则匹配:
  • 域名特征匹配:对于携带域名信息的数据包(如TLS客户端初始化、HTTP主机字段、DNS查询),系统优先提取域名特征并与GeoSite规则库进行匹配,这是最精确的识别方式。
  • IP匹配:对于域名未匹配任何规则的数据包,系统利用DNS解析结果匹配配置的GeoIP规则。
  • 对于无法提取域名数据包,系统直接使用IP地址进行匹配。

执行动作

根据匹配结果,系统执行相应动作,例如允许、拒绝或配置策略路由的下一跳。

典型应用场景

1.应用感知路由(PBR)

背景: 企业拥有高速但昂贵的企业专线和较为廉价的 ISP 线路,传统方案下需手动收集海量 IP 段,让重要的办公业务应用如 ZOOM,Office 365 走企业专线确保网络性能,其他一般占用大带宽的非关键应用走 ISP 普通线路。但是,一旦应用更新了 IP,策略便会马上失效

AsterNOS方案: 编写基于域名的策略路由,无论应用如何改变 IP,只要 SNI(服务器名称指示) 匹配 geosite:zoom,流量自动导向企业专线

伪代码示例:

pbr-map SMART_ROUTING
match geosite ZOOM set nexthop <Premium_Gateway_IP>
match geosite MICROSOFT set nexthop <Premium_Gateway_IP>

2.安全合规与地理围栏

  • 背景: 企业禁止特定国家 IP 访问内部服务器,或限制员工办公时间访问社交媒体;传统方案是在防火墙产品内订阅 GeoIP 数据库(可能存在高昂的订阅费用)或者手动添加基于IP的策略规则,以上都会影响防火墙的性能
  • AsterNOS方案: 利用 GeoIP 和 GeoSite 的分类能力,在 VPP 转发面直接阻断违规流量,不消耗下游处理资源
  • 伪代码示例:

access-list SECURE_ACL
# Deny all media websites (based on domain classification)
rule 10 deny geosite CATEGORY-MEDIA
# Block US IPs (based on geo-location)
rule 20 deny geoip US

3.精准的应用 QoS 流量整形

  • 背景: 办公工具应用(如 ZOOM 会议)与带宽大户(Youtube)共享同一加密通道(HTTPS/443),传统基于端口的 QoS 无法区分
  • AsterNOS方案: 利用有状态的应用感知 QoS。在初始握手阶段识别特定应用,并创建动态会话仅对目标流进行限速
  • 伪代码示例:

# Define the throttle policy
traffic behavior LIMIT_STREAMING
car sr-tcm cir 100 cbs 6400

# Create Stateful ACL
access-list REFLECT_L3 APP_QOS_POLICY
rule 10 geosite YOUTUBE traffic-behavior LIMIT_STREAMING

硬件平台支持

AsterNOS-VPP 目前主要支持运行在星融元ET系列智能业务处理平台之上。

产品图

ET2500开放智能业务处理平台

  • 设备尺寸:220 x 310 x 44 mm
  • 业务接口:4 x 10GE (SFP+), 4 x 2.5GE (RJ45), 8 x 1GE (RJ45);其中4个 2.5G 和 1G 接口可选 POE++供电,总功率预算为 150W
  • 风扇模块 x2 ,电源模块 x1
  • 满负载功耗 60w,不含 PoE
  • 扩展支持 5G/LTE、WiFi-6E/7、BlueTooth 5.3、GNSS、TPM等

ET3600 系列开放智能业务处理平台

  • 设备尺寸:440 x 470 x 44 mm
  • 业务接口:2或4 x 10GE (SFP+), 2或4 x 100GE (QSFP28)
  • 风扇模块3+1 ,电源模块1+1,2个M.2插槽, 可选PTP模块
  • 满负载功耗100w或200w

EasyRoCE 新年上新!基于INT的网络拥塞监控和告警工具


关注星融元


前言:基于 INT 技术,星融元开发了 EasyRoCE-CMA( Congestion Monitoring & Alert,拥塞监控与告警) 工具实现纳秒级的采集精度,一站式呈现交换机端口队列级的拥塞丢包异常状态,辅助网络快速调优

INT 带来的革新

在网络监控演进中,Pull与Push是两种传统的基础范式。

Pull 模式由监控服务器主动向被管设备发起数据采集,例如通过 SNMPGet或 ICMPPing 定期轮询设备状态。该方式便于集中控制,适合指标趋势分析,但实时性依赖轮询间隔,且高频率采集会增加服务器与网络负担。

Push 模式则由被管设备主动将数据发送至监控服务器,例如设备通过 SNMP Trap 或 Syslog 主动上报故障事件,其优势在于实时性较强,但信息孤立。

带内网络遥测(In-band Network Telemetry)区别于传统网络监控运维的最大差异,是从“外部观测”到“数据自述”的革命性转变——不只是基于事件的 Push,而且还让网络数据包自身成为探针,在转发路径中“自行记录”网络状态,同时做到最高纳秒级的实时性与路径级的可视化,完美捕捉网络中偶发的、微突发(Micro-burst)的问题。

CMA

INT 技术的实现由交换机底层硬件支持,在数据平面芯片内部进行采集,通过在业务数据包内嵌入指令,使交换机在转发时动态插入本地的精准遥测数据(如设备ID、队列时延、拥塞状态等),最终由接收端(如服务器或其他网络边缘设备)解析并上报这些信息。

基于 INT 的 HDC 和 BDC 信息

服务于AI智算等大规模复杂流量环境的 EasyRoCE- CMA工具主要借助了星融元交换机基于 INT 特性生成的 High Delay Capture(高延迟捕获) Buffer Drop Capture(缓冲区丢包捕获) 信息。

Buffer Drop Capture(缓冲区丢包捕获)

BDC 专注于捕获和分析与交换机 Buffer 相关的问题。

CMA

当数据包因缓冲区容量限制被丢弃时,交换设备会为该丢弃数据包添加元数据,并将原始数据包前150字节,连同元数据打包作为 BDC 数据包发送至远端收集器或者本地交换设备CPU——通过收集BDC报文中包含的报文节点ID、队列缓冲区大小和QP(Queue Pair)队列等信息,我们可以识别出潜在的缓冲区溢出和数据丢失情况,由此网络工程师可快速采取措施优化缓冲区配置,提高通信性能。

High Delay Capture(高延迟捕获)

HDC 则专注于捕获和分析网络中的高延迟问题。

CMA

交换机设备会捕获所有超过用户设定阈值的延迟数据包,并将原始数据包的前 150 字节连同元数据打包成 HDC数据包发送至远端收集器或者本地交换设备CPU,同时原始数据包仍保持正常传输——通过监测 HDC 报文中的节点ID、累计时延和丢包数量等关键字段,帮助工程师识别出网络延迟的根本原因,辅助系统优化或排障。

EasyRoCE-CMA 工具介绍

EasyRoCE-CMA( Congestion Monitoring & Alert,拥塞监控与告警) 运行在安装有 EasyRoCE Toolkit 相关组件的服务器上,该服务器连接到所有被监控交换机的 INT 接口(星融元交换机大多拥有额外的两个10G口用于传输此类网络遥测数据,不影响生产网络)。

CMA

CMA工具主要分为控制面与业务监控面两部分。

启用工具时,CMA控制面会先从EasyRoCE-AID工具读取到交换机的基础信息,此后用户可在相应界面图形化地设置交换机 HDC/BDC功能的启停状态;

业务监控面则负责解析收到的 HDC 和 BDC报文,并将各交换机的流量运行状况和异常流量的详细报文信息导出到后端监控平台,做可视化呈现,比如 EasyRoCE-UG;除此之外,CMA 所采集到的信息也可以用于 EasyRoCE- RPA 工具的参数优化。

CMA 主要界面示例

CMA 本次发布的1.0版本主要包含以下几个功能界面。

CMA 首页

CMA 首页可以通览所有交换机的网络拥塞和丢包状态,默认情况下,CMA在5分钟内收到某个交换机的HDC/BDC报文,监控状态一栏相应状态会显示变红。

CMA

CMA 配置

首页点击交换机名称进入该设备的配置面板,进入该页面时,CMA会实时从交换机同步 INT 配置的开关和具体参数情况,如需修改编辑参数先要关闭 CMA 开关。

CMA

CMA 监控 – 全局监控

CMA 首页点击全局监控按钮后可在一个页面上查看被监控的所有交换机发出最近1000条 HDC 和 BDC 报文信息,其中包含报文相关的上下行设备和该报文所关联的业务报文详情。

CMA

CMA 监控 – 设备详情

CMA 首页点击设备所在行会展示指定设备上所有接口,以及接口上所有8个队列的拥塞/丢包状态,此表下方附有该交换机发出的所有 BDC/HDC 报文详情。

CMA

相关阅读:

EasyRoCE:AI基础设施蓝图规划 AI Infrastructure Descriptor (AID)
INT-based Routing:AI时代的智能路由

AsterNOS SONiC 现已支持基于YANG的网络管理新范式


关注星融元


截至2025年底,运行最新版本AsterNOS的星融元交换机已支持新一代的基于 YANG 数据模型的运维管理接口,包括 NETCONF,RESTCONF(REST API)和 gNMI,覆盖数据中心、园区和边缘智能网关/路由等场景。

快速回顾: CLI 和 SNMP

CLI(命令行接口) 是一种基于文本的交互界面,用户通过键盘输入文字指令,由命令解析器完成解析之后向被管理设备下发指令。

CLI 作为最广泛最基础的管理手段用来管理小规模简单网络基本够用,一旦组网规模扩大,业务复杂化,其管理效率的下降显而易见。

SNMP(简单网络管理协议) 开发于上世纪 80 年代末,是第一个被广泛部署的互联网网络管理标准。

SNMP 基于服务器/客户端架构,被管理网络设备作为 SNMP Agent,向网管系统(NMS)提供各种信息,NMS 则通过 SNMP 协议向设备进行查询和配置,两者的交互过程主要是 NMS 和 Agent 一问一答的 Pull 模式,也可以由 Agent 主动上报信息(比如告警)。

尽管 SNMP 最初是为网络设备配置而设计的,但由于其缺乏更复杂的网络配置任务所需的灵活性和可靠性,目前主要用于采集呈现监控指标——通过整合不同设备厂家的管理信息库(MIB, Management Information Base),从中拿到所需指标的 OID 值由NMS完成对多厂商设备的统一集中监控。

SNMP-MIB

MIB 是一个树型结构的数据库,定义网络设备中可管理资源,包括变量名称、数据类型、访问权限等,通过对象标识符 OID(object identifier)确定与被管理对象的对应关系;每个支持 SNMP 管理的设备都有自己的 MIB。

可以看到 SNMP 在定义监控参数方面的确有效,但也存在诸多缺陷,例如 SNMP 仅支持分钟级的监控精度,无法反映微突发流量,以及大规模监控需求下的 Server 资源占用问题等等。

什么是 YANG (数据建模语言)?

无论是CLI还是SNMP,在应对现代网络复杂、动态的需求时,逐渐显现出其在效率、精确性和一致性方面的局限性,这种局限性的本质在于它们是面向被管理对象单独配置的,而不是面向业务。

为了解决以上问题并应对现代网络环境中日益增长的配置管理需求,IETF 提出了 YANG(Yet Another Next Generation)作为描述网络配置数据的建模语言,正如其名,YANG 定义了一种适用于新一代网络管理的数据结构,其上是新一代的网管协议如NETCONF、RESTCONF、gRPC 等等。

相较于SNMP 使用的 MIB,YANG 模型更有层次,可扩展性更强。

MIB 使用平铺的表结构,难以区分配置和状态数据,用唯一的OID(如 1.3.6.1.2.1.4.3)来访问对象,而 YANG 模型支持用更灵活丰富的数据结构去描述设备的配置(configuration)和运行状态(state)信息,甚至是操作。

有了结构良好的 YANG 建模语言,网络运维工程师依照设备厂商所支持的 YANG 模型文件(厂商私有或开放标准,用于具体定义设备状态/配置数据的层次化结构)编写YANG 数据实例,并将其用 XML 或 JSON 编码后下发到设备用以执行各类配置管理操作。

发送方式可以是基于 SSH 的 NETCONF,也可以是基于 HTTP 的 RESTCONF(RESTful API),或是基于HTTP/2的 gRPC。

YANG

设备的配置管理

设备供应商使用原生的 YANG 模型或 IETF/OpenConfig 提供的标准 YANG 模型来描述其所有配置层次结构和所有支持的功能。网络工程师若需对设备进行配置,仅需要拿到对应设备的YANG文件并按照它的定义向设备下发即可。

以下是使用 NETCONF 在星融元园区交换机的eth1上创建静态ARP的示例。

<config><top>
  <interfaces>
    <interface>
      <name>Ethernet1</name>
      <ipv4>
        <address operation=“create”>
          <ip-prefix>20.1.1.1/20</ip-prefix>
        </address>
        <address operation=“create”>
          <ip-prefix>30.1.1.1/20</ip-prefix>
        </address>
        <neighbor operation=“create”>
          <ip>20.1.1.2</ip>
          <mac-address>00:0e:c6:56:9d:35</mac-address>
        </neighbor>
        <neighbor operation=“create”>
          <ip>30.1.1.2</ip>
          <mac-address>00:0e:c6:56:9d:35</mac-address>
        </neighbor>
      </ipv4>
    </interface>
  </interfaces>
</top></config>

设备的运行状态

设备供应商使用 YANG 模型描述设备上当前运行的各种接口和协议的所有运行状态,这些信息可以通过以下两种方式获取。

  • 使用 NETCONF 的 GET RPC (远程过程调用)和或供应商支持的其他管理接口的 RPC,与 SNMP 非常相似
  • 使用网络遥测技术(Telemetry)来定义需要监控的字段,并将遥测信息发送到指定的收集器,采集精度可达纳秒级

可见, YANG 数据模型适用于各种现代化的网络管理场景,包括但不限于:

  • 网络配置管理:自动配置和同步网络配置,减少人为错误,提高运营效率
  • 网络状态监控:利用 YANG 模型对网络状态进行实时监控和验证,从而实现主动管理和故障排除
  • 网络服务编排:支持 NFV 和 SDN 架构中的复杂服务定义和编排,从而实现动态的、按需的网络服务

基于 YANG 模型的几种主流管理协议

YAND Data Model

NETCONF

NETCONF 定义了基于 YANG 的现代网络管理范式,管理应用通过安全可靠的连接,使用基于XML的数据编码对网络设备进行精准的配置操控与数据获取,有明确的连接建立、会话和关闭过程,适用于电信级网络、核心路由器/交换机等对配置可靠性和精确性要求极高的组网环境。

以下是一个典型的数据中心带外管理网拓扑:

topo

在带外管理网络内部部署一台管理服务器,使其能与所有交换机进行网络通信,即可对所有交换机进行集中管理,例如配置变更和状态检查。

NETCONF 和 YANG 提供了相对统一的操作接口来管理跨厂商的设备,同时具备强大的配置事务机制,配置失败时可以自动回滚。尽管不同厂商的设备支持的YANG模型可能不同,但管理应用可以建立在相同的底座上对所有设备执行相同的操作(如<edit-config>)。当具体的操作数据不同,可能需要网络管理员针对不同厂商设备编写不同的配置数据模板,而配置数据的语法又是相同的。

RESTCONF

RESTCONF 是 NETCONF 面向 RESTful API 的“简化版”,2017年融合了 NETCONF 和 HTTP 协议的 RESTCONF 悄然诞生,为用户提供高效开发 Web 化运维工具的能力,提供的编程接口符合IT业界流行RESTful风格,与现代云原生应用和 DevOps 工具链(如 Ansible, Python脚本)集成度极高,学习成本低。

与 NETCONF相比,RESTCONF 提供基本的 CRUD 操作,使用标准的 HTTP 方法(GET, POST, PUT, PATCH, DELETE),通常不用来实现复杂的事务配置。

OPENCONFIG/gRPC

gRPC(google Remote Procedure Calls)是Google于2015年发布的高性能通用RPC开源软件框架,基于HTTP/2协议实现,支持以Protocol Buffers格式定义接口,并以二进制编码传输数据,此外还具备跨平台等特性。通信双方都基于该框架进行二次开发,gRPC承担了传输、安全、编码等工作,使得开发者可以专注于应用层的接口定义和实现。

gNMI(gRPC Network Management Interface)是基于gRPC定义的一套用于管理目标设备的开源接口协议,gNMI 由谷歌发起,并得到 OpenConfig 社区大力推动,是未来发展方向,尤其在需要实时可视性和自动闭环控制的云原生网络中优势明显。

gNMI定义了以下四种服务:

  • Capabilities:获取目标设备的能力。
  • Get:获取目标设备当前的状态和配置数据。
  • Set:向目标设备下发/修改配置。
  • Subscribe:订阅/高速采集目标设备的数据。

在常规的状态查询和配置修改方面,gNMI 和 NETCONF 的能力相差无几;但对于大型数据中心、云网络、5G 核心网等需要海量、实时监控数据和高频配置的场景,gNMI 性能卓越,通过单一协议解决了配置与监控需求,并且原生支持流式遥测,推送模式效率远高于轮询,是云原生/可编程网络的首选。

以下是一个典型的数据中心云网场景组网拓扑,使用遥测方式对网络进行监控:

topo

通过连接星融元数据中心网络交换机提供的额外 10G 接口并辅以隔离性配置,监控服务器可在不干扰业务流量的情况下对所有设备发起gNMI订阅请求,持续高频获取网络设备的各类信息,只要是设备支持的YANG模型有建模的数据均可。

gNMI 可采集的数据十分丰富,可用于监控设备状态、监控流量计数,配合 Prometheus 和 Grafana 等可视化工具,以上时序数据可被转化为直观的统计图表,并进一步实现系统异常告警、流量分析等功能。

星融元目前的支持情况

截至2025年底,运行最新版本AsterNOS的星融元交换机,包含数据中心、园区和边缘智能网关/路由产品系列,已支持新一代的基于 YANG 数据模型的运维管理接口,其中包括 NETCONF,RESTCONF(RESTful API)和 gNMI ,提供设备配置(如路由协议配置)、系统状态(如CPU负载、内存使用量、主板温度、风扇转速)以及端口转发计数、ACL命中计数、关键资源使用量在内的丰富统计信息。

AsterNOS

即插即用零配置,数据中心带外管理网的快速上线方案


关注星融元


数据中心的带外管理网是一个独立于业务网络的专用管理通道,是数据中心运维体系中关键的容错和保障机制,其核心作用是在主业务网络发生故障、设备宕机或系统无法远程登录时,为管理员提供一条“备用通道”,从而实现对设备的持续访问和控制,保障业务的连续性。

数据中心管理网的传统配置方式

通常我们会使用千兆电口交换机去连接区域内所有不同类型服务器和网络交换机的带外管理口,并为其划分出独立的IP地址段,与业务网络地址段严格区分,以避免路由混淆。

典型配置工作如下:

  • 登录所有服务器设备,按照规划给服务器带外口/网络设备管理口配置静态的管理IP地址,掩码和网关信息
  • 在交换机上根据设备类型或管理权限划分不同的VLAN(如服务器管理VLAN、网络设备管理VLAN),以实现逻辑隔离和权限细分

而如今,上述的配置工作也可以免去了。

管理网

图1:管理网零配置上线方案概要

在星融元的交付实践中,我们依托SONiC交换机的开放特性,通过在交换机内部运行DHCP server 和 TFTP server,已轻松实现了带外管理网的“即插即用”零配置开局配置,无需额外的管理节点。

✦ 交换机自动上线并分配到不同 VLAN 用于标识和区分

✦ 终端主机根据DHCP请求包 option 携带的主机位置自动获取到预先规划的IP地址,完成上线(比如按照设备物理安装和连接位置按序分配,后续管理时可轻松定位)

✦ 双活DHCP服务器,高可靠设计保障业务

数据中心管理网的零配置上线方案

本例所用到的设备为:

CX-M

  • 星融元 CX202P-24Y-M,2x100GE + 24x25GE QSFP28,作为管理网的Spine /核心交换机,运行TFTP server 和 DHCP server,支持 DHCP option82/66/67

园区交换机

  • 星融元 CX206Y-48GT-M,6x10GE+48x1GE RJ45,作为管理网的 Leaf/接入交换机,下连各类被管理设备;

以上交换机均搭载基于SONiC的 AsterNOS 网络操作系统,容器化架构,支持完备的数据中心/云化园区网络特性。

AsterNOS

被管理交换机设备的零配置上线

topo

  1. 被管理交换机通过发起DHCP请求获取IP地址、配置文件所在的TFTP服务器地址和开局文件名称
  2. 被管理交换机根据 DHCP 服务器给出的地址与TFTP Server 建立联系,获取开局文件(Smart_config.ini)并解析,开局文件中包含与此设备MAC匹配的唯一配置文件名称(MACn.cfg)
  3. 被管理交换机根据解析出的配置文件名称再次向TFTP Server 获取对应的配置文件并应用

配置文件为每台交换机分配了 VLAN,并配置好 DHCP Relay使其下接入的终端也能顺利通过 DHCP 过程获取到 IP 地址。

终端主机/服务器的零配置上线

终端主机/服务器零配置上线

  1. 主机通过DHCP请求获取IP地址
  2. 主机所连接的被管理交换机分别在 DHCP discover 报文 Option 82 字段中加入自身MAC地址和连接终端的端口号、VLAN号,用来标识该主机位置
  3. Spine 交换机上DHCP Server 根据 Option82 字段中的信息,匹配到唯一的IP地址并回复给接入主机
  4. 主机按照规划获得到与位置对应的 IP 地址

DHCP server 的高可靠设计

DHCP Server

上述方案中,管理交换机和上行链路之外,DHCP server 也支持双活部署以提升业务可靠性:两台Spine交换机上都分别运行了DHCP服务器,并进行地址分配等相关信息的同步,当其中一台服务器出现故障,另一台服务器将继续从地址池中续订租约

正常情况下:两台DHCP服务器均收到DHCP请求,并向客户端发送IP地址,客户端挑选一条回复,收到回复的服务器并向对端设备同步地址信息,客户端到达任一个服务器均可以续租。

若某台DHCP服务器出现故障:客户端获取地址时由当前存活的DHCP服务器响应请求,根据客户端信息和地址池状态分配地址,交互完成后,本地更新租约信息,客户端的续租请求仅向存活服务器发起。

科技型企业办公区+自建云的混合组网和一站式融合管理


关注星融元


科创型企业是数字化时代的核心引擎,其发展势头与竞争力,取决于底层网络架构的稳定与高效。这类企业通常依托两大核心网络——承载关键业务的服务器区和支持高效接入的办公网(采用“混合组网”架构),以满足高性能与高可靠性的双重需求。

  • 服务器区Leaf通过MC-LAG技术与服务器相连,实现服务器双活接入;
  • 办公网与服务器区之间则通过全三层路由实现灵活可控的互访与高效的传输路径。

在网络规模持续扩张的背景下,“MC-LAG + 全三层”架构虽能提供高可用和灵活的路由能力,但其运维复杂度可想而知。传统网络控制器手工配置、分散管理和被动运维的模式,已成为制约企业业务敏捷发展与稳定安全的瓶颈。

ACC混合组网运维管理方案

面对科创型企业提出的“混合组网”需求,星融元基于TIP OpenWiFi框架构建的园区网络控制器(ACC)在规划拓扑环节新增了“混合组网”场景,显著简化了传统“MC-LAG + 全三层”架构的部署与运维流程。

化繁为简、快速开局

在已做好网络规划的前提下。

第1步,设备导入

根据模板规范填写设备信息并上传,完成后即可在库存信息界面查看已创建的设备。

第2步,规划拓扑

混合组网

ACC – 拓扑场景规划

选择“混合组网场景”模板。

按角色(Spine/Aggregation/Leaf)分配设备并填写互联接口,控制器会根据填写内容生成网络拓扑。

混合组网

ACC – 拓扑生成

Leaf1Leaf2作为分布式网关,Leaf1负责连接AP及无线终端,Leaf2负责连接有线终端。通过横向扩展汇聚层(Agg1Agg2)实现高可用与负载均衡,Spine与汇聚设备间均运行MC-LAG,以保障链路可靠性。

Server-Leaf1Server-Leaf2通过MC-LAG技术以纯二层模式连接服务器,网关集中部署在Spine设备上,简化服务器区网络管理并提升转发效率。

第3步,基础网络配置

ACC通过图形化界面,极大地简化了传统控制器上需要复杂命令行操作的MC-LAG(跨设备链路聚合)与全三层路由混合组网配置。

  • 业务区网络配置

这一步主要针对园区网络中的汇聚层设备,为其实现带内管理和MC-LAG功能奠定基础。如:管理地址段、PeerLink VLANPeerLink IP……

混合组网

ACC – 业务区网络配置

  • 服务器区网络配置

针对服务器区的Leaf设备,配置内容与业务区类似,为Leaf设备提供带内管理能力,并为其Peer-Link接口做好准备。

混合组网

ACC – 服务器区网络配置

  • 出口路由配置

确保整个园区网络能够通过Spine设备与外部网络进行通信。

第4步,业务配置

  • 有线业务配置

默认业务区的主要在Leaf1Leaf2设备上进行,为不同业务区域定义VLAN、网关、DHCP中继及PoE供电等参数。

ACC – 有线业务配置

为服务器区Leaf交换机创建链路聚合组及业务VLAN,在Spine设备上创建与Leaf设备对应的VLAN。

混合组网

  • 无线业务配置

管理员可以在此集中管理无线接入点(AP),配置SSID、安全策略、有线终端接入方式等,并利用标签系统实现配置的自动匹配与下发。

  • DHCP Server

Spine设备上配置DHCP Server,为整个园区网络中的终端设备(如AP、无线终端、有线终端)自动分配IP地址,是实现网络自动化管理的核心环节。

混合组网

ACC – 配置DHCP Server

第5步,配置下发

在完成所有网络与业务配置后,一键向交换机批量推送基础网络、有线业务及DHCP配置,而AP在上线后则根据预分配标签自动拉取对应配置,实现全自动化部署,彻底告别了传统的人工逐台配置模式。

混合后组网

运维效率提升ACC

ACC – Dashboard

ACC通过图形化界面,实现了网络状态的全面可视化,帮助运维人员直观地掌握整个网络的运行状况。

ACC

ACC – 主动告警

还能够实时监控设备的关键服务状态。一旦发现异常,会立即自动生成包含详细信息的告警,并根据告警的严重程度,精准地推送给相应的人员,从而实现高效、主动的运维管理。

同时,智能巡检功能支持对巡检项目进行精细化配置,确保运维工作的全面性和准确性。

创新性的云化设计理念

  • Spine-leaf架构

有线网络采用简洁、高可靠的 Spine/Leaf 架构运行全三层网络,天然无环路,隔绝广播风暴,同时支持按需横向扩展满足未来5-8年的扩容升级需求;下一代园区网络,用Leaf/Spine架构替代传统三层拓扑 下一代园区网络,用Leaf/Spine架构替代传统三层拓扑

  • 分布式网关

无线网络则借助分布式网关设计,提供超大漫游域的无缝漫游,实现跨楼栋漫游不中断,网随人动,策略随行,兼顾安全和便利性;园区网前沿实践:基于开放网络架构的云化路由设计 园区网前沿实践:基于开放网络架构的云化路由设计

  • 多元化认证方式

智能地自动识别接入网络的终端类型,并根据其属性和场景,自动匹配并执行最合适的认证方式,如802.1X或Portal认证,从而实现高效、安全且体验友好的网络准入控制。

NPB 2.0 面面观 | 基于 Ansible 自动化配置 NPB 策略


关注星融元


传统分流器 / TAP 一般是通过 Web 界面手动调整配置,而实际业务中成千条配置的周期性调整给一线运维人员造成了极大的负担。

举例来说,传统方式下假设我们要配置 10 台 NPB 专用设备,为其更新 VLAN 镜像规则与目标端口映射,我们需要依次登录这 10 台设备,打开 Web 界面进行手动添加/修改规则 1000+ 条,然后检查、保存,一通操作耗时动辄数小时,甚至一整天。

随着近些年的产品迭代,虽然部分 NPB 设备已经可以做到集群内的批量配置同步,但无论是在 Web 界面上如何优化,只要运维模式依旧是手工完成的拖拉点拽,还是免不了耗时耗力易出错。

关于星融元 NPB 2.0 ,请参阅:无需TAP/分流器,SONiC上跑容器,交换机秒变NPB

在 NPB2.0 中,我们已抛弃了过往使用专用设备的方案,而是在交换机上容器化运行 NPB 组件来实现相应功能。不光如此,我们也支持用 Ansible 去调用 sonic-cli 来批量配置新一代基于SONiC的 NPB 设备(包括园区和数据中心场景),实现快速、标准化、零差错的策略部署。

Ansible

什么是 Ansible?

Ansible是一款基于 Python 开发的开源自动化运维工具,由 Red Hat 公司主导维护,其诞生背景源于云计算时代下IT基础设施的规模化与动态化,传统手工运维方式难以应对频繁的配置变更和批量部署需求。

该工具的核心特点是基于agentless和声明式模型,借助 SSH 或 WinRM 协议直接管理节点,避免了客户端代理的安装和维护成本,其大致的交互模式为 用户通过YAML语言编写 Playbook定义目标状态,Ansible 自动将模块推送到远程节点执行配置。

ansible

由此我们可以建立标准化流程,将重复性运维操作转化为可版本控制的自动化任务,显著提升网络运维效率与可靠性。

目前 Ansible 已成为 DevOps 和云原生技术栈中的重要组件,帮助运维工程师跨平台配置统一管理各大基础设施,包括网络设备、云主机、容器集群等等。

如何使用 Ansible 自动化配置 NPB?

星融元的 Ansible 官方模块集合 Asterfusion AsterNOS Collection 已完成cliconf 插件和asternos_command 模块的开发适配,这些模块可在 Playbook 中直接调用,然后在 Ansible 的 inventory 文件中定义 SONiC 设备并为其设置正确的连接变量。

运维人员根据实际需求使用上述的 CLI 模块编写 Playbook 任务并运行,即可快速完成 NPB 策略下发、ACL 更新、端口配置等批量操作,几秒钟内即可将规则同步到所有 NPB 设备(SONiC 设备),并在 Git 中追踪变更历史。

示例步骤

1.在服务器上安装 Ansible

pip3 install ansible

我们所提供的demo文件结构如下

eric@mypc:~$ tree
.
├── ansible.cfg
├── group_vars
│ └── sonic.yml
├── host_vars
│ └── sonic1.yml
├── inventory
├── library
│ └── sonic_klish.py
└── site.yml

2.在 ansible.cfg 中指定设备信息文件

[defaults]
inventory = inventory #指定为’inventory’文件
host_key_checking = False
retry_files_enabled = False
gathering = explicit
stdout_callback = yaml

3.在 inventory 文件中指定设备的登录信息

[sonic]
sonic1 ansible_host=192.168.1.x ansible_user=x ansible_password=x

4.group_vars/sonic.yml 文件不需要改动

# group_vars/sonic.yml
host: “{{ ansible_host }}”
user: “{{ ansible_user }}”
password: “{{ ansible_password }}”

5.host_vars/sonic1.yml 中编写要下发的配置

以下为两组示例的命令行配置

config_vlan_cmd: |
configure
vlan 3003
end
exit

config_acl_test_cmd: |
configure
access-list L3 test1 ingress priority 500000
rule 1 packet-action permit redirect-action ethernet 11
exit
interface ethernet 11
acl test1
end
exit

6.library/sonic_klish.py

不需要改动,用来调用设备的 CLI(代码略)

7、site.yml 设置用例

新增两个task分别调用config_acl_test_cmdconfig_vlan_cmd


– hosts: sonic
gather_facts: no
tasks:
– name: Push klish commands
sonic_klish:
commands: “{{ config_acl_test_cmd }}”
host: “{{ host }}”
user: “{{ user }}”
password: “{{ password }}”
delegate_to: localhost
register: result

– name: Push klish commands 1
sonic_klish:
commands: “{{ config_vlan_cmd }}”
host: “{{ host }}”
user: “{{ user }}”
password: “{{ password }}”
delegate_to: localhost
register: result

– debug: var=result.stdout

8.执行用例

[root@localhost ansible]# ansible-playbook -v site.yml
Using /home/ryan/ansible/ansible.cfg as config file

打印如下,则执行完毕:

PLAY [sonic] *********************

TASK [Push klish commands] ****************
changed: [sonic1 -> localhost] => changed=true
stdout: |-
Warning: Permanently added ‘192.168.1.102’ (RSA) to the list of known hosts.
…Entering cli view, please wait…
stty: ‘standard input’: Inappropriate ioctl for device
stty: ‘standard input’: Inappropriate ioctl for device
sonic# configure
sonic(config)# access-list L3 test1 ingress priority 500000
sonic(config-L3-acl-test1)# rule 1 packet-action permit redirect-action ethernet 13
sonic(config-L3-acl-test1)# exit[J
sonic(config)# interface ethernet 13
sonic(config-if-13)# acl test1[J
sonic(config-if-13)# end[J
sonic# exit
stdout_lines: <omitted>

TASK [debug] ***********************
ok: [sonic1] =>
result.stdout: |-
Warning: Permanently added ‘192.168.1.102’ (RSA) to the list of known hosts.
…Entering cli view, please wait…
stty: ‘standard input’: Inappropriate ioctl for device
stty: ‘standard input’: Inappropriate ioctl for device
sonic# configure
sonic(config)# access-list L3 test1 ingress priority 500000
sonic(config-L3-acl-test1)# rule 1 packet-action permit redirect-action ethernet 13
sonic(config-L3-acl-test1)# exit[J
sonic(config)# interface ethernet 13
sonic(config-if-13)# acl test1[J
sonic(config-if-13)# end[J
sonic# exit

TASK [Push klish commands] *****************
changed: [sonic1 -> localhost] => changed=true
stdout: |-
Warning: Permanently added ‘192.168.1.102’ (RSA) to the list of known hosts.
…Entering cli view, please wait…
stty: ‘standard input’: Inappropriate ioctl for device
stty: ‘standard input’: Inappropriate ioctl for device
sonic# configure
sonic(config)# vlan 3003
sonic(config-vlan-3003)# end[J
sonic# exit
stdout_lines: <omitted>

TASK [debug] *********************
ok: [sonic1] =>
result.stdout: |-
Warning: Permanently added ‘192.168.1.102’ (RSA) to the list of known hosts.
…Entering cli view, please wait…
stty: ‘standard input’: Inappropriate ioctl for device
stty: ‘standard input’: Inappropriate ioctl for device
sonic# configure
sonic(config)# vlan 3003
sonic(config-vlan-3003)# end[J
sonic# exit

PLAY RECAP ************************
sonic1 : ok=4 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

对星融元产品感兴趣?

立即联系!

返回顶部

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