标签：技术实现

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完成对多厂商设备的统一集中监控。

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 模型或 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 模型的几种主流管理协议

NETCONF

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

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

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

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 性能卓越，通过单一协议解决了配置与监控需求，并且原生支持流式遥测，推送模式效率远高于轮询，是云原生/可编程网络的首选。

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

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

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

星融元目前的支持情况

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

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

关注星融元

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

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

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

典型配置工作如下：

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

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

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

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

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

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

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

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

本例所用到的设备为：

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

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

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

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

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

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

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

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

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 – 拓扑生成

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

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

第3步，基础网络配置

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

业务区网络配置

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

ACC – 业务区网络配置

服务器区网络配置

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

ACC – 服务器区网络配置

出口路由配置

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

第4步，业务配置

有线业务配置

默认业务区的主要在Leaf1和Leaf2设备上进行，为不同业务区域定义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 – Dashboard

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

该工具的核心特点是基于agentless和声明式模型，借助 SSH 或 WinRM 协议直接管理节点，避免了客户端代理的安装和维护成本，其大致的交互模式为用户通过YAML语言编写 Playbook定义目标状态，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_cmd和config_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

EasyRoCE工具上新：RoCE监控再升级，网卡状态也采集

关注星融元

在数据中心智算场景中，除了 GPU 本身的性能和调度算法，集群的整体性能很大程度上还取决于底层通信栈的效率。

智算集群的底层通信机制可分为机内通信和机间通信两大类。机内通信指在一台服务器内部，各个计算部件之间的数据交换，最典型的就是一台AI服务器内部，多个GPU（例如8张A100/H100卡）之间、GPU与CPU之间的高速通信。机间通信，则是让成百上千台AI服务器通过高性能网卡和交换机实现互联（scale-out网络）进行数据交换和协同工作，将算力规模成倍放大。

从“机内通信”的 NVLink/PCIE 通道，到“机间通信”所经过的网卡、交换机的每个端口，以及每个无损传输队列，都必须完成精密高效的协同运作，任何一个环节成为瓶颈都会导致昂贵的计算资源（GPU）处于“等待数据”的空闲状态，极大降低整个集群的算力利用率。

跨节点通信的全环节监控

作为IB网络强有力的竞争者，RoCEv2拥有高性能、兼容标准以太网生态、成本可控、扩展性强、支持多租户与虚拟化等优点，但其对网络无损有严格要求，配置不当很可能会放大拥塞，例如 PFC、ECN、Buffer 滞留等RoCE参数配置不合适，对外都是笼统表现为通信异常，网络性能下降，而逐项排查的操作相当繁琐。

为解决 RoCE 网络监控运维上的不便，此前我们已发布用于监控星融元 RoCE 交换机各项网络配置和状态指标的 AsterNOS Exporter 和 RoCE exporter以及配套的一系列高效运维工具。参考阅读：一文解读开源开放生态下的RDMA网络监控实践

现在我们新推出了 EasyRoCE-NE （NIC Exporter）网卡状态采集工具，不光是交换机和光模块，服务器网卡信息也可一并纳入统一监控平台。

网卡状态采集工具（NE）

NE 是 EasyRoCE 工具集中针对服务器网络监控部分的组件，主要分为 Exporter 客户端(NIC Exporter)code>和监控面板自动化创建程序(NIC Generator)两部分。

NIC Exporter 运行在 GPU 服务器内部，主要工作是采集服务器网卡（例如 Mellanox NIC ）的配置以及流量状况，将其转换为 Prometheus 能理解的标准格式并通过 HTTP 接口暴露。

NIC Generator 运行在部署管理节点（安装了星融元 EasyRoCE Toolkit 的服务器），该程序从EasyRoCE-AID（配套的数据库组件，什么是AID工具？）读取GPU服务器的IP信息，自动在EasyRoCE-UG（Unified Glancer）创建可视化监控面板，把客户端采集的信息一站式展示出来。

网卡配置：网卡驱动固件版本、名称，运行状态
RoCE配置：DSCP, TOS, ECN, PFC, CNP 报文DSCP值
网卡流量：网口带宽，收发速率，丢包统计
ECN标记数，CNP收发统计，PFC收发帧数统计

安装配置步骤

下载 EasyRoCE-NE 工具包

nic_exporter.tgz、nic_exporter，请联系销售/售前人员获取。

在AID中完成配置信息

用户需要事先通过EasyRoCE-AID完成网络规划，并将其上传到服务器的EasyRoCE Toolkit目录下。

安装客户端nic_exporter

将nic_exporter上传到GPU服务器中并后台启动，默认监听9105端口。

chmod +x nic_exporter nohup ./ nic_exporter &

安装自动化脚本

将nic_exporter.tgz上传到服务器的 EasyRoCE Toolkit 目录下并解压，解压后目录结构如下：

. ├── ne_dashboard.json #UG面板文件 ├── nic_generator.py #启动脚本 └── requirements.txt #依赖

为了避免影响服务器自身的python环境，推荐使用venv 作资源隔离：

python -m venv .venv source .venv/bin/activate

安装依赖

pip install -r requirement.txt

启动NE工具

./nic_generator.py

打印如下即成功创建面板:

Pushing dashboard to Grafana... Dashboard pushed successfully: {'id':116, 'slug': 'gpuserver8', 'status': 'success', 'uid': 'easyroce-ne-gpu-server8', 'url': '/d/easyroce-ne-gpu-server8/gpu-server8', 'version': 4}All dashboards processed. Total: 8. Url: http://10.106.219.5:3000/dashboards/f/XXXXXXX

一文看懂 PTP（精确时间协议）及SONiC上的最新优化实践

关注星融元

什么是PTP？

PTP，简写自 Precision Time Protocol（精确时间协议）。顾名思义，PTP 用于为时间同步敏感的系统和应用程序在局域网或广域网上创造高精度时间同步的环境，往往需要通过硬件辅助才能实现。

PTP 在 IEEE 1588 标准中定义，目前已发展到的 IEEE 1588 v2 具有双向通道、纳秒级精度、广泛适应不同接入环境。

PTP 网络的基本架构如下图所示：所有时钟都会按照主从（Master-Slave）关系组织在一起，以GMC为起始点，向各节点逐级同步时钟。

需要注意的是，这种主从关系是相对而言的，因为一些设备不但会从上层设备同步时钟（此时作为从节点/时钟），也会向下层设备发布时钟（此时作为主节点/时钟）。

Grandmaster Clock：（GMC，大师钟）最高级别的时钟，作为时钟源为整个PTP域提供参考时间。设备一般需要具有GNSS（全球导航卫星系统，例如GPS，北斗等）接收器。GMC的产生方式，可以是手工配置一个静态的，也可以通过最佳主时钟 BMC（Best Master Clock）算法动态选举。
Boundary Clock（BC，边界时钟）：提供两个或多个物理端口参与PTP域的时间同步，其中一个端口与上游设备同步时间，其他端口将时间发送给下游设备。
Transparent Clock（TC，透明时钟）：不与其他设备同步时间，仅在其 PTP 端口之间转发 PTP 消息并测量消息的链路延迟。
Ordinary Clock（OC，普通时钟）：仅提供一个物理端口参与PTP域内的时间同步，通常用作网络的终端节点，连接到需要同步的终端设备。

设备上运行 PTP 协议的端口称为 PTP 端口，其中发布同步时间的端口称为“主端口（Master Port）”，接收同步时间的端口则称为“从端口（Slave Port）”。此外，也有既不接收也不发送同步时间的“被动端口”（Passive Port），它只存在于边界时钟（BC）上。

PTP 如何工作？

实现时钟同步主要包括3个步骤：

建立主从关系，选取大师时钟（GMC）、协商端口主从状态等。
频率同步（Frequency synchronization），从节点时间与主节点同步，信号之间保持恒定相位差。
相位同步（Phase synchronization），从节点时间与主节点同步，信号之间相位差恒定为零。

PTP 报文

要实现高精度时间同步，很关键的一点是让“从时钟”通过 PTP 报文中携带的时间戳信息，计算与“主时钟”之间的偏移和延时，并据此调整本地时钟来实现时间同步。

根据报文是否携带时间戳，我们可以将PTP报文分为两类：

非时间概念报文，进出设备时不会打上时间戳；用于 PTP 网络系统主从关系的建立、时间信息的请求和发布，
时间概念报文，进出设备端口会打上精确时间戳；PTP 网络系统会根据报文携带的时间戳计算链路延迟。该类报文包含以下四种：Sync、Delay_Req、Pdelay_Req和Pdelay_Resp。

PTP的延迟测量机制

PTP 网络如何从 PTP 报文中计算得出偏移和延时信息呢？这里就必须说到延迟测量机制，主要有“端到端（E2E）”和“点对点 (P2P) ”两种。

E2E 的测量机制

E2E 机制下，中间设备（E2E TC）在转发计时消息的同时，会添加一个停留时间 (rt) ，E2E 机制使用双向消息计算总路径延迟作为时间补偿。

计算公式：
t₂ – t₁ = 偏移 + 延迟
t₄ – t₃ = 延迟 – 偏移
延迟 = (t₂-t₁)+(t₄-t₃)/2
偏移量 = (t₂-t₁)-(t₄-t₃)/2
T_OC_new = T_Master ± 偏移量

P2P 的测量机制

不同于 E2E 机制，P2P 的测量机制在会在每一跳交换消息以测量链路延迟，从而实时测量并纠正每跳延迟。

计算公式：
PD1 = (pt2-pt₁)+(pt₃-pt2)/2
PD2 = (pt₄-pt₁)+(pt₄-pt₃)/2
校正字段（correction field） = PD1 + rt
偏移量 = t₂ – t₁ – 校正字段 – PD2
T_OC_new = T_Master ± 偏移量

在SONiC上的PTP优化：精度从1000ns提升至20ns

LinuxPTP

在 Linux 中，PTP 协议的实现称为 Linux PTP，它基于 IEEE 1588 标准，软件包有 ptp4l 和 phc2sys。

我们基于 ptp4l 和 Linux 网卡做了测试，可以看到：同步精度分布在 1000ns（1μs）以内，并且存在 8000ns（8μs）以上的不稳定跳变。

在没有额外调优工作的前提下，这样的同步精度对于个人爱好者或一般实验环境或许足够，但离企业级商用场景还远远不够。

作为参考，此处列出 ITU（国际电信联盟）提出的时间同步能力分类，

A类：时间误差≤50ns，适用于对同步精度要求较低的一般电信网络。
B类：时间误差≤20ns，适用于更严格的时间同步场景，如5G基站同步。
C类：时间误差≤10ns，主要用于对同步精度要求极高的场景，例如5G前传。

SONiC（AsterNOS） PTP

深入研究上述原理和机制后，我们发现 SONiC 开放架构不但能够灵活地满足各种时间同步要求，还能为广大客户提供自由选择，消除供应商锁定。

早在2024年上半年，星融元就引领社区开始着手在 SONiC 中实现 PTP ，并优化其在企业级 SONiC 发行版 AsterNOS 上的性能。

下图是 AsterNOS 内的 PTP 子系统示意图，包含一个运行 Linux PTP / ptp4l 并与 RedistDB 和底层硬件驱动程序交互的 PTP 容器。此外这套系统还支持多种网络管理协议，例如 RESTful API、RESTconf 和 Netconf，给到更优的系统集成和互操作性。

通过硬件加速和软件算法优化的星融元 PTP 交换机的时间同步精度分布在 20ns 以内，并且不同延迟测量模式获得的偏差结果几乎相同。

one-step：Sync 报文带报文发送时刻的时间戳
two-step：Sync 报文不带报文发送时刻的时间戳，只记录本报文发送时的时间，由Follow_Up报文带上该报文发送时刻的时间戳。

目前，星融元 CX-M 交换机产品已经系列化地支持了 PTP ，兼容 E2E 和 P2P 模式和多种配置文件。

可在设备模拟器体验 PTP 功能特性 👉vAsterNOS Campus v6.0

应用场景（广播媒体行业）

该图展示了一个典型广播和媒体网络拓扑，采用星融元的 PTP 交换机提供多个 PTP 域和冗余时钟源（主备切换），为音频和视频分配单独的域号，在网络中实现 20ns 时间同步精度，确保音频、视频和其他数据流量的无缝对齐。

分布式网关技术 + BGP EVPN，解锁真正的无缝漫游

近期文章

无线漫游的核心挑战与标准化协议支持

在构建高性能无线网络时，实现用户终端（STA）在不同接入点（AP）之间平滑、快速的漫游是核心目标之一。我们的无线AP产品原生支持业界标准的802.11k/v/r协议（常称为“快速漫游三协议”），为降低漫游时延奠定了坚实基础：

802.11k (邻居报告)：解决“去哪漫游”的问题。AP主动向关联的终端提供周边优质AP的列表（包括信道、信号强度等信息），使终端能快速发现并评估潜在的目标AP，避免盲目扫描带来的延迟。
802.11v (网络辅助漫游)：解决“何时漫游”的问题。网络侧（通常通过AP或控制器）可以基于负载均衡、信号质量等策略，主动向终端发送漫游建议（BSS Transition Management Request），引导终端在最佳时机触发漫游，减少因终端粘滞在弱信号AP上造成的性能下降。
802.11r (快速基本服务集转换)：解决“如何快速接入”的问题。通过在漫游发生前预先完成部分或全部认证/密钥协商过程（FT Initial Mobility Domain Association），使得终端连接到新AP时能实现近乎“瞬间”的重关联，大幅缩减了链路层切换时间。

这三项协议协同工作，显著优化了无线链路层（L2）的切换效率，是降低整体漫游时延的关键第一步。

超越链路层：IP地址保持的必要性与挑战

然而，成功关联到新AP（完成L2切换）仅是漫游过程的上半场。要真正恢复业务连续性，终端必须能够快速、可靠地使用原有的IP地址进行三层（L3）通信。这意味着漫游后的IP层连通性同样至关重要。

传统L3漫游（如图）：

在漫游场景下，终端从一个AP切换到另一个AP后，其是否需要重新发起DHCP请求以获取IP地址，主要由终端自身的操作系统和驱动策略决定，网络侧无法强制干预。常见情况是：

普遍行为：绝大多数移动终端厂商（如智能手机、平板）倾向于采用一种简单且保守的策略：无论新老AP是否在同一IP子网内（即无论是L2还是L3漫游），只要检测到关联的AP发生了变更，就会主动发起一次DHCP请求（通常是DHCP REQUEST或DISCOVER）。这对终端来说是最直接、最可靠的判断IP状态变化的方法。
例外情况：当然，并非所有终端在所有场景下都会这样做。某些终端或特定操作系统版本可能仅在检测到IP子网变更（即L3漫游）时才发起DHCP请求，或者在IP租期未过半时选择续租而非重新请求。这种终端行为的差异性，正是导致不同设备实测漫游时延存在波动的原因之一，也是我们强调“平均漫游时延”指标的现实基础。
租期到期：显而易见，如果漫游发生时，终端IP地址的DHCP租期恰好到期，则必然触发完整的DHCP流程（DISCOVER, OFFER, REQUEST, ACK）。

因此，即使链路层切换再快，如果IP地址获取过程（无论是必要的重新获取还是冗余的请求）耗时过长，整体漫游体验仍会大打折扣。

所以，802.11k/v/r三个协议解决的是同一个二层域内的漫游问题，在同一个二层域内网关是不会改变的。而要解决跨二层域的漫游（L3），就需要我们的分布式网关技术，让终端无论漫游到哪个AP，这个AP连接在哪个接入交换机上，都能获得同样的网关，分配到同样的IP，从而实现无缝漫游。

分布式网关与BGP EVPN：消除冗余DHCP时延的关键

作为网络设备提供商，我们通过创新的分布式网关架构结合BGP EVPN技术，从根本上解决了漫游后IP地址保持和快速可达的问题，有效规避或极大压缩了冗余DHCP请求带来的时延：

1、分布式网关架构：在这种架构中，终端网关（Default Gateway）不再集中部署在核心或汇聚层，而是下沉到每一个接入交换机（或分布式网关节点）上。接入交换机直接作为本地终端的网关，并承担DHCP Relay Agent的角色。

2、BGP EVPN的核心作用： BGP EVPN (Ethernet VPN) 是一种强大的控制平面协议。它不仅仅用于构建Overlay网络，其核心能力在于高效地分发和同步二层（MAC地址）和三层（IP地址、主机路由）信息。

在我们的方案中：

当终端首次接入网络并通过某个接入交换机（作为网关/DHCP Relay）成功获取IP地址后，该交换机会通过BGP EVPN协议，将终端的IP地址、MAC地址以及对应的主机路由信息（/32或/128）快速通告给网络中的所有其他接入交换机（网关节点）。

无论终端漫游到哪个AP下（无论该AP连接的是否是同一个接入交换机），新的接入交换机（网关节点）在BGP EVPN控制平面中都已经预先学习到了该终端的完整IP和MAC绑定信息及其主机路由。

3、优化DHCP流程：当漫游后的终端（遵循其自身策略）发起DHCP REQUEST（或DISCOVER）时：

新的接入交换机（作为DHCP Relay Agent）收到该请求。
由于它已通过BGP EVPN知晓该终端的IP/MAC绑定关系，它能够立即判断出该终端已经拥有一个有效的、未过期的IP地址。
因此，该接入交换机无需将请求转发给远端的DHCP服务器，而是直接以DHCP Relay Agent的身份，模拟DHCP服务器的行为，向终端回复一个DHCP ACK报文，明确告知终端“继续使用你原有的IP地址”（即包含原有的IP地址信息）。

这个过程将原本可能需要数百毫秒的多跳DHCP交互（Relay->Server->Relay->Client），压缩为一次本地化的、毫秒级的交换处理（Relay直接回复ACK），彻底消除了向中心DHCP服务器请求所带来的潜在网络拥塞、服务器处理延迟以及多跳传输时延。

流量转发优化：直达路径提升业务体验

在成功保持IP地址后，确保业务流量能高效转发同样重要：

传统集中转发瓶颈

在传统集中式无线架构（如FAT AP + AC或部分云管理方案）中，即使用户数据流量（User Traffic）在漫游后仍需先回传（Tunnel）到无线控制器（AC）进行集中处理和转发。对于跨AC的大规模漫游，流量甚至需要在不同AC之间隧道绕行，最终才能到达出口网络。这种“三角形路由”（Hairpinning）显著增加了传输路径和时延。

分布式网关+云化架构优势

分布式网关架构天然支持本地转发。结合去中心化的云化管理架构（控制管理面云化，数据转发面分布式）：

漫游成功后，终端的业务流量直接在新的接入交换机（作为其网关）完成三层路由查找。
流量无需绕行任何集中式控制器（AC），即可通过该接入交换机直连的上层汇聚/核心交换机以及出口设备访问互联网或企业内网资源。

极致漫游体验的技术基石

我们综合运用标准化的802.11k/v/r协议实现快速链路层切换，并通过分布式网关架构结合BGP EVPN技术智能处理IP层连续性，最后依托本地化、最优化的流量转发路径，成功实现了业界领先的超低漫游时延。

实测表明，我们的方案能够稳定地将平均漫游时延控制在<10ms以内。这不仅显著超越了依赖传统集中式网关和DHCP处理流程的解决方案（其额外DHCP交互和集中转发路径极易引入数十甚至上百毫秒的延迟），更能满足医疗、工业物联网、高密度场馆等对漫游性能要求极为苛刻的场景需求，为客户带来真正无缝、极致的无线漫游体验。

最新动态

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

关注星融元

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

存储架构沿革
分布式存储网络协议选择
交换机硬件设备选型
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）方式接入。

网络硬件选型

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

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

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/

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

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

关键测试指标

存储性能测试项整体上分为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的大小是混合的。

性能测试步骤和工具

存储网络的性能测试。主要关注网络单链路的吞吐和时延，常用的工具是iperf、ib_read/write_bw、ib_read/write_lat；
会进行存储系统的基础性能测试。这里关注的是存储系统的时延和吞吐，常用的工具是fio；
业务级别的兼容性、稳定性以及性能测试。兼容性方面主要测试交换机的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媲美的性能和无损网络
超低时延提高业务并发量，加快数据传输速度，提升业务响应效率，抢占市场先机
更低的技术门槛和运维成本，可以在传统以太网上实现超低时延、零丢包、高性能的网络传输

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 试用，请与我们联系。

【参考文档】

云化园区

网络操作系统（SONiC）

可视交换机

开放硬件平台

标签： 技术实现

关注星融元

快速回顾: CLI 和 SNMP

什么是 YANG （数据建模语言）？

设备的配置管理

设备的运行状态

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

NETCONF

RESTCONF

OPENCONFIG/gRPC

星融元目前的支持情况

关注星融元

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

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

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

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

DHCP server 的高可靠设计

关注星融元

ACC混合组网运维管理方案

化繁为简、快速开局

第1步，设备导入

第2步，规划拓扑

第3步，基础网络配置

第5步，配置下发

运维效率提升

创新性的云化设计理念

关注星融元

什么是 Ansible？

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

示例步骤

1.在服务器上安装 Ansible

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

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

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

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

6.library/sonic_klish.py

7、site.yml 设置用例

8.执行用例

关注星融元

跨节点通信的全环节监控

安装配置步骤

下载 EasyRoCE-NE 工具包

在AID中完成配置信息

安装客户端nic_exporter

安装自动化脚本

安装依赖

启动NE工具

关注星融元

什么是PTP？

PTP 如何工作？

PTP 报文

PTP的延迟测量机制

E2E 的测量机制

P2P 的测量机制

在SONiC上的PTP优化：精度从1000ns提升至20ns

LinuxPTP

SONiC（AsterNOS） PTP

应用场景（广播媒体行业）

近期文章

无线漫游的核心挑战与标准化协议支持

超越链路层：IP地址保持的必要性与挑战

分布式网关与BGP EVPN：消除冗余DHCP时延的关键

流量转发优化：直达路径提升业务体验

传统集中转发瓶颈

分布式网关+云化架构优势

极致漫游体验的技术基石

最新动态

关注星融元

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

分布式存储网络的搭建

网络协议的选择

组网架构

网络硬件选型

RoCE 无损网络的配置和管理

一般手动方式

基于网络自动化工具

标签：技术实现

虚拟化试用（vAsterNOS）