标签：技术分享

EasyRoCE 上新：RoCE网卡参数配置工具

告别低效的手动运维，星融元EasyRoCE-NC助您轻松完成网卡批量部署。

智算中心场景中，GPU分布式训练的性能很大程度取决于底层网络的通信效率，其中RoCE网络对网卡参数配置的一致性、准确性要求极高，配置偏差会直接引发网络丢包、拥塞死锁、训练性能骤降甚至任务中断。

手动配置难以为继

传统手动配置方式在智算集群运维中存在很多痛点，难以适配大规模集群的管理需求：
效率极低：数百台规模的集群需运维人员逐台登录服务器配置，费时费力
一致性差：人工配置失误导致集群RoCE配置不统一，引发网络性能不均，且问题定位难度极大
无环境预检：配置前无法批量验证服务器驱动、固件和RDMA组件的完整性，导致配置中途频繁失败
缺乏持久化保障：手动配置没有标准化开机自启方案，一旦服务器重启后配置丢失，需要低效的重复操作

网卡参数配置工具 EasyRoCE-NC

星融元 EasyRoCE Toolkit 新推出的网卡参数配置工具（Network Configurator，NC）专为智算中心网络打造，通过实现规模集群 RoCE 网卡的一键式配置，解决上述传统运维方式带来的核心痛点。

标准化配置：基于统一规划，一键完成全集群RoCE网卡参数配置，保证集群服务器参数一致
环境预检：配置前自动完成集群网卡环境检查，提前规避风险
低门槛易操作：无需运维人员精通RoCE底层技术，一键执行即可完成配置，降低运维门槛
支持配置持久化：根据需求选择RoCE配置是否持久化，避免服务器重启后配置丢失

实现原理

NC 工具通过从数据源（EasyRoCE-AID工具，AI基础设施蓝图）中自动解析到集群服务器网卡规划与RoCE参数，完成网卡环境预检、标准化配置脚本生成和批量执行动作。

此外，NC工具可与EasyRoCE-UG平台无缝打通。配置完成后即可通过 NE、TM、TG、DP 等组件（参阅开源开放生态下的RDMA网络监控实践），实现网卡状态、光模块健康、网络拓扑和交换机硬件的全维度可视化监控。

安装步骤概览与效果

环境和工具准备

1、服务器要求

NC工具运行在集群的监控服务器上，该服务器需安装 Mellanox OFED 版本驱动，驱动与网卡固件版本匹配，已开启SSH服务并配置免密登录，管理网IP与监控节点网络互通。

2、数据源

NIC Configurator(NC) 工具以 EasyRoCE-AID 为核心数据源，用户需提前在服务器上安装该工具，并按用户指导文档修改文件路径和名称。

[root@server1 EasyRoCE]# cat config.ini 
[GRAFANA]
GRAFANA_URL =
API_KEY =
DIRECTORY_NAME = 
[COMMANDS]
AID_path = /root/EasyRoCE
AID_file = EasyRoCE-AID-v1.8.xlsm
prometheus_uid =

3、NIC Configurator (NC)工具包

用户可通过星融元官网EasyRoCE：网卡参数配置（NC）或项目销售人员获取最新版本NC工具包。

安装NC工具

将NC工具包上传到监控服务器的EasyRoCE工具目录下。解压后，执行EasyRoCE-NC.py启动脚本即可完成配置和环境预检（配置失败的GPU服务器会跳过，并告知未通过项)。

 [root@localhost EasyRoCE-NC]# python3 EasyRoCE-NC.py 
文件路径：./roce_server_config.json
成功生成 2 台服务器的配置
============================================================
开始环境预检，共 2 台服务器（并发数: 10）
============================================================
❌GPU-Server02: 未通过项: 
ib_dev:mlx5_10, ib_dev:mlx5_12, netdev_map:mlx5_10, netdev_map:mlx5_12
ib_dev:mlx5_10: mlx5_10 不在 /sys/class/infiniband/，当前设备: 无
⚠ib_dev:mlx5_12: mlx5_12 不在 /sys/class/infiniband/，当前设备: 无
⚠netdev_map:mlx5_10: mlx5_10 在 ibdev2netdev 输出中无映射，脚本执行时将跳过该设备
⚠netdev_map:mlx5_12: mlx5_12 在 ibdev2netdev 输出中无映射，脚本执行时将跳过该设备
✅GPU-Server01 (10.230.1.12): 所有检查通过

============================================================
❌ 预检未通过，以下服务器存在问题：
-GPU-Server02
请修复上述问题后重新运行
============================================================

最终效果

正确完成 NC 工具的上述安装配置流程，并协同 EasyRoCE-NE工具（网卡状态采集），用户就可在EasyRoCE-UG 监控面板上直观地查看集群服务器集群网卡的详细信息。

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

产品型号： 星融元（Asterfusion）CX664D-N（64 x 200G QSFP56/QSFP28/QSFP+）
功能特性：RoCEv2, PFC, ECN, DCBX ……

应用场景：分布式存储，数据中心，GPU算力集群
最后更新：2026-05-26

星融元(Asterfusion)

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

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

企业 AI 流量与出海应用精细化管控指南：基于 AsterNOS 的合规与网络调度实践

拒绝传统 L7 DPI：以轻量级 Geo-Engine 与 HQoS 重塑边缘智能调度

全面拥抱 AI 的今天，企业的 IT 管理者们正陷入两难的拉扯：既不能因噎废食全面封杀，也无法承受毫无管控的数据风险。

面对 IP 频繁跳动、TLS 1.3 全加密的海外 AI 应用，传统依靠手工维护 IP 黑白名单的防火墙早已力不从心。

想要在安全合规与业务效率之间找到完美平衡，我们需要重新认识 AI 流量，并赋予网络边缘更智能的调度能力。

重新定义企业 AI 流量工作流

在讨论如何管理之前，我们必须明确一个核心概念：AI 流量不应该仅仅局限于“与大模型对话的 Token 交互”（Inference Traffic）。对于拥有研发、设计团队的企业来说，AI 业务的工作流是完整的，涵盖了截然不同的流量特征：

模型获取与环境构建（重度带宽消耗）：从 HuggingFace、Civitai 或 GitHub 下载动辄几十 GB 的基础大模型（Checkpoint）和代码库。
云端 API 高频调用（突发性并发流量）：设计部批量使用云端生成式生图 API，带来极高的并发请求。
日常交互型对话（低带宽、高频次、对延迟极度敏感）：员工与 Claude、ChatGPT 进行的文本 Token 交互。

如果不能全面识别这些涵盖整个 AI 工作流的加密数据，所谓的管控就是纸上谈兵。

替代传统 L7 DPI：精准识别加密 AI 流量

面对上述复杂的 AI 流量特征与精细化的部门管控需求，基于 SONiC 与 VPP 架构的 AsterNOS 给出了一套优雅的解法:

抛弃臃肿且严重拖累性能的传统 L7 DPI 深度包检测，利用 VPP 数据面开发的轻量级 Geo-Engine（域名/应用提取引擎）结合 ACL 与 HQoS，实现精准把控。

AsterNOS 能够在 TLS 1.3 握手阶段（Client Hello）直接抓取 SNI 字段或提取 DNS 请求头，瞬间识别出流量的目标业务身份（如 geosite:OPENAI、geosite:HUGGINGFACE）。

然而，仅仅做到“精准识别”还远远不够。像 OpenAI 这样庞大的全球化应用，其背后关联的域名、CDN 节点和 API 接口成百上千，且每天都在动态变化。如果沿用传统防火墙“在命令行里手工逐条敲入 IP 或域名”的陈旧方式，网络运维团队依然会陷入无休止的配置泥潭中。

针对这一痛点，AsterNOS 的解法是：用“开源生态与数据驱动”彻底取代落后的手工规则。

作为开放网络生态的构建者，AsterNOS 拒绝了传统安全厂商封闭的“黑盒特征库”模式。系统原生支持并兼容开源社区（如 GitHub 上的 domain-list-community）的标准 GeoSite/GeoIP 库格式。这意味着，设备可以自动同步全球数万名开发者共同维护的最新 AI 站点特征，无惧海外服务的频繁变动，彻底解放运维的双手。

更重要的是，这套特征库彻底解放了运维的双手，支持每日 0 点自动拉取最新规则，无惧海外 AI 站点 IP 与域名的频繁变动。同时，它完全开放了 DIY 权限，企业可以随时手动添加或修改专属的内部业务域名，实现真正的自主可控。

基于这种强大的“业务感知”能力，我们可以轻松落地以下真实管理场景：

场景一：基于部门的精细化合规隔离（GeoSite + 状态 ACL）

如何确保核心数据部门完全隔离于外部 AI 工具，同时保障研发部门顺畅使用？

通过 AsterNOS 的状态 ACL 结合 GeoSite，我们可以基于内网源 IP 段（不同部门）设定截然不同的访问规则，彻底告别“一刀切”。

1. 核心财务/数据部门

全面阻断 AI 与出海媒体应用:

access-list SECURE_ACL_FINANCE
rule 10 deny geosite OPENAI
rule 20 deny geosite CLAUDE
rule 30 deny geosite CATEGORY-MEDIA

2. 研发/设计部门

精准放行 AI 业务池:

access-list SECURE_ACL_RND
rule 10 permit geosite OPENAI
rule 20 permit geosite HUGGINGFACE

场景二：保障出海专线体验与大模型下载限速（HQoS 流量调度）

研发部门合规获取到了访问 HuggingFace 的权限，但如果不加节制地下载几十 GB 的大模型，瞬间就会挤占公司出海专线的带宽，导致管理层的跨国 Zoom 视频会议卡顿掉线。

流量放行不等于放任。AsterNOS 不仅能“认出”应用，还能结合强大的层次化 QoS（HQoS）进行动态调度: 在识别出大模型下载流量后，为其分配特定的整形策略（基于 CIR/PIR 承诺与峰值速率），而为核心视频会议流保留最高优先级的 STRICT 队列。

配置步骤参考如下：

1. 基础映射

定义 DSCP 到内部转发队列 (TC) 的映射关系

# 将普通数据流量（大模型下载等）映射到基础队列 TC0
qos map dscp_to_tc voice-prio 0 0

# 将核心语音/视频流量映射到最高优先级的队列 TC7
qos map dscp_to_tc voice-prio 46 7

2. 调度配置

创建研发部门的 HQoS 用户模板，精细化定义底层行为

hqos-user-profile emp-standard
# 绑定上述映射规则以对齐出口队列
qos-map bind dscp_to_tc voice-prio
# Queue 0：采用 DWRR 模式（保障基础数据与模型下载，防止网络饿死）
tc-queue 0 mode dwrr 1
# Queue 7：采用 STRICT 严格优先级模式（保障跨国会议零时延、零丢包）
tc-queue 7 mode strict

软硬协同: AsterNOS-VPP 构建新一代智能企业边界网关

为了支撑这些毫秒级的识别与调度，AsterNOS-VPP 完美适配星融元的 ET 系列智能业务处理平台。

ET3600 系列智能网关平台（左图）
2 x 100GE QSFP28, 2x10GE SFP, 2 x 2.5GE RJ45 （左上）
4 x 100GE QSFP28, 4x10GE SFP+, 4 x 2.5GE RJ45（左下）
高性能8 x 2.5GHz ARM64 Neoverse N2 Core，硬件DPDK、硬件加解密引擎
100Gbps转发能力及高性能业务处理能力（路由器、防火墙、IPSec、SSL/TLS）
最高48GB DDR5 SO-DDIM内存，最高4TB M.2存储
2个M.2插槽，以便支持5G/LTE模块；可选PTP模块，支持20ns同步精度

ET2500 系列智能网关平台（右图）
4 x 10GE, 4 x 2.5GE and 8 x 1GE, optional 8 x 1GE PoE+, 4 x 2.5GE PoE++
高性能 8 x 2.7GHz ARM64 Neoverse N2 Core，硬件DPDK、硬件加解密引擎
最高128GB DDR5 SO-DDIM内存，4TB M.2存储
60Gbps转发能力及高性能业务处理能力（路由器、防火墙、IPSec、SSL/TLS）
可选26TOPS INT8 AI硬件加速模块，150W PoE供电
运行 AsterNOS-VPP 软件

无论是具备 50Gbps 吞吐的 SMB 级边缘路由 ET2500，还是面向更大型企业分支的 100Gbps 级智能网关 ET3600，一台设备即可替代传统的“路由器+繁重的应用层防火墙+专线流控设备”，实现算网融合，灵活部署，无缝融入现有架构。

对于企业用户而言，引入新的网络控制能力不应以推翻现有架构为代价。AsterNOS 支持灵活的部署模式，最典型的场景是将其作为企业互联网或专线出口的默认网关。只需在网络边界部署，即可接管外网流量的识别与调度，无需大规模调整内网的交换与路由结构。

在这个技术更迭日新月异的时代，优秀的 IT 管理绝不是一禁了之，而是收放自如。让 AsterNOS 助你理清企业的 AI 流量脉络。

想了解您的企业网络距离 AI-Ready 还有多远？现在联系星融元，获取 AsterNOS 在企业边界网关的解决方案。

产品型号： 星融元（Asterfusion）ET3600系列智能网关平台
支持协议：PTP，IPSec，SSL/TLS……
应用场景：企业路由器，路由器，防火墙，VPN网关，负载均衡器，IDS/IPS，网络流量分析器
最后更新：2026-06-12

产品型号： 星融元（Asterfusion）ET2500系列智能网关平台
支持协议：PTP，IPSec，SSL/TLS……
应用场景：路由器，防火墙，VPN网关，负载均衡器，IDS/IPS，网络流量分析器
最后更新：2026-06-12

星融元(Asterfusion)

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

如何为时间同步网络选择合适的 PTP 配置文件

关注星融元

PTP 配置文件（PTP Profile）为特定应用场景定义了一套时间同步规则和配置约束。每个配置文件都规定了明确的功能要求、参数取值和操作行为，从而确保在同一域内、多厂商部署的环境中实现高精度、可靠的时间同步与互操作性。

PTP 配置文件分类

星融元（Asterfusion）交换机支持多种 PTP 配置文件，如G.8275.1、G.8275.2、SMPTE 2059-2等；根据不同的业务场景，主要可分为以下三大类：通用型、电信型和媒体型。

1. 通用配置文件 (General Purpose Profile)

设计初衷：专为标准 IP 或以太网环境设计
特点：未针对任何特定行业进行深度优化，具有极高的灵活性和广泛的适用性
适用场景：适用于对时间同步精度要求适中、网络模型相对开放的场景
典型代表：IEEE 1588v2 Default Profile（默认配置文件）是该类别的典型代表

2. 媒体配置文件 (Media Profile)

设计初衷：专为基于 IP 网络的广播电视及专业音视频制作环境设计，确保视频帧、音频流和控制信号的精确对齐。
特点：通常要求亚微秒级的同步精度，并支持基于组播的通信机制
典型场景：适用于 ST 2110 媒体网络、广播演播室和转播车
架构价值：通过集中式或层级化的主时钟（Grandmaster）架构，为整个网络提供统一的时间基准，是现代 IP 化广播系统稳定运行的基石

3. 电信配置文件 (Telecom Profile)

设计初衷：由 ITU-T 定义，主要面向运营商传输网和移动通信系统
特点：对时间、相位和频率精度提出了极其严苛的要求，明确规定了时钟质量等级（clockClass）行为和域值范围，并支持层次化的电信同步架构
关键作用：在 4G/5G 网络和 TDD 系统中，纳秒级的时间同步对于基站时隙对齐和网络稳定运行至关重要
星融元支持情况：支持 G.8275.1（全路径授时支持）和 G.8275.2（部分路径授时支持）配置文件，并可结合同步以太网（SyncE）进一步提升频率稳定性

PTP 配置文件详解

1. 通用配置文件：IEEE 1588v2

IEEE 1588v2 Default Profile 是应用最广泛的 PTP 配置文件，也是 G.8275.x、AES67 和 SMPTE-2059-2 等行业专用配置文件的基础。

核心功能：在标准 IP 或以太网中提供高精度同步，确保跨厂商互操作性。
部署环境：广泛应用于企业局域网、数据中心和通用以太网环境。
架构设计：采用主从时钟架构（Master/Slave），通过最佳主时钟算法（BMCA）自动选举网络中的主时钟。

【时钟类型 (Clock Type)】

在 IEEE 1588v2 中，节点角色决定了其同步功能：

普通时钟 (OC)：最基础的类型，通常只有一个 PTP 端口，既可作为主时钟发送参考时间，也可作为从时钟接收同步信息。
边界时钟 (BC)：拥有多个端口的设备，能够从上游接收同步并向下游分发时间，主要用于在大规模网络中隔离延迟累积。
透明时钟 (TC)：不调整本地时钟，仅测量 PTP 报文经过设备或链路时的延迟，并将此延迟信息附加在报文中传递给下游，从而减少端到端误差。

【报文与通信机制】

默认配置文件通过以下报文实现同步：

Sync / Follow_Up：主时钟向从时钟发送时间戳信息。
Delay_Req / Delay_Resp：从时钟测量单向延迟，用于补偿网络延迟。
Pdelay_Req / Pdelay_Resp：相邻 PTP 设备测量直连链路延迟（P2P 模式）。
Announce：主时钟广播其状态，用于 BMCA 选举。

2. 媒体配置文件：AES67 与 SMPTE-2059-2

现代 IP 广播网络利用 AES67 或 SMPTE-2059-2 实现高精度的音视频对齐。与电信配置文件相比，它们更注重满足音视频流的对齐需求，而非全网电信级的严苛授时约束。

AES67 配置文件

目标：实现音频网络互操作性，主要服务于音频流同步。
精度：通常要求亚毫秒级精度。
机制：AES67 支持单播和组播同步消息。多个主节点可以共存，其中一个主节点通过 PTP 的 BMCA 机制选定。终端节点作为从节点接收同步消息，中间网络节点无需处理 PTP 消息。

时钟类型：主时钟提供主要时间参考，通常由音频网关或核心交换机承载。从时钟使音频终端设备通过 PTP 与网络同步。

【SMPTE-2059-2 配置文件】

目标：针对 SMPTE ST 2110 等视频 IP 网络，强调视频帧对齐。
精度：要求亚微秒级精度。
关键技术：SM-TLV：该配置文件支持 SMPTE 媒体扩展（SM-TLV），用于携带媒体同步相关的元数据：

系统帧率配置：通过分子/分母表示帧率（如 29.97 fps 对应分子 30000/分母 1001），实现精确的帧级同步。
掉帧时间码（Drop-frame）：修正非整数帧率的计时偏差，确保时间码与实际时钟对齐。
色帧信息（Color-frame）：标记帧类型和颜色序列，防止在多机位切换时出现色彩偏差。

3. 电信配置文件：G.8275.1 与 G.8275.2

【G.8275.1 (全路径授时支持)】

应用场景：4G/5G 移动蜂窝系统和电信传输网。
架构要求：网络中每个中间节点都必须参与 PTP 处理，因此**禁止使用透明时钟 (TC)**，必须使用电信边界时钟 (T-BC) 进行逐跳修正。
时钟角色：

T-GM (电信主时钟)：必须溯源至 PRTC（一级参考时钟），并具备在参考丢失时的守时（Holdover）能力。
T-TSC (电信从时钟)：部署在基站等终端，接收同步信息。
T-BC（电信边界时钟）：从上游节点恢复时间，并为下游节点重新生成同步消息，执行逐跳时间校正，并在整个网络中保持同步精度。

约束：在 G.8275.1 网络中，PTP 域号严格限制在 24 到 43（含 24 和 43）的范围内。限制域号范围可以避免与其他 PTP 配置文件或通用网络发生冲突，从而确保电信同步域的隔离性和可管理性

【G.8275.2 (部分路径授时支持)】

设计初衷：针对无法保证全网节点都支持 PTP 的现有 IP 传输网。
特点：允许 PTP 同步路径穿越非 PTP 设备。同步在 PTP 感知节点间保持，非 PTP 节点仅负责标准 IP 转发。这种方法显著提高了部署灵活性，并减少了对整个网络基础设施进行升级的需求。
机制：域号范围为 44 到 63 ；通常采用单播协商（Unicast Negotiation）机制，从设备主动向主设备发起连接请求，以提高复杂 IP 网络中的可控性。
PTP消息和通信机制：ITU-T G.8275.2 支持单播和组播 PTP 消息传输机制。在实际的电信传输网络部署中，由于该标准是为 IP 网络环境设计的，而 IP 网络环境无法在所有节点上提供完整的 PTP 感知，因此通常采用单播协商来提高可扩展性和流量可控性。

关键参数对比表

配置文件	时钟类型	通信方式	延迟测量机制	同步精度	典型应用
IEEE 1588v2	Master / Slave	单播 / 组播	E2E / P2P	亚毫秒级	企业局域网、数据中心
G.8275.1	T-GM, T-BC, T-TSC	二层以太网	E2E	纳秒级	5G 基站、运营商核心网
G.8275.2	T-GM, T-BC-P, T-TSC-P	单播	E2E	纳秒级	异构 IP 传输网
AES67	Master / Slave	单播 / 组播	E2E	亚毫秒级	IP 音频广播、录音棚
SMPTE-2059-2	Master / Slave	单播 / 组播	P2P	亚微秒级	ST 2110 视频制作、转播车

5. 星融元（Asterfusion）设备支持的 PTP 特性

星融元交换机旨在弥合复杂协议与实际部署之间的鸿沟，其核心优势包括：

灵活的时钟角色：全面支持 BC 或 TC 配置，适配各种多跳网络拓扑
广泛的配置文件兼容性：深度集成 G.8275.1、G.8275.2、SMPTE 2059-2 等主流配置文件
高精度标准：授时精度达到 Class A/C 级（最高亚微秒级时间精度）
全场景部署：PTP模块内置高稳定度的恒温晶振（OCXO），提供稳定的本地频率参考和SyncE频率同步能力，从企业园区到高性能数据中心，均提供稳健的 PTP 时间同步功能支持

CX-M系列云化园区交换机：构建新一代精简高效的云化园区网络

请个“龙虾”当网管：星融元ET2500上的OpenClaw进化实录

关注星融元

手头这台 Asterfusion ET2500 开放智能网关，硬件规格堪称“西装暴徒”。

内置 Marvell OCTEONTX 高性能 ARM64 处理器，十几个千兆/万兆以太网口一字排开。在 Linux 系统的加持下，它理论上拥有无限的定制空间。

但现实往往是：功能越强大，折腾的门槛就越高。

想加个透明代理？依赖冲突能让你配到深夜；想跑个 IDS（入侵检测）看流量？交叉编译和规则适配的“坑”能填满整个控制台……

直到我在这台机器上“孵化”了 OpenClaw。

深度进化：从“手动挡”到“自动驾驶”

起初我以为 OpenClaw 只是个套壳的聊天机器人，直到我开始尝试让这只“龙虾”接管复杂的部署任务。

实战一：十分钟搞定代理网关

我想在 ET2500 上部署 Squid 代理，实现内网流量的统一出口。原本这涉及 apt 依赖补齐、手动编辑 squid.conf、调试访问控制及配置防火墙转发。后来我只说了一句：“帮我装个 Squid，监听特定端口，允许内网指定网段访问。” 龙虾自动识别了 Debian 12 ARM64 环境，修正了语法，甚至顺手开启了缓存压缩优化。十分钟后，一份比我手动写得还规整的配置清单直接呈现在面前。

实战二：攻克 Snort 3 “编译玄学”

在 ARM64 架构上从源码编译 Snort 3 是极客的噩梦。我下达指令：“安装 Snort 3，适配最新社区规则。” 接下来是整场演出的高潮：

OpenClaw 自动转入源码编译，发现缺少 DAQ3 库后果断停下，自行下载源码并重新编译安装，更新库链接后再次回到 Snort 3 编译主线。整整半个小时的排错逻辑，我没有动一次键盘。

ET2500 与 OpenClaw 的结合，堪称底层算力与高阶逻辑的天作之合。强大的硬件执行力确保了任务的下限，而 AI 的介入则拉高了网关能力的上限。它让 ET2500 告别了繁琐的命令行堆砌，转型为能够胜任复杂出口任务的智能中枢。无论是策略过滤还是实时安全审计，OpenClaw 都能凭借对系统依赖和底层限制的深刻“理解”，驱动硬件自主跨越部署障碍。

在这种模式下，运维不再是反复的调试，而是面向目标的意图交付。

龙虾虽好，胃口不小

众所周知，“龙虾”虽能干，却也是个不折不扣的“Token 吞噬者”。从我监控的阿里云百炼后台数据来看，短短两个部署任务，就几乎耗尽了申请的所有免费额度：

在 Snort 3 的安装过程中，单次请求的平均 Token 量高达 35K。

运行期间我数次遇到模型配额耗尽的警告，虽然任务最终通过自动重试硬扛了过去，但这种“烧钱式”的运维显然不是长久之计。想要实现真正的“龙虾自由”，我们必须挖掘这台设备的另一项核心本领。

当“边缘算力”遇见“智力自由”

这套组合的潜力上限，其实藏在其预留的 M.2 接口：插上一张高性能 AI 算力卡（如 Hailo系列），我们可以将 OpenClaw 的推理逻辑从云端拉回本地，让这只龙虾拥有真正的“本地大脑”

“智力买断”式的免费劳动：彻底告别按 Token 计费的账单。无论是 7×24 小时的深度包检测，还是复杂的系统自动化审计，所有推理都在本地算力卡上完成，真正实现一次投入、永久“免费干活”。
极致隐私与毫秒级自愈：敏感的网络拓扑与流量日志不再需要离境上传。数据主权被完全锁定在 ET2508 内部，同时配合本地模型极低的推理延迟，实现毫秒级的威胁响应与自愈巡检。

硬件是骨架，Linux 是血液，而 OpenClaw 配合本地 AI 算力卡，则是让这台 ET2508 彻底进化为“自主生命体”、实现“智力自由”的终极钥匙。

开放式网络硬件的更多玩法，等你来探索哦。

最佳实践：2000+企业共享办公，构建“不断网、好管控”的园区智网

关注星融元

在企业数字化转型进程中，传统的“围墙式”安全正面临巨大挑战。特别是对于超大规模的科技孵化器或高密办公园区，网络运维往往会陷入碎片化配置、策略不一致、用户体验差以及“黑盒化”运维的泥潭。

今天，我们以某国家级科创大楼真实案例为背景，深度剖析星融元园区智网如何通过技术创新，解决高密多租户场景下的准入难题，这其中的技术关键即为： Asteria Security Engine (ASE 安全认证引擎）。

案例背景：43 层科创大楼里的“高密多租户挑战”

该科技中心大楼总计 43 层，入驻企业超过 2,000 家，支撑着 10,000 多名员工及数万台终端的日常办公。物理架构上，该项目部署了核心/汇聚层交换机、30 余台 PoE 接入交换机以及 550 台无线 AP。

在这种环境下，园区物业和 IT 团队面临三个核心痛点：

极度复杂的逻辑隔离： 2,000 多家初创企业共享一套物理网络，必须确保各企业内网数据互不干扰。
高频流动的漫游需求：员工在不同楼层、会议室间频繁移动，要求网络具备毫秒级的无感切换能力。
访客管理的碎片化：每日大量访客入驻，传统的密码分发模式效率低下，急需高效的自助准入手段，让临时访客快速、自助地接入网络。

挑战一：2k+ 企业如何实现“一企一策”？

传统方案中，每增加一个 VLAN 或修改策略，都需要登录数十台设备手动操作，极易出错且难以实现“同人不同权”。

ASE 解决方案：动态授权与全局编排

星融元 ASE 安全认证引擎并非孤立的服务器，而是深度集成在 Asteria Campus Controller 网络控制平台中。通过统一配置入口，管理员无需逐台登录设备，所有认证规则均在 Web 界面完成并实时同步全网。

身份映射： ASE 通过“用户组”功能，将 2,000+ 入驻企业映射为独立的策略实体，支持一键批量开通业务。

动态 VLAN 下发：利用其核心的动态授权能力，无论入驻企业员工在何处接入（有线或无线），ASE 在识别身份后会通过 RADIUS 协议自动下发“企业专属 VLAN” 。这实现了“网络随人走，权限自动对齐”，确保了严密的二层逻辑隔离。

挑战二：终端如何实现“无感接入和漫游”？

传统方案下，员工在园区内移动时，常因 SSID 切换或认证超时需要重新认证登录，体验极差。

ASE 解决方案：MAC 优先认证/ 状态保持

1. 无感接入：MAC优先/状态保留 (Session Persistence) 机制简言之是优先以 MAC 地址去匹配已有记录完成终端认证。以员工接入为例，只需首次登录成功，ASE 记录到其 MAC 地址、状态及授权属性等信息，后续接入则会转为无感认证；同时系统也可结合终端厂商型号信息验证、漫游异常检测等方式触发告警，及时向管理员提示仿冒接入风险。

无感漫游：在设定的 Session 保持周期内，接入设备会通过 MAB（MAC 地址绕过认证）询问 ASE ，ASE 匹配现有 Session 后直接下发授权。由此，只要是认证通过的员工终端，后续在电梯、会议室跨 AP 移动时，MAC 状态都会自动匹配，无需再次进行802.1x或 Portal 认证，轻松实现毫秒级切换，零丢包的无感漫游体验。

挑战三：海量终端如何“自助式认证入网”？

传统方式下访客接入认证流程繁琐，大型企业园区网络环境依靠 IT 部门手动分发密码不仅低效，还存在安全隐患。

ASE 解决方案：自助式认证与自定义 Portal 页面

为了平衡安全与访客体验，本项目最终采用 802.1x + Portal 的混合认证模式，上文的 MAC 优先机制同样适用于802.1x 和 Portal 方式，用户再次接入时，无需重复输入用户名和密码，即可实现自动入网。

访客端采用Portal方式

访客终端发出接入请求，将重定向到 Portal 界面，通过手机验证码自助接入，并被自动划入隔离的“外网 VLAN”，确保核心生产网的安全。

原理简介：

首次接入时，ASE 在 RADIUS 数据库中检索终端的 MAC 信息终端，未检索到记录则会先被分配到 Guest VLAN，让终端获取仅可访问认证服务器的IP地址。该租约极短，仅供完成登录流程。

待用户完成登录所需步骤，ASE 记录其身份信息并强制终端下线重连，刷新网络授权状态；终端再次连接则触发 MAC 认证，正常分配到访客VLAN和网段，获取长租约IP地址，完成接入。

员工端采用 802.1x 方式

现有方案结合 AP 可支持 WPA 企业级、WPA2 企业级（EAP-TLS）、WPA3 企业级（EAP-TLS）、WPA3-192 企业级（EAP-TLS）等多种高强度的 802.1x 认证，配合上述提及的 MAC 优先/Session 保持技术，后续在电梯、会议室跨 AP 漫游时，MAC 状态自动匹配，无需复杂配置即可获得无缝漫游体验。

原理简介：

ASE 作为决策大脑，会对 AP 发出的接入请求进行双重校验，检查其来源AP的IP地址和共享密钥是否在白名单，而后根据用户组管理预设的策略，校验用户名/密码（PEAP/MSCHAPv2）或客户端证书（EAP-TLS），根据用户身份下发VLAN 编号或 ACL 规则（Filter-ID），AP 接收指令后，将该无线连接实时挂载到对应业务 VLAN。

自定义Portal界面

在 Portal 认证场景下，登录页面往往是访客接入网络的第一印象。ASE（ACC Security Engine）在控制器端提供了直观、灵活的页面定制功能，让“品牌化准入”变得触手可及。

管理员通过 ASE 的“零代码配置”功能（无需编写 HTML/CSS 代码），上传企业 Logo 和欢迎语，快速定制 Portal 页面，实时修改欢迎语与操作说明文字。

基于 OAuth 的 Portal 登录

对于有需求将常见现代化办公软件（如飞书、钉钉等应用）与无线接入集成使用的客户，ASE 安全引擎同样支持基于 OAuth 的 Portal 登录：企业员工也可通过已有第三方办公软件的授权直接完成无线接入，无需输入一套复杂的密码，也能确保企业身份权限的全局一致性。

具体实现流程大体如下：ASE 引导用户重定向至 Portal 登录界面（Logto托管），从第三方平台授权获得终端用户在企业组织中的办公身份，完成认证后开始绑定权限，ASE 下发动态 VLAN 或 Filter-ID，确保不同企业的员工进入各自的企业网络（不同企业之间相互隔离），并匹配到已设定的用户策略，再放行该终端的网络接入。

挑战四：故障排查如何摆脱“黑盒化”？

当用户反馈“连不上网”时，网络管理员以往需要 SSH 登录多台设备翻阅日志，故障定位往往耗时数小时。

ASE 解决方案：全生命周期会话洞察

终端管理视角：相比传统 AAA 系统只告诉你“通不通”的问题，ACC 控制器的统一视图下提供了详尽的终端视角——管理员可以实时掌握清楚掌握每个账户名下挂载了几个终端、分别接入了哪台设备的哪个端口/SSID，每一台终端的上线时间与下线时间以及流量趋势，为安全审计和网络资产规划提供第一手真实数据。

离线原因溯源：管理后台不只显示“离线”，而是精准展示各种下线原因（如认证超时、信号强度低触发踢出、手动强制下线等），让用户状态有迹可循。

进阶能力：API 驱动的物联生态集成

在该案例中，园区物业方利用了 ASE 丰富的 RESTful API，将 ASE 与已有的租户管理系统联动，实现了自动化运维。

API划分为四大模块：用户管理、用户组（角色）管理、网络事件通知以及终端管控。同时，我们为开发人员提供了多编程语言的SDK与代码模板，旨在大幅降低集成门槛，帮助用户快速、高效地完成对接与开发工作。

自动同步：当新企业入驻或员工离职时，物业系统自动调用接口在 ASE 中同步账号状态，无需人工二次干预。

数据可视化呈现：通过 API 实现大楼整网流量展示、在线状态监控及离线原因溯源，可为楼宇的智能化运营提供数据支撑。

立即进入控制器页面 app.cloudswitch.io

如何实现 RoCE 配置的自动同步（基础篇） – DCBX协议

关注星融元

进入AI 时代，为多卡、多节点的大规模集群环境构造高性能的无损网络，除了具备必要的 QoS 配置能力外，设备间配置的自动同步也尤为重要。

DCBX（Data Center Bridging Exchange）协议是实现数据中心网络自动化的关键技术，由此可大大减轻运维工作量，并降低人工配置失误引发网络故障的概率。

DCBX 协议为大规模网络部署场景下设备之间的 RoCE 配置同步打下了技术基础，详细内容我们将在下篇展开介绍。

DCBX 产生背景

在现代大规模、多云互联的数据中心中，网络所负载的流量类型庞杂，其中既有对延迟和丢包极度敏感的关键业务流量（如存储、HPC、实时计算），又有可容忍一定延迟的普通数据流量。

因此我们需要对不同类型的流量设定不同的优先级，以保障关键应用的服务质量，与此相关的无损网络特性功能主要有 PFC、ETS 等。显而易见，若采用传统方式人工逐台配置，效率低下且容易引入配置失误，无法满足现代数据中心运营所需。

PFC（基于优先级的流量控制）：流量的无损传输，能够根据优先级控制流量阻塞，减少数据丢包。

ETS（增强传输选择）：用于管理不同流量的带宽分配和优先级控制，从而实现不同类型流量的服务质量管理。

下图是因为没有端到端开启 PFC 而导致的丢包/拥塞扩散示例：

交换机上出现拥塞，向服务器发送PFC Pause帧
服务器由于未使能 PFC，会继续向交换机发送流量
当交换机 Buffer 占用超限，出现流量丢弃则需要重传，导致了时延显著增加或引发故障

什么是DCBX

DCBX（Data Center Bridging Exchange，数据中心桥接交换）协议是基于 IEEE 802.1Qaz 的链路层协议，通过 LLDP（Link Layer Discovery Protocol，链路层发现协议）的扩展字段进行配置交换，以确保不同设备间的流控、服务质量（QoS）等设置保持一致。对于这些设置，我们在当前语境下统称为”DCB 配置”。

具体而言，DCBX 协议主要提供了以下功能：

发现对端设备的DCB配置信息
更新对端设备的DCB参数到本地
监测设备的DCB配置变化

DCBX 协议信息封装

如前文所述，DCBX 协议基于 LLDP 协议拓展而来，DCB的信息被封装在 LLDP 特定的扩展TLV中（Type,Length,Value）。

DCBX TLV包括 ETS Configuration TLV、ETS Recommendation TLV、PFC Configuration TLV和Application Priority TLV。

DCBX 的工作流程

DCBX 的配置宣告，协商以及更新行为通过状态机实现，DCBX 状态机运行在每个使能了 DCBX 的端口上，默认工作流程如下：

本地配置采集

初始化本地配置、本地能力和本地同步意愿。当对端存在，则进入宣告本地配置状态。

本地配置宣告

宣告本地配置。当检测到对端存在，且本地有意愿同步，则进入对端配置采集状态。

对端配置采集

初始化对端的配置、对端能力、对端同步意愿，并进入本地配置更新状态。

本地配置更新

将对端配置与本地配置进行协商，依据协商结果检查数据库中的配置，若与本地配置不一致，则更新数据库中的配置。

配置变化监测

监测本地与对端配置和存在状态是否发生变化，若发生变化则回到本地配置采集阶段。

典型场景应用示例

我们依旧以 PFC 为例，来结合图示简要了解 DCBX 协议如何在交换机与服务器之间，以及交换机和交换机之间完成参数配置交换。

交换机与服务器

DCBX 协议通过设备间双向的能力发现与配置协商，确保了 DCB 功能的端到端一致性。

服务器与交换机 DCBX 配置交换示意图

交换机配置 PFC 参数并使能 DCBX
服务器使能 DCBX 并配置接收意愿，可选配置 PFC 参数
通过 LLDP 扩展字段完成配置交换

交换机和交换机

交换机与交换机之间通过 DCBX 协议完成配置交换，确保了 DCB 配置在转发链路上的一致性。

交换机之间 DCBX 配置交换示意图

本地交换机配置接口3、4队列使能 PFC，使能 DCBX 并配置接收意愿
对端交换机配置接口6、7队列使能 PFC，使能 DCBX
本地发现对端接口 PFC 配置与本地不一致，将对端 PFC 配置同步到本地

一文看懂ARS（自适应路由切换）：基于 Flowlet 的动态负载均衡技术

智算网络高带宽利用率利器：基于 Flowlet 的自适应动态负载均衡技术

不同负载均衡技术对比

现有主流负载均衡技术大体分为三种，逐流的 ECMP 负载均衡、逐包负载均衡和基于子流（Flowlet）的负载均衡。

逐流负载均衡

传统的 ECMP 路由通常采用逐流负载分担机制，其核心是基于数据包的特征字段（例如 IP 五元组等信息）作为计算因子去进行哈希运算，根据哈希值选择转发链路。

不同的流由于特征字段不同，会生成不同的哈希值，从而分散到不同的链路完成转发，在整网实现一定的负载均衡；
具有相同特征字段的流，经过哈希运算后会分配到同一条转发路径，由此保证了同一条数据流会按序依次到达对端。

随着云计算的发展和智算业务兴起，逐流负载均衡的缺陷愈加凸显。

首先，逐流的负载均衡无法解决流大小不均的问题，当大小流平等、粗放地进行负载均衡的精细度有限，带宽利用率也有所损耗；

其次，它是一种静态的负载均衡机制，无法实时感知链路的负载情况。当网络出现大象流，静态负载均衡机制依旧会按照既定的路由算法去选路，容易进一步加剧拥塞，造成丢包；

尤其是智算集合通信场景下，该机制还极易在 Clos 组网的 Leaf 上行链路出现哈希极化现象，造成网络拥塞。（btw，我们提供一个静态方式来解决这个问题，感兴趣可以参考? 主动规划+自动化配置工具，简单应对AI智算网络 ECMP 负载不均）

逐包负载均衡

逐包的负载均衡技术则是将数据包均匀地负载到各条链路上，又被形象地称为“数据包喷洒”（Packet Spray）。

逐包负载均衡通常提供 Random 和 Round Robin 两种算法，Random 算法将数据包随机分散到各条链路上；Round Robin 算法能够将数据包逐一等量的分散到各条链路，理论上均衡度最好。

但由于实际组网中不同链路的负载情况和转发时延不一样，逐包负载均衡无法保证报文依照原有时序到达接收端，故其整体性能依赖于端侧的缓存容量和乱序重组能力。

基于子流（Flowlet）的负载均衡

不同于传统负载均衡的逐流负载分担或逐包负载分担，基于子流的负载均衡不光是对数据流进行分割以实现更精细均匀的负载分担，而且保持了报文到达的时序性。

当前星融元 RoCE 交换机所支持的 ARS（Adaptive Routing and Switching，自适应路由切换）即是一种基于子流的负载均衡技术；同时这也是一种动态的负载均衡，其利用了 ASIC 提供的硬件 ALB（Auto-Load-Balancing）能力通过实时感知链路状态，主动调整选路改善拥塞状况，并提高整体的带宽利用率。

接下来我们将从下面三个问题出发，帮助读者理解该机制的运行原理。

如何分割大流？
动态选路机制和链路的测量指标是什么？
何时触发路径的主动分配/重分配？

术语解释

ARS技术中有以下几个关键概念：

微观流（Micro Flow）：五元组相同的一组数据
宏观流（Macro Flow）：哈希值相同的微观流的集合
空闲时间（Idle Time）：宏观流中一段没有流量的时间（可配置的参数）
子流（Flowlet）：指宏观流中被空闲时间分割的一组连续数据包

流分割：从 Flow 到 Flowlet

Flowlet（子流）是 ARS 技术对流进行负载均衡的基本单位。

如上图所示，一系列拥有相同五元组微观流（Micro Flow 1/2/3…）会进入到网络中，我们采用 IP 五元组作为哈希因子对所有微观流进行哈希计算，哈希值相同的一系列微观流组成一条宏观流。

宏观流中，当两条微观流之间相隔的时间T大于配置的空闲时间（Idle Time）会触发流分割，将宏观流分割为子流（Flowlet）：以时间 T 为界，前后两个微观流从属于两个不同的子流。

显然，Flowlet 会包含拥有不同 IP 五元组信息的数据包（不同的微观流），从业务层面来看，传统意义上的“大象流”会被打散，而小流则有可能合并到一个 Flowlet 里传输。

动态选路机制和测量指标？

ASIC 负责维护一个宏观流表 (Macro Flow Table)，其中记录了各宏观流和其对应的出接口（或 ECMP 链路成员）信息。

通过实时测量不同端口上负载和时延，ARS 技术可以将宏观流以 Flowlet 的颗粒度路由到当前更优的链路上。

至于我们如何得知当前哪条链路更优呢？这里就涉及到链路质量指标的测量问题。

链路指标的测量由控制平面和ASIC共同完成，在星融元的方案中，我们关心的指标有端口带宽、端口利用率、转发时延，上述三个指标共同决定了端口所在链路于t时刻的质量情况。

端口带宽

对于启用了 ARS 功能的端口，控制平面会对其线速速率进行归一化，并将配置下发给 ASIC 备用，基础速率为10G。

端口利用率

端口带宽利用率通过端口实时流量速率反映。ASIC 对端口上的流量速率进行采样后，通过与端口线速速率进行比较得出端口带宽利用率，并计算端口平均负载。

转发时延

端口所在链路转发时延通过该端口的队列深度反映，ASIC 对端口队列深度进行采样后计算其历史负载情况。

对于参与了 ARS 的端口，ECMP 组会实时计算更新各出接口的链路质量情况，并在路径动态分配时根据最近一次的结果择优转发流量。

何时进行路径主动分配？

路径主动分配发生在流分割过程中的末尾，结合上述的路径指标完成最终路由决策。

我们可以假设这样一个场景：当 Flowlet 1 的最后一条微观流 Micro Flow 2 被分配到路径 D 并间隔时间 T（T>Idle Time）后，另一条微观流 Micro Flow 3 此时待处理。

由于 T>Idle Time，此时 ASIC 认为 Flowlet 1 已结束，到路径D的映射到期。

此后的微观流 Micro Flow 3 从属于一条新的子流，且处于非活跃状态，于是触发一次主动路径分配。

流分割的关键参数 Idle Time 的合理配置值跟全局路径级时延信息高度相关，通常会配置为不小于 1/2 RTT。

这是因为转发设备的接收队列缓冲区会实时变化，即使发送端的报文发送间隔恒定，转发设备上处理报文并进行转发时，间隔也会发生变化。配置过小会导致分割出来的 Flowlet 粒度过细从而引发乱序，过大则无法将宏观流进行有效分割，引发拥塞。

典型应用举例

如上图，以 128 台 8 卡 GPU 服务器（共计 1024 个 400G 网卡）规模为例，AIDC 承载网采用两层 Clos 网络架构。Spine 和 Leaf 设备均选择星融元 CX864E-N 交换机，并按照下行端口与上行端口1:1的收敛比设计组网。在保证网络高吞吐、高带宽的基础上，1:1 的带宽收敛比能够避免因为带宽不对称导致的性能问题。

点击链接 ➡️ 64 x 800G 51.2T RoCE交换机

假设 Server1 的 GPU1 要与 Server65 的 GPU1 通信，按照传统负载均衡的逻辑，流量会选择 Spine 中的一个然后到达 Leaf9。由于传统负载均衡不会感知路径实时状态，所以 AI 场景下的少量大象流极易被均衡到同一 Spine 上从而导致 Leaf1 上行端口拥塞甚至出现丢包。

当在星融元 CX864E-N 交换机启用 ARS 技术，则 ASIC 将能根据转发时延和端口实时负载对流量出接口进行调整。

假设 Leaf1 通往 Spine4 的链路上发生拥塞，则 Leaf1 的 ASIC 会将更少的 Flowlet 路由到 Spine4 或跳过 Spine4，直至该链路上的拥塞情况缓解后，才会恢复选中该链路进行流量转发。

由此各设备通过完成自治达到降低整网链路拥塞情况并提高带宽利用率。

参考文档
[1] OCPSummit2022- Adaptive Routing in AI/ML Workloads https://www.youtube.com/watch?v=cgYOpp4xwQ8
[2] https://infohub.delltechnologies.com/zh-cn/l/dell-enterprise-sonic-quality-of-service-qos/adaptive-routing-and-switching/
[3] https://asterfusion.com/a20250528-flowlet-alb/

星融元(Asterfusion)

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

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

基于RoCEv2构建媲美InfiniBand的低时延无损以太网实践指南

分布式存储网络方案的封面图

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

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

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

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

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

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

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

对比维度	传统集中式存储	分布式存储
架构本质	紧耦合硬件（控制器+硬盘柜）	松耦合软件定义（标准服务+存储软件）
硬件组成	专用存储控制器、硬盘柜	标准化服务器+本地硬盘
扩展模式	纵向扩展为主（Scale-Up）	横向扩展为主（Scale-Out）
扩展能力	受限于控制器性能，容量/性能有上限	节点可扩展至数千，容量达PB/FB级
性能特点	低延迟、高IOPS	高吞吐、高并发读写能力
数据保护机制	双控制器、BBU/UPS、双活、容灾	多副本、纠删码（EC）、灵活策略
适用场景	核心数据库（金融、医疗等）	海量非结构化数据、云原生、大数据
成本与敏捷性	专用硬件成本高，部署复杂	标准化硬件成本低，IT敏捷性高
瓶颈点	存储机头（控制器）	网络延迟（I/O路径较长）

分布式存储网络的搭建

网络协议的选择

为了解决分布式存储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媲美的性能和无损网络
超低时延提高业务并发量，加快数据传输速度，提升业务响应效率，抢占市场先机
更低的技术门槛和运维成本，可以在传统以太网上实现超低时延、零丢包、高性能的网络传输

相关文档：分布式存储网络解决方案

产品型号： 星融元（Asterfusion）CX664D-N（64 x 200G QSFP56/QSFP28/QSFP+）
功能特性：RoCEv2, PFC, ECN, DCBX ……

应用场景：分布式存储，数据中心，GPU算力集群……
最后更新：2026-05-26

星融元(Asterfusion)

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

园区智网

网络操作系统（SONiC）

网络可视化（NPB）

开放硬件平台

标签： 技术分享

手动配置难以为继

网卡参数配置工具 EasyRoCE-NC

实现原理

安装步骤概览与效果

环境和工具准备

1、服务器要求

2、数据源

3、NIC Configurator (NC)工具包

安装NC工具

最终效果

重新定义企业 AI 流量工作流

替代传统 L7 DPI：精准识别加密 AI 流量

场景一：基于部门的精细化合规隔离（GeoSite + 状态 ACL）

1. 核心财务/数据部门

2. 研发/设计部门

场景二：保障出海专线体验与大模型下载限速（HQoS 流量调度）

1. 基础映射

2. 调度配置

软硬协同: AsterNOS-VPP 构建新一代智能企业边界网关

关注星融元

PTP 配置文件分类

1. 通用配置文件 (General Purpose Profile)

2. 媒体配置文件 (Media Profile)

3. 电信配置文件 (Telecom Profile)

PTP 配置文件详解

1. 通用配置文件：IEEE 1588v2

2. 媒体配置文件：AES67 与 SMPTE-2059-2

3. 电信配置文件：G.8275.1 与 G.8275.2

关键参数对比表

5. 星融元（Asterfusion）设备支持的 PTP 特性

关注星融元

深度进化：从“手动挡”到“自动驾驶”

实战一：十分钟搞定代理网关

实战二：攻克 Snort 3 “编译玄学”

龙虾虽好，胃口不小

当“边缘算力”遇见“智力自由”

关注星融元

案例背景：43 层科创大楼里的“高密多租户挑战”

挑战一：2k+ 企业如何实现“一企一策”？

挑战二：终端如何实现“无感接入和漫游”？

挑战三：海量终端如何“自助式认证入网”？

访客端采用Portal方式

员工端采用 802.1x 方式

自定义Portal界面

基于 OAuth 的 Portal 登录

挑战四：故障排查如何摆脱“黑盒化”？

进阶能力：API 驱动的物联生态集成

关注星融元

DCBX 产生背景

什么是DCBX

DCBX 协议信息封装

DCBX 的工作流程

本地配置采集

本地配置宣告

本地配置更新

配置变化监测

典型场景应用示例

交换机与服务器

交换机和交换机

不同负载均衡技术对比

逐流负载均衡

逐包负载均衡

基于子流（Flowlet）的负载均衡

术语解释

流分割：从 Flow 到 Flowlet

动态选路机制和测量指标？

端口带宽

端口利用率

转发时延

何时进行路径主动分配？

典型应用举例

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

分布式存储网络的搭建

网络协议的选择

组网架构

标签：技术分享