客户端/服务器（C/S）架构的运作流程

RADIUS 采用典型的 C/S 架构，其工作逻辑可分为四个关键步骤：

1. 发起连接：用户在需要接入的网络设备（如Wi-Fi）上输入用户名和密码。

2. 客户端转发请求：网络接入设备（NAS），例如无线控制器、交换机等，作为RADIUS的客户端，将用户的认证信息打包成”认证请求包”发送给RADIUS服务器。（这一步中，用户密码会经过加密处理）

3. 服务器核验身份：RADIUS服务器接收到请求后，会检查用户信息是否与自己的数据库匹配。

• 认证成功：如果信息正确，服务器会返回”认证接受包”。这个包里不仅包含”允许接入”的指令，还会附带用户的授权信息（如网络权限），RADIUS将认证和授权合并为一步。
• 认证失败：如果信息错误，服务器返回”认证拒绝包”，拒绝用户接入。

4. 执行授权与计费：RADIUS客户端（NAS）根据服务器返回的指令执行操作，允许或拒绝用户。如果允许接入，客户端还会向服务器发送”计费开始请求”，服务器确认后开始记录。当用户断开连接时，计费停止。

核心应用场景：企业级 Wi-Fi 与 802.1X

在现代办公环境中，RADIUS 配合 802.1X 认证框架实现了精细化的权限管理 。这种方案不再依赖单一的共享密钥，而是让每个用户拥有独立的账号。
无线接入中的三个关键角色

• 申请者（Supplicant）： 员工的笔记本或手机，需运行支持 802.1X 的客户端。
• 认证者（Authenticator）： 通常指无线接入点（AP），在通过验证前拦截访问请求并转发身份信息。
• 认证服务器（Authentication Server）： 即 RADIUS 服务器，负责核实凭证并告知 AP 是否放行。

此外，RADIUS 还常用于双因素认证（MFA）场景，为企业网络额外增加一道锁。

核心应用场景：双因素认证（MFA）

在传统的认证中，RADIUS 仅核对“用户名 + 密码”。但在 MFA 场景下，RADIUS 协议被扩展用于处理多阶段验证。

企业 VPN 远程接入安全

这是 RADIUS MFA 最广泛的应用。

• 现状：仅靠静态密码极易被暴力破解或因员工泄露而失守。
• 解决方案：VPN 网关作为 RADIUS 客户端 ，将认证请求转发给集成了 MFA 插件的 RADIUS 服务器。只有当员工在手机 App 上点击“允许”后，VPN 隧道才能成功建立。

关键基础设施的 SSH 登录

对于核心服务器或交换机的管理，企业通常配置 RADIUS 认证以替代本地账户。

• 精细控制：通过 RADIUS 授权功能，可以决定该用户登录后是具备“只读”权限还是“管理员”权限。
• 安全加固：强制要求在输入密码后进行动态令牌校验，防止运维账号被盗导致的大规模内网渗透。

未来网络安全的基石

无论是简单的 Wi-Fi 接入还是复杂的跨区域 VPN 办公，RADIUS 凭借其成熟的 AAA 机制和高效的接入认证流程，始终是构建安全、透明、可审计的网络准入环境的基石。

• CX-M系列云化园区交换机：构建新一代精简高效的
• 云化园区网络
• 云化园区无线接入点：新一代云化园区网络无线控制器

关注星融元

在数字化转型的浪潮中，企业网络边界正在迅速扩张 。随着光纤宽带向 10G、25G 甚至 100G 演进，网络工程师面临着一个棘手的挑战：如何在开放网络架构下，实现与带宽能力相匹配的安全加密性能 ？

面对海量加密流量时，传统的软件路由方案往往力不从心 。今天我们将深入探讨这一性能瓶颈背后的技术逻辑，剖析 AsterNOS 如何利用 VPP（矢量报文处理）与硬件卸载技术打破性能天花板。

技术基础：IPsec 如何工作？

要理解性能瓶颈的根源，首先需要深度理解 IPsec 的运行机制 。

什么是 IPsec？

IPsec（互联网协议安全）并非单一协议，而是由 IETF 定义的一套开放的网络层安全框架协议族 。它主要由三个核心组件构成：

• AH（Authentication Header，认证报文头）：提供数据源认证和完整性校验，确保报文未被篡改，但不提供加密功能
• ESP（Encapsulating Security Payload，封装安全载荷）：提供加密、认证和完整性校验 。由于涉及数据载荷加密，这是 VPN 中最耗费性能的部分
• IKE（Internet Key Exchange，因特网密钥交换）：用于自动协商密钥并建立安全联盟（Security Association，SA）

典型场景：企业分支机构互联

假设总部网络（192.168.1.0/24）需要与分支网络（10.1.1.0/24）通信 。

通过在两端网关配置 IPsec，我们可以在不可信的公共网络（互联网）上建立虚拟加密隧道：所有流经该隧道的报文在离开网关前会自动加密，并在进入对方网关时解密，这一过程对终端用户是透明的 。

IPsec 运行在 OSI 模型的网络层（第 3 层），其典型的处理流程如下：

• 流量引导（兴趣流匹配）：网络设备接收到报文后，将报文的五元组等信息和IPsec策略进行匹配来判断报文是否要通过IPsec隧道传输
• IKE 协商（控制面）：双方建立安全通道，协商具体的密钥和算法
• 数据传输（数据面）：发送方使用 SA 对原始 IP 报文进行 ESP 封装（加密载荷并添加首部），接收方则进行解密并校验 ICV（完整性校验值）

为什么传统软件路由在 10 Gbps+ 环境下会失效？

在传统网络架构中，通用 CPU（x86/ARM）是核心处理单元 。虽然 CPU 擅长处理复杂的控制逻辑，但在处理计算密集型的 ESP 封装任务时却有先天劣势 ：

• 计算压力：通过接口的每一个数据包都需要进行高强度的数学运算（AES 加解密）和 SHA 哈希校验
• 上下文切换开销：在 10Gbps+ 的高并发流量下，海量报文会导致频繁的 CPU 中断和上下文切换，消耗大量计算资源
• 控制平面的不稳定性：当 CPU 被加密任务占满时，路由协议（如 BGP/OSPF）的存活报文可能无法及时处理，导致网络震荡

这种“用通用计算处理专用任务”的失配，会导致吞吐量大幅下降，延迟剧增 。

解决方案：VPP 矢量处理与硬件卸载加速

长期以来，企业在规划安全网关时常陷入两难：是选择灵活性高但性能有限的通用软件路由，还是选择性能强大但封闭昂贵的专用硬件 ？

星融元通过异构计算架构给出了第三种答案。通过深度融合 VPP 的矢量软件效率与 DPDK 硬件卸载的确定性算力，AsterNOS 成功解耦了控制面与数据面 ：不仅让通用硬件焕发出媲美专用 ASIC 的线速加密能力，还保留了 SONiC 云原生生态的开放性与可编程性 —— 步入 10Gbps+ 互联时代的企业无需再为加密支付昂贵的“性能税” 。

相关硬件参阅：

• 新机发布 | ET3600 系列开放智能网关平台
• 深度拆解 | ET2500 系列开放智能网关平台

第一重进化：软件架构革新

即便没有专用硬件加速卡，AsterNOS 的运行速度也优于传统路由 。

传统的 Linux IPsec 处理采用“逐包中断”模式，效率极低 。相比之下，AsterNOS 基于 VPP（矢量报文处理）架构，采用“批处理”模式处理报文 。

这类似于公交车（一次运输数十人）与出租车（一次仅运输一人）之间的效率差异 。这使得 AsterNOS 仅依靠通用 CPU 就能实现远超传统 Linux 内核的 IPsec 处理性能 。

第二重进化：释放硬件潜能（硬件卸载）

当带宽需求上升到 10G/25G+ 线速时，我们引入了 IPsec 硬件卸载 ，借助专用的加密引擎（Crypto Engine），将繁重的数学运算从 CPU 中完全剥离 。CPU 仅负责“下达指令”，而硬件负责“暴力计算” 。

• 控制面（SONiC 容器化管理）：采用数据库驱动模式 。用户配置意图先写入配置数据库（Config_DB），经由智能管理进程（ipsecmgrd）校验转换后，下发至底层的硬件抽象层数据库（ASIC_DB）
• IKE 服务：负责密钥协商的进程运行在通用 CPU 上，处理身份认证和密钥交换逻辑；协商完成后，将生成的安全联盟（SA）推送到数据面
• 数据面路径 A（VPP 软件加速）：在普通服务器上，VPP 利用矢量批处理技术，确保核心处理代码始终驻留在 CPU 的 L1 指令缓存（I-cache）中 。它完全在用户态处理 ESP 封装和解密，避免了传统内核频繁读取内存带来的延迟
• 数据面路径 B（DPDK 零拷贝硬件卸载）：这是性能飞跃的关键 。VPP 通过 DPDK Cryptodev 接口直接与底层硬件加速单元（Crypto VF）通信 。数据包在硬件引擎中直接完成读取、加解密及 ICV 计算，无需在内存中反复拷贝，随后直接发往物理接口

同时，AsterNOS 采用了符合云原生网络理念的虚拟隧道接口（VTI）架构 ，IPsec 隧道被视为标准的逻辑 3 层接口 ，流量进入隧道的逻辑由路由表控制，简化了复杂的策略配置。

带来的收益

实验室测试数据表明，该架构具有显著优势：

• 软件定义的灵活性：即便在无硬件加速卡的设备上，AsterNOS 也能凭借 VPP 架构提供优秀的性能基线，满足多数中小企业的 VPN 需求
• 接近线速的吞吐量：在 4x10GE 的物理网络环境下，AsterNOS 在 512 字节包长下轻松实现了 35.2 Gbps 的聚合加密吞吐量 ，该数值已达到物理接口的带宽极限（而非加密引擎的极限）
• 极低的 CPU 占用率：由于繁重的计算已卸载到专用引擎之上，CPU 可专注于业务逻辑和策略控制，不再成为瓶颈
• 广泛的算法兼容性：全面支持高效的 AES-GCM (128/192/256) 算法，并兼容 AES-CBC/CTR 。支持高达 MODP-8192 和 ECP-521 的 DH 组，满足金融级安全合规要求

gRPC的背景

由于GPU、HPC等这类业务容易出现微突发的现象，运维人员需要快速检测到微突发的情况并且进行定位、调整。而传统的CLI、SNMP等网管手段不能很好满足自动化运维需求，这时需要有一种技术在不影响设备的性能和功能的情况下实现更高精度的数据监控。通过INT技术可以实现流量端到端转发路径的可视化，但无法对交换机的Buffer进行更全面的管理，包括出、入端口/队列缓存等实时监控。

什么是gRPC？

gRPC（Google Remote Procedure Call） 是一个高性能、开源且与语言无关的远程过程调用（RPC）框架，最初由 Google 开发并基于 HTTP/2作为传输协议、Protocol Buffers（protobuf） 作为接口描述语言（IDL）和消息交换格式。若是采用基于gRPC + Protocol Buffers的运维接口设计，可以很好地满足运维对单个网络网元全面的可视化和实时性要求。解决了传统 SNMP 协议“跑不快、看不清、管不了”的痛点。

传统的 SNMP 采用“轮询（Pull）”模式，网管系统就像个查水表的，每间隔5分钟就去敲一次交换机的门“请问1号端口流量是多少？”。如果交换机正在忙，或者监控的项目太多，这种方式会导致数据不准且响应滞后。

在现代网络操作系统（如 SONiC）中，gPRC在网络监控中的应用（gRPC Telemetry）采用“推送（Push）”模式。可以实现毫秒级的数据采集，交换机能主动推送结构化数据，极大地降低了 CPU 占用。

gRPC的交互方式

• 一次订阅，持续推送： 监控服务器只要向交换机发送一次订阅请求，交换机就会按照预设的时间间隔（比如每 100 毫秒）或在状态发生变化时，主动把数据塞给服务器。
• 极高的精细度： SNMP 很难做到秒级监控，而 gRPC 可以轻松实现毫秒级。这让你能捕捉到所谓的“微突发（Micro-burst）”流量，这在金融交易或高性能计算场景中至关重要。

交换机在开启gRPC功能后充当gRPC客户端的角色，采集服务器充当gRPC服务器角色；交换机会根据订阅的事件构建对应数据的格式（GPB/JSON），通过Protocol Buffers进行编写proto文件，交换机与服务器建立gRPC通道，通过gRPC协议向服务器发送请求消息；服务器收到请求消息后，会通过Protocol Buffers解译proto文件，还原出最先定义好格式的数据结构，进行业务处理；数据梳理完后，服务器需要使用Protocol Buffers重编译应答数据，通过gRPC协议向交换机发送应答消息；交换机收到应答消息后，结束本次的gRPC交互。

上图展示的是gRPC交互过程的具体流程，也是Telemetry触发方式其中之一，称为Dial-out模式。

gRPC的工作原理

gRPC Telemetry 之所以快且准，是因为它解决了“语言不通”的问题。

1、Protobuf（数据压缩）

传统的网络管理数据（如 JSON 或 XML）包含大量冗余的标签。Protobuf 将数据转换为二进制流，体积通常只有 JSON 的 20%-50%。
通过 .proto 文件定义数据结构，交换机和控制器在“对话”前已经知道了数据的格式，解析速度非常快。

2、HTTP/2

gRPC 跑在 HTTP/2 之上，带来了几个关键特性，第一个多路复用，在同一个 TCP 连接上同时发送多个请求和响应，不再需要排队。第二双向流，交换机可以保持一个长连接，实时将接口流量、温度等数据源源不断地推送到监控平台。

3、交互流程

使用 YANG 模型（IDL）定义网络功能，并转换为 .proto 文件，服务器端运行gRPC Server，监听特定端口。客户端发起连接，订阅特定的数据路径（如/interfaces/interface/state/counters），交换机根据配置，一旦数据发生变化或达到时间间隔，立即封装成Portobuf并通过HTTP/2推送给客户端。

YANG 模型（数据建模） 它是网络设备的“说明书”。它规定了数据的层级结构（例如：接口名称 > 状态 > 输入字节数）。有了 YANG，开发者不再需要去查晦涩的 MIB 库。

SNMP vs gRPC（Telemetry）

gRPC 与 YANG 模型驱动的自动化基石

在拥有数万节点、承载秒级万亿次请求的超大规模数据中心内，网络的容错空间几乎为零。面对万兆乃至 800G 的极速网络环境，传统 SNMP 协议频繁的请求/响应开销已成为交换机 CPU 不堪重负的枷锁。

gRPC 的引入彻底重构了监控范式：它依托 Protobuf 极高压缩率的二进制序列化技术，结合 HTTP/2 的多路复用能力，将网络遥测（Telemetry）的系统损耗降至微秒级，确保交换机算力能全量聚焦于线速转发。然而，单纯的“快”并不够，YANG 模型 为这些海量数据赋予了标准化的“灵魂”。只有当采集频率跨入毫秒级，且数据通过 YANG 实现高度结构化的语义定义时，自动化编排引擎才能在瞬息之间精准识别微突发拥塞，并在几毫秒内下发动态策略调整路由。

这种“高性能传输 + 标准化建模语言”的组合，不仅是效率的飞跃，更是实现自愈网络（Self-healing Network）的技术底座。

什么是IPT（In-band Path Telemetry）？

IPT是 In-band Path Telemetry 的缩写，中文译为 “带内路径遥测”。IPT是INT技术的标准方案之一，也是实现网络数据平面可观测性的一种核心技术。要理解“带内”，首先要对比“带外”；

• 带外遥测：网络设备（如交换机、路由器）会定期、主动地收集自身的性能数据（如端口计数、CPU负载），并通过独立的管理通道（如SNMP、gRPC）上报给控制平面或网管系统。数据流和业务报文是分离的。
• 带内遥测：业务报文本身在转发过程中，会“携带”其流经路径的网络状态信息。这些信息被直接写入数据包内部，并随数据包一同被传送到目的地或指定的收集点。

所以，IPT的核心思想就是，将网络测量任务从网管设备（带外）下放到数据报文（带内）本身。让数据包在穿越网络时，像“侦探”一样，沿途自动收集每一跳设备的实时状态信息，并将这些证据（遥测数据）封装在自己体内，最终送达分析端。

IPT的技术实现

在现有报文格式（如以太网帧、IPv4/IPv6包）中插入一个INT头部和一系列INT指令，预留出空间来存放待收集的数据。需要支持INT的设备（称为“INT节点”或“Telemetry Node”）在转发该报文时，会识别INT指令，并根据指令要求，将本地的特定信息（如交换机ID、入口/出口端口、时间戳、队列深度、链路利用率等）写入报文预留的INT数据区。所有信息都在数据内部添加和传输，不需要再为遥测单独建立通道或额外发送探测报文。

IPT 报文格式

如图，IPT报文由多层头部构成，包含L2/L3封装、GRE头部、IPT Shim头部、探针标记及各节点统计信息等字段。

IPT工作流程

IPT通过入口节点生成探测包、传输节点收集信息、出口节点封装报文发送的整理流程图，实现端到端路径信息采集。探测数据包为原始数据包的克隆（payload截断），沿与原始包相同路径传输，并在各个节点插入统计信息，最终发送至用户配置的收集器。

IPT能做什么呢？

IPT提供了一种高实时性、与业务流完全同步的网络路径状态的洞察能力。

精准的故障与性能问题定位

传统定位故障问题的方法：网络管理员收到告警（如“服务器A到B延迟高”），需要逐跳登录设备、查看计数器、抓包分析，耗时长，难以定位到具体哪一跳、哪个端口、哪个队列出了问题。

IPT可以直接从出问题的数据流本身的INT报告中，就能看到整条路径上每一跳的详细信息。举个例子：通过报告可以发现“在交换机3的出口端口Ethernet1/1/1上，队列2的排队延迟突增了50ms”，这样就实现秒级甚至亚秒级的根因定位。

网络性能可视化与基线建立

持续收集关键业务流的路径数据，可以绘制出网络性能的精细图谱，实现端到端性能的可视化，包括逐跳的延迟、抖动、丢包、拥塞点等。基于这些真实数据建立性能基线，任何偏离基线的异常都可以被快速检测出来，辅助运维决策。

自动化与智能运维

为SDN控制器、网络分析器或AIOps平台提供高质量、实时、关联性极强的输入数据，可用于训练AI模型。使得网络能够实现基于真实流量状态的动态优化，如自动重路由（将受拥塞影响的流量切换到其他路径）、主动缓存调整、容量规划等。

服务等级协议保障与验证

对于云服务商或企业，可以针对VIP客户或关键应用（如视频会议、金融交易）的流量启用IPT。直接验证从源头到目的地的SLA指标（如端到端延迟、丢包率）是否达标，并提供无法抵赖的、逐跳的证据。

典型应用场景 – 端到端路径时延监控

在某超千卡GPU集群的大规模训练场景中，All-Reduce等集合通信操作对网络时延极度敏感，其完成速度取决于最慢的路径。传统监控手段难以精准定位网络链路中的隐患。IPT技术通过实现纳秒级精度的端到端路径时延透视，为解决此问题提供了根本性方案。

端到端路径时延监控

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

通过IPT实现的端到端路径时延监控，将网络从“黑盒”变为“白盒”，把训练效率的瓶颈定位从“猜测GPU或软件问题”精确到“证实并定位网络硬件或微突发流量问题”，从而将小时级甚至天级的故障排查过程缩短至分钟级，有效保障了万卡集群的算力高效、稳定输出。

关注星融元

基于 RoCEv2 的 RDMA 网络已经在 AI 训练、推理、NVMe-oF 存储、高性能数据库等场景中大规模落地。

然而实际运维中，RDMA 层级的通信尚处于“黑盒”状态——业务侧工程师看不到RDMA 通信在网络中的真实路径。当出现推理速度下降、链路突发拥塞、尾部时延偏高等问题，定位问题的成本极高。

现有的RDMA通信观测方式

从协议栈视角看，一条 RDMA 连接大致包含以下几个维度的信息：

• 源/目的 IP、端口
• QP（Queue Pair）：源QPN、目的QPN
• 连接管理（CM，Communication Manager）
• 通信ID（Communication ID，CID）
• 会话建立与断开阶段的交互报文

目前的端侧工具只能看到 IP 地址、QPN 等离散的信息，而 RDMA 通信会话的状态、网络转发路径是无法获悉的；现有的交换机上的观测手段也有其局限性，存在较大提升空间，例如：

• 设备/端口 DEBUG：通过交换机的端口计数器、PFC/ECN 统计，只能看到“哪个端口有问题”，看不到“哪条 RDMA 连接经过这里”
• 抓包/镜像：ERSPAN 等方式导出大量流量，依赖手工分析复杂
• 高级硬件特性：基于 INT 或自定义 Telemetry 的方案，需要底层芯片支持和现网改造，成本和落地难度相对较高

在这样的背景下，星融元推出的EasyRoCE Toolkit 新增了一款 RMDA可视化工具链——RST（RDMA Session Tracer，RDMA会话追踪和路径还原），为用户提供了一种轻量且无侵入的观测手段，辅助网络工程师完成 RDMA 网络运维的优化决策。

EasyRoCE – RST 工具

在EasyRoCE-RST工具的 1.0 版本，我们主要观察RDMA通信的关键点——建连阶段的控制面交互报文：CM 报文。

通过获取 CM 报文携带的 QPN、CID 等关键信息,从中解析构建出 RDMA 会话的生命周期，并将其关联到具体的交换设备和端口，最终通过多设备之间的 CID 和时间序列关联，还原出 RDMA 完整的通信路径。

CM协议（Communication Management Protocol，通信管理协议），在本文语境下指的是一种建立于 Infiniband/RoCE 协议基础之上的建链方式，它有一套专属的报文格式、交互流程和用户接口。

CM 协议通过报文的多次往返来建立连接，类似于 TCP 协议的握手，同时也规定了断链的方式。

参考：Savir，https://zhuanlan.zhihu.com/p/494826608

RST 由两大子模块组成：RFT 和 RPT。

RFT – RDMA Flow Table

RFT 以容器形态运行在每台交换机的管理系统上，主要功能包括：

1. CM报文捕获：匹配CM管理面通信报文并上送到AsterNOS的RFT容器中；
2. 会话解析与状态管理：解析CM交互报文抽取关键字段，构建会话状态机，记录每条会话的生命周期与状态（如：Established / Closed）；
3. 流表输出：RDMA 流表信息通过 4791 端口暴露给工程师和 RST 控制器。

RPT – RDMA Path Table

RPT 运行在独立的 RST 控制器上，负责全网设备的流表采集和实时路径还原，并将最终结果以图形化的 WEB 界面（Grafana）提供给业务侧。

RST 工具的使用

获取交换机信息

RST 工具可从EasyRoCE-AID 中自动获取交换机信息（主机名、IP地址、用户名、密码），这是正确获取各交换机上的 RDMA 流表信息的前提。

分别安装 RST 下的子模块

1. 将 RFT 的容器镜像上传到星融元交换机操作系统 AsterNOS ，导入运行此容器
2. 将 RPT 的代码包上传管理节点服务器上，解压运行，一键生成 Grafana 面板

此时登录到刚生成 Grafana 面板即可访问、操作 RST 工具。

RST 工具首页

RST 工具首页可看到当前组网内的所有业务交换机的列表和功能指示开关，直观查看和修改交换机上 RFT 容器的启用和停止状态。

当设备对应的开关处于打开状态，用户可点击后方“查看”按钮，进入 RDMA 流表信息页，查看设备的流表与 RDMA 会话状态追踪。

RDMA流表信息页

当全网设备都开启 RFT 功能，点击 RST 工具首页左上角的流量路径按钮，即可进入 RDMA 流量路径表信息页，由此看到全网的 RMDA 通信会话的转发路径。

RDMA流量路径表信息页

星融元EasyRoCE Toolkit更新，带来智简开放新体验

VRRP协议概述

VRRP (Virtual Router Redundancy Protocol) 是一种旨在解决局域网内默认网关单点故障问题的容错协议。
通过 VRRP，多台物理路由器或交换机可以逻辑上聚合为一个“虚拟路由器”，并对外统一提供一个虚拟 IP (VIP)。对于终端设备（如服务器、PC）而言，网关配置仅需指向该 VIP，无需感知底层物理设备的运行状态或切换过程。

VRRP核心工作机制

VRRP 运行基于优先级竞选机制，定义了两种主要角色：

• Master (主设备)：负责处理并转发目标地址为虚拟网关的数据包，同时定期向备份设备发送 VRRP 通告报文以维持状态。
• Backup (备设备)：实时监听 Master 的通告报文 ()。一旦在预设时间内未收到报文，则判定 Master 发生故障，并触发切换逻辑接管业务。
• 虚拟 MAC 地址：为确保切换过程中终端侧 ARP 表项依然有效，VRRP 使用固定的虚拟 MAC 地址，实现对业务侧的透明切换。

在传统架构中，单出口路由器面临硬件损坏、链路故障或维护停机等高风险单点故障隐患。VRRP 的引入提供了：高可用性，支持秒级甚至毫秒级的故障恢复，以及业务连续性，在设备升级或维护期间，通过协议自动切换确保网络不断连。

智算中心 (AIDC) 高级实践

在承载大量 AI 训练与推理任务的智算中心，VRRP 常部署于汇聚层或核心层交换机，以保障 GPU 服务器集群（如 H100/H800）业务网关的 24/7 在线 。

VRRP 与 MC-LAG 结合（双活转发）

现代 AIDC 架构中，VRRP 常与 MC-LAG (跨设备链路聚合) 配合使用，将传统的“主备”模式优化为“双活”模式，两台物理设备通过 Peer-link 同步状态，并将虚拟网关 MAC 写入硬件转发逻辑。当流量经负载均衡到达 Backup 设备时，Backup 设备直接根据本地网关信息进行转发，无需绕行 Master，极大提升了带宽利用率。

联动 BFD 实现超快切换

针对 AI 训练对网络抖动极其敏感的特性，通过部署 BFD for VRRP，可将故障感知时间从秒级压缩至 10ms-50ms，有效防止因网络波动导致的训练任务失败 。

版本演进：VRRP V2 vs. VRRP V3

随着 IPv6 的普及及对切换速度要求的提升，VRRP 经历了从 V2 到 V3 的重大进化：

VRRP 作为网络高可用的基石，在管理网、带外网及非全路由环境中仍具有不可替代的地位 ()()。通过与 MC-LAG 及 BFD 等技术的融合，它能够满足智算中心对极致稳定性和转发性能的双重需求。

关注星融元

大多数传统园区全光接入网络中的接入层是割裂运行和管理的：OLT / ONU（光线路终端/光网络单元） 由 PON （无源光网络）管理系统负责，而 Wi-Fi AP 由无线网控制器管理。

网络规模较小的场景下，独立管理的弊端尚不显著，但进入到例如多校区教育机构、企业集团等大规模接入场景里，这种网络架构将会迅速放大运维复杂度：

• AP 离线时，很难第一时间判断是供电、光纤，还是无线问题
• 光功率下降，是否已经影响终端的 Wi-Fi 体验？
• 运维人员需要在多个系统之间反复切换，才能拼凑完整的接入链路状态

基于 OpenWiFi 的统一接入控制面

星融元推出的新一代基于 OpenWiFi 架构的园区网络控制器 Asteria Campus Controller（ACC），提供了覆盖“光+无线”的统一控制与可视平面。

我们之前介绍的全光接入方案中采用的是 OLT Stick 作为 OLT 专用硬件的替代，去帮助用户大幅降低建设和运维成本。详情参考：“去OLT” 的新一代园区全光接入网络和组网对比

该思路下，实现统一纳管的核心在于 OLT Stick 不再作为一个“外部系统”，而是被视为与 AP 同级的接入节点， 与网络中的无线AP，以及园区交换机都遵循相同的、基于 OpenWiFi 的接入、配置和状态模型。

所以，ACC 控制器除了可以统一纳管常规的交换机和无线AP之外，运维人员也可以直接看到 OLT 和 ONU 的各类状态和配置信息，例如：

• 所有 OLT 的在线状态以及与 ONU 的连接关系
• 每个 ONU 的光功率、上下线历史

值得说明的一点是：控制器 ACC 并不参与数据转发，其职责专注于在控制与设备运行的可视化方面,负责设备注册与生命周期管理、接入设备的状态汇聚、策略决策模板的绑定、告警与历史数据管理等；OLT / ONU 设备负责数据转发，光链路维护，执行控制器下发的策略。

这种清晰的职责划分，使系统在规模扩展时依然保持稳定与可维护性。

OLT/ONU的纳管流程：即插即用零配置

DHCP Discovery

OLT Stick 接入在交换机的光口上，向上通过标准化报文接口与控制器通信，向下通过 PON 协议管理 ONU 设备，实现两层协议的透明转换；上电后，会像一个标准接入设备一样发送 DHCP Discovery 请求

地址分配与发现控制器

控制器发出的 DHCP 响应中不仅包含 IP 地址，还会通过 DHCP Option 138字段返回控制器的地址，从而让 OLT Stick 明确知道自己需要向哪个控制器注册。

注册与持续的状态上报

OLT Stick 获取 IP 后会主动向 ACC 控制器发起注册，并建立起持续的心跳与控制通道，周期性上报在线/离线状态、光模块信息、实时与历史光功率、连接历史等，以上都不需要运维人员手动加以配置。

ACC 同时会将这些信息与 AP 状态进行关联，帮助用户判定 AP 离线是否由光功率异常引起，Wi-Fi 不稳定是否与光链路波动相关等问题。

策略配置下发和执行

完成了上线动作，此时的OLT也不再只是传统意义上的被动转发设备，而是一个可策略化、可编排的接入节点。

ACC控制器可以在一处向 OLT Stick 集中下发白名单与准入策略、QoS 与流量控制规则、配置模板绑定、运维与管理策略等等。

得到指令的 OLT Stick 负责对其下挂的 ONU 执行具体操作，例如接入控制、用户级策略执行、带宽与流量管理等。同时，OLT stick 也具备基础的事件过滤与告警收敛能力，以减少无效事件对控制器的冲击。

光网络的最终交付点 ONU 则为终端用户提供多种接入方式，执行来自 OLT 的 QoS 策略、安全规则、VLAN 划分等配置，确保用户服务质量，并且实时监测自身工作状态（光功率、温度、电压）及连接终端的信息，并上报至 OLT，最终呈现在ACC的监控面板。

典型案例：校园分支机构

该拓扑展示了采用 OLT Stick 的光接入方案在校园分支网络中的典型应用。

该网络采用 Spine-Leaf 架构，由ACC集中管理 Spine 和 Leaf 交换机、OLT stick、PON AP，Spine 与 Leaf 层之间运行 BGP。

Leaf层交换机的 SFP 端口插入 OLT Stick，将不同业务 VLAN（如 10、20、30）由以太光转换为 PON 光信号，经光纤传输至分光器（ODN）层，最终连接多所分校的AP上，实现高效、可扩展的分校无线网络接入与管理。

组网优势

• 极简化架构：Leaf交换机直插 OLT Stick，省去传统独立 OLT 机柜，降低设备复杂度与空间占用。
• 光纤直达：单根光纤承载一个学校的业务，直达学生宿舍的 PON AP，实现 FTTR。
• 灵活扩展：Spine-Leaf 架构与 BGP 协议便于横向扩容，学校新增楼栋只需在 Leaf 层增加端口或 OLT Stick 即可快速接入。

运维优势

• 集中管控：通过统一的控制器，实现各分校接入设备的远程管理，无需现场操作。
• 业务快速部署：模板化配置交换机、OLT 与 PON AP，一键配置下发，缩短业务上线时间。
• 故障定位直观：控制器可实时监测 OLT Stick 及光链路状态，快速定位光纤中断、VLAN错误或设备故障点。
• 降低运维成本：简化物理层设备，减少机房空间与能耗。

关注星融元

近日，星融元数据技术有限公司 (Asterfusion) 完成新一轮融资，本次融资由厦门联和、湖南财信共同投资，历史投资人包括华业天成，上海金浦，深圳高新投等。

随着AI大模型浪潮席卷全球，智算中心对网络基础设施提出了革命性要求——低延迟、高带宽、无损且可大规模扩展的网络成为释放算力潜力的关键。在这一背景下，全球头部厂商正加速从传统网络向以AI为中心、开放解耦的新型架构演进，网络基础设施的技术与市场格局正在重构。

星融元作为国内AI网络架构的领先者，紧密契合这一技术跃迁趋势。公司前瞻性地布局并成功构建了「云网融合、开放解耦」的核心技术体系，致力于为AI时代的IT基础设施提供软硬解耦、软件开源、硬件开放、芯片可编程的全栈网络解决方案。为全球私有云、存储、安全、高性能计算、智慧园区等生态伙伴提供中立开放、功能易扩展、以应用场景为中心、智能优化运维成本的网络连接能力。

目前，星融元已形成覆盖数据中心、云/智算中心及广域网边缘的丰富产品矩阵，其最新一代AI Fabric高性能网络解决方案已在多家头部客户实现规模化部署，可有效支撑千卡乃至万卡级AI集群的稳定高效运行。公司持续与行业头部企业合作研发OCS交换机、CPO交换机等前沿网络硬件产品，布局全球头部云厂客户，研发与服务体系日益完善，正以坚实的创新步伐，推动网络基础设施迈向全新的AI原生时代。

关注星融元

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

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

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

AsterNOS Geo-Engine 工作逻辑

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

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

• GeoIP： 按区域（如 CN, US）识别
• GeoSite： 按应用（如 YouTube, 游戏，办公应用）识别

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

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

为什么不使用传统 DPI？

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

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

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

域名提取

与深层数据包检测（DPI）不同，该技术专注于不同协议的报文头特征字段的提取：

• HTTPS/TLS： 在 TLS 握手阶段解析 Client Hello 包，提取SNI（Server Name Indication） 字段

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

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

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

匹配算法和数据结构

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

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

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

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

业务流处理

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

1. 域名提取：数据包进入geosite_input节点，根据协议类型提取域名。
2. 会话查询：系统查询现有会话表。若存在匹配结果则直接复用，减少重复解析开销。
3. 规则匹配：

• 域名特征匹配：对于携带域名信息的数据包（如TLS客户端初始化、HTTP主机字段、DNS查询），系统优先提取域名特征并与GeoSite规则库进行匹配，这是最精确的识别方式。
• IP匹配：对于域名未匹配任何规则的数据包，系统利用DNS解析结果匹配配置的GeoIP规则。
• 对于无法提取域名数据包，系统直接使用IP地址进行匹配。

执行动作

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

典型应用场景

1.应用感知路由（PBR）

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

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

伪代码示例：

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

2.安全合规与地理围栏

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

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

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

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

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

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

硬件平台支持

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

ET2500开放智能业务处理平台

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

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

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