标签：技术实现

一文看懂 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 时间同步精度，确保音频、视频和其他数据流量的无缝对齐。

近期文章

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

在构建高性能无线网络时，实现用户终端（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 试用，请与我们联系。

【参考文档】

优化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

工作原理

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。如需了解产品详情或项目定制方案请与我们联系。

云化园区

网络操作系统（SONiC）

可视交换机

开放硬件平台

标签： 技术实现

关注星融元

什么是PTP？

PTP 如何工作？

PTP 报文

PTP的延迟测量机制

E2E 的测量机制

P2P 的测量机制

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

LinuxPTP

SONiC（AsterNOS） PTP

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

近期文章

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

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

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

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

传统集中转发瓶颈

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

极致漫游体验的技术基石

最新动态

关注星融元

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

分布式存储网络的搭建

网络协议的选择

组网架构

网络硬件选型

RoCE 无损网络的配置和管理

一般手动方式

基于网络自动化工具

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

关键测试指标

性能测试步骤和工具

测试参数说明

最佳实践

需求背景

方案介绍

关注星融元

什么是哈希极化？

主动路径规划配置逻辑

借助 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

告警管理

巡检与固件管理

近期文章

标签：技术实现

虚拟化试用（vAsterNOS）