标签：技术实现

技术手册- 显示拥塞通知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。如需了解产品详情或项目定制方案请与我们联系。

完整揭秘：新一代园区网络运维管理全流程

关注星融元

前言：传统网络面临的结构性挑战显而易见，尤其是多地多分支机构的大型园区网络，哪怕引入了一个大而全的SDN控制器，但底层仍沿用着复杂的园区网络架构，有线无线两张网分离控制，真实使用体验依旧差强人意。

新一代的园区网应该是什么样的？且不论未来如何，在放眼可见的当下，除了承载常规的办公网业务，园区的网络基础设施已然在面对诸如物联网智能终端接入，频繁的无线漫游，以及各类公有云、本地私有云业务融合等等挑战。

园区网络的云化转型已成必然趋势。论及云化，不单是更高的带宽速率，更是要配合现代化的网络架构和灵活的运维方式，解决复杂业务和管理效率之间的矛盾。

TIP：电信业“开源运动”领导者

TIP（电信基础设施项目）成立于2016年，由Meta（原Facebook）联合多家全球电信运营商、技术公司和行业组织发起，是一个开放协作的行业联盟。其核心目标是推动电信基础设施的开放解耦化和软件化，通过技术创新降低网络部署和运营成本，加速全球通信网络的普及与升级。

TIP 推出的 OpenWiFi 和 OpenLAN Switching为企业园区网络场景带来了基于通用硬件和开源软件的解决方案。

uCentral 作为 OpenWiFi 通信框架的关键核心，是一种标准化数据模型，它定义了网络中关键配置数据的结构和语义，以确保整个网络的一致性和互操作性，并且该协议是开放可扩展的，随社区技术发展平滑演进。

OpenLAN Switching（OLS）将 OpenWiFi 的管理框架延展到了有线网络，显著扩展了OpenWiFi 的功能。实现形式是在交换机内部以容器形式运行一个客户端（uCentral Client），将有线网络纳入统一管理框架中。

OpenWiFi、OLS、局域网（LAN）

OpenWiFi和OLS 在局域网（LAN）中扮演各自不同角色，通过统一的北向接口与上层管理系统（Cloud SDK ）对接，并可复用成熟的开放网络组件（例如SONiC NOS）形成有线+无线、完整的端到端开放网络解决方案

Asteria Campus Controller（ACC）是星融元基于SONiC+ OpenWiFi/OLS 的云化网络的核心组成部分。

作为一款基于TIP社区标准的轻量级控制器软件，ACC 为园区有线网络和无线网络的统一管理提供了全面的解决方案。它可以无缝管理无线AP（包括第三方白盒AP）和所有搭载着星融元AsterNOS的SONiC交换机，自动执行网络配置和管理等关键任务。正常情况下，为一个中大规模的园区开通网络业务仅需30分钟。

部署方式

ACC支持三种部署方式：

本地部署（以docker形式部署在开放计算平台/服务器）
虚机部署（部署在虚拟机内，网络设备较多时适用）
云上部署（通过访问IP/域名，随时随地查看整网运行状态）

01、ACC 界面概览

登录ACC控制器后我们首先会看到一张全景地图，可以看到控制器纳管的网络自顶向下分为“根节点-组织-场所-设备”四个逻辑层。

（点开查看gif）

根节点作为系统默认节点，不可调整；
根节点下可建立“组织”，可以简单理解为一个管理域（例如一家公司或园区运营者可支配的管理范围）；
“组织”下可建立“场所”，对应着不同的办公区域或者分支机构；“组织”支持嵌套结构，即建立子组织，并继续建立子组织下的“场所”；
“场所”之下是设备层，展示了分配在该场所的物理网络设备，一般是按照有线设备（交换机）、无线设备（AP）分组。

02、内生的资产管理能力

值得一提的是，控制器内部自带了较为完善的资产管理能力，标准使用流程下即可自动完成数据整理并生成设备清单。

具体来说，我们购入新设备做的第一件事便是进入预计安装部署的组织或场所，比如下图的“1号办公楼”，在库存栏目点击按键选择手动导入设备或者基于模板批量导入。

此处导入的信息主要是设备的角色类型（Spine或Leaf）和序列号。待设备上电，控制器会自动根据设备的MAC将其纳入所属的组织/场所，并无额外操作。

导入完成后便可获得下面这张设备清单，它包含了设备所在场所、型号、名称、管理IP、许可证状态等信息字段。管理员可在此选择特定字段筛选，并在同一界面编辑调整清单信息。此处的“标签”字段对应的是控制器的配置模板，后续设备将据此标签信息从控制器拉取对应配置文件，做到真正的即插即用。

03、ACC带来的运维效率提升

上文已经提到，使用ACC为一个中大规模的园区开通网络业务仅需30分钟，开局效率的大幅提升主要来自于以下几点：

基于场景模板（全三层的Spine-Leaf 架构）自动生成规划拓扑
屏蔽实现细节，由控制器自动计算并通过ZTP机制下发基础网络配置
借助DHCP option 128 为交换机和无线AP同时提供“即插即用”的能力
图形化界面+自定义脚本，一键配置VLAN业务，DHCP中继，以及其他安全协议

下一篇我们将围绕上述内容详细展开，请持续关注。

A-Lab 杂谈 | 十年老网工，为啥这次没把智算服务器一次配通？

关注星融元

十年弹指一挥，当年的爆款热词“云计算”已然能搭上“传统” 二字当前缀；

十年弹指一挥，机房滚滚轰鸣声中，网工小王不知不觉熬成了老王；

老王不解啊，十年弹指一挥，咱亲手上架的服务器不说上千也有大几百，不就多了几张网卡，配个智算服务器怎会卡了壳？！

客官别笑，通用云计算中心与智算中心在主机侧网络架构层面的确存在显著差异，老网工偶尔走点弯路也是在所难免的啦。今天就让我们快速捋一捋其中缘由。

为啥出错？

传统CPU服务器多采用单网卡出口设计，通过OS内核协议栈实现网络报文转发，其网络拓扑相对简单，主要满足虚拟化资源的弹性调度需求。

源于AI训练任务对网络带宽的严苛要求，智算中心的GPU服务器普遍采用多网卡出口架构，用于接入参数网、存储网、业务网和带外管理网，其中通常会有8张网卡用于接入参数网，或称计算后端网络。而跨服务器的通信大多发生在同轨（Rail）的网卡/GPU之间。（请参考：关于智算的“多轨道网络架构”）

多轨道网络架构

老王遇到的机间通信失败问题主要发生在以下两种场景：

场景1：

智算业务报文从管理网段发出。两台GPU服务器A和B的8张网卡都接入到一张参数网，对应的网卡A1到A8、B1到B8，它们都分配到不同的网段，同轨网卡之间有互通需求（A1-B1，A2-B2…）

如果没有进行路由规划，通常在GPU服务器A的系统上会看到默认路由是业务网的，8个子网A1～8会产生8条对应的网段路由，报文会命中A的默认路由从管理网段发出，此时A1和B1是无法直接通信的。

场景2：

回程通信失败。如果网卡A1到A8、B1到 B8 都分配到同一个网段下的不同IP，在这种情况下在服务器B上通过B1尝试与A1通信，会发现报文可以到达A1，但是回包会命中默认路由之外的代价最低的路由，很可能会从其他7张网卡中的一张出去，导致通信失败。

通信失败情况下可能的系统路由配置：

路由配置

应对思路

当传统路由设置方法在智算环境下失效，一个可行的应对方式是提前规划GPU服务器内的路由，借助Linux的多路由表和策略机制实现更加灵活、精细的流量控制和路由管理功能。

具体而言：在Linux内增加一个自定义路由表，并通过策略路由告知系统，特定源地址的报文根据这张自定义路由表转发，并在该表中增加一条指定目的网段的表项（例如前往10.0.5.0/24的报文从指定网卡发出）。

多路由表（Multiple Routing Tables）：Linux支持多张路由表，这些路由表可以通过不同的标识符来区分，每张路由表中可以包含一组路由规则。Linux系统默认会存在一个主路由表，当不特别指定的时候路由规则会写入默认路由表。
策略路由机制（Policy Routing）：根据数据包的源目的IP、网卡等条件来选择合适的路由表进行转发。

更高效的实现方式

更高效的办法，当然是用脚本工具批量自动配置啊！

星融元（Asterfusion）AI智算网络解决方案中包含的EasyRoCE Toolkit – IRM工具（In-Node Route Map，GPU服务器内部路由规划）正是用于解决多网卡路由问题——根据已有的IP地址规划表，自动生成并对集群内所有GPU服务器下发内部路由规划和配置。

IRM工具运行过程中需要通过SSH和集群中的所有GPU服务器进行交互，一般运行在管理节点上。

GPU服务器内部路由规划

网工老王仅需完成三步微操：

1、将IRM工具上传到管理节点；

2、指定需要解析的路由规划信息文件。该文件可在EasyRoCE-AID （AI Infrastructure Descriptor，AI基础设施蓝图规划）工具引导下手动填写，形式为下图所示的excel表格，主要包含IP和接口地址规划、Rail平面划分等构造智算网络的必备信息；

IP和接口地址规划、Rail平面划分

3、运行IRM工具脚本。等待上述规划信息完成转换重组后，IRM工具会生成包含路由配置的JSON文件并下发到集群，随后网络运维人员即可查验到所有GPU服务器内部的策略路由都已成功生效，同一个Rail平面内的网段按照预期正常互通。此外，该阶段生成的JSON文件亦可复用于其他客户自定义/第三方工具。

DeepSeek优化徒劳？揭秘99%的AI推理集群都适用的组网设计

关注星融元

DeepSeek的优化，精细但门槛极高

作为开源周的“彩蛋”，DeepSeek于上周六展示了采用混合专家模型（MoE）DeepSeek-V3 / R1 所使用的推理架构的整体方法——从增大吞吐和降低时延的目标出发，再次优化了PD分离架构，不过暂时没有开源代码。

（MoE）DeepSeek-V3 / R1

与Llama等采用张量并行（TP）的Dense（稠密）模型不同，混合专家（MoE）模型通过组合多个专家模型来处理复杂任务，每个专家模型专注于输入数据的不同部分，每次计算任务只需激活特定专家（而非整个神经网络）。

DeepSeek-V3 / R1 的推理系统架构一方面引入了更复杂的跨节点和多节点的传输提升计算效率和改善内存墙，同时也通过异步通信和流水线调度设计，确保由此增加的通信开销被计算任务掩盖。

值得注意的是，根据官方公布的信息，若要充分发挥DeepSeek MoE 模型的能力，起步资源是320卡，且不论在未开源的情况下面临的技术挑战。

综合成本和需求考量，上述面向专家并行的推理系统优化仅在部分toC云计算场景具备一定研究意义。现阶段toB行业大模型以及边缘计算场景仍以Dense模型为主，需要高并发的大集群平台部署可延续现有主流的算力网络设计思路，面向本地低并发需求则可采用大内存单机部署方案。

回顾：AI推理集群的PD分离和流量特征

大模型的推理任务一般分为两个阶段，一是Prefill，处理所有输入的 Token，生成第一个输出 token 和 KV cache，是算力密集型；二是Decode，利用 KV Cache 进行多轮迭代，每轮生成一个 token，需要反复读取前面所有token的 Key 和 Value，瓶颈在于内存访问。

从用户实际体验层面看，推理过程中最关键的指标是 “第一个Token的延迟” （Time To First Token, TTFT）和后续token输出的延迟（Time Per output Token, TPOT）。

如果 Prefill 和 Decode 两个阶段在同一张GPU卡上运行，则容易发生资源争抢影响到 TTFT 和 TPOT 表现，尤其是当用户输入一段长 prompt 时，不光需要较多算力来支撑prefill运算, 也需要大内存来存储 KV Cache。

Prefill-Decode

因此，业界通常采用 Prefill-Decode 分离的架构：用高算力卡做 Prefill（prefill server）, 低算力卡做 Decode（decode server）, Prefill节点在完成计算传输 KV cache 后即可释放本地显存。

参阅：一文揭秘AI智算中心网络流量 —AI推理

AI推理系统的 Scale-out 组网设计

推理集群的工程部署方面，由于 Prefill 和 Decode 采用的GPU并行方式不一样，Prefill和Decode集群是相互独立的，但两个集群间需要互联以同步KV cache。从两个阶段的输入输出来看，Prefill 流量的特征是低频大流量，要求大带宽；Decode 阶段流量的特征是高频小流量，要求低时延。

1、分离网络架构

分为Prefill网络和Decode网络，分别负责本集群内流量，两个集群之间的流量通过互联网络实现
两个网络分别运维管理，但Prefill和Decode GPU之间的流量至少需要3跳

2、统一网络架构

单个网络同时负责集群内和集群间流量
网络统一运维管理，Prefill和Decode GPU之间流量可一跳直达

统一网络架构

我们推荐采用统一网络架构，借助 QoS、自适应路由技术对 Prefill 和 Decode 流量分别处理。

Rail-only 拓扑

Rail-Only

GPU服务器内部：每四个GPU作为一组，共享一个并行推理网卡，连接到同一个PCI Switch,两组GPU之间的通信通过两个PCI Switch之间的直连通道完成；
GPU服务器之间：同一组号的GPU之间的通信通过交换机直接完成；不同组号的GPU之间的通信，先通过PCI Swtitch将流量路由到另一组的网卡，然后通过交换机完成

小规模并行推理网络拓扑

每台推理服务器有8张GPU，2张400G网卡，双归连接到两台CX732Q-N
16个推理服务器（128张GPU）和2个CX732Q-N组成一个PoD。Prefill和Decode服务器可能属于不同PoD
可横向扩展至64个PoD

中大规模并行推理网络拓扑

每台推理服务器有8张GPU，2张400G网卡，双归连接到两台CX864E-N
64个推理服务器（512张GPU）和2个CX864E-N组成一个PoD，Prefill和Decode服务器在同一个PoD，服务器间一跳可达
可横向扩展至64个PoD

拓扑设计仅供预览参考，方案均采用星融元（Asterfusion）提供的CX-N系列 AI智算网络产品：基于SONiC的开放NOS（AsterNOS）+ 100G/200G/400G/800G 超低时延以太网交换机硬件，全端口支持 RoCEv2 & EasyRoCE Toolkit。了解产品详情或项目定制方案请与我们联系。

尝试私有化部署DeepSeek？至少九成工程师会忽略这一点

关注星融元

当你尝试在私有集群上部署各类LLM应用，除了关注作为成本中心的算力资源，也一定不要忽视网络侧的配置！未经优化的网络连接，会给你的集群通信性能带来将近80%的损耗，哪怕仅有双机8卡规模。

参考：分析NCCL-Tests运行日志优化Scale-Out网络拓扑

一言以蔽之，上述性能瓶颈来自于网络连接方式与集合通信模式的不匹配。当前智算集群内采用的组网是“轨道优化”或“多轨道网络架构”，连接方式与一般云计算场景差别巨大。

以适用性最高的 Fat-tree CLOS 组网架构为例（这也是各大智算公有云的首选方法，具有非阻塞的 all-to-all 连接，不依赖于正在训练的模型），下方拓扑中的Leaf/TOR交换机被称为轨道交换机（Rail Switches），它们与所有集群单元内的GPU节点都建立了直接连接。

Fat-tree CLOS

为什么要有轨道优化？

这个问题可能需要从通信库说起。当我们要利用分布式的GPU集群实现并行计算，集合通信库是关键环节之一。集合通信库向上提供API供训练框架调用，向下连接GPU卡（机内和机间）以完成模型参数的高效传输。目前业界应用最为广泛的是NVIDIA 提供的 NCCL 开源通信库，各个大厂基本都基于 NCCL 或 NCCL 的改造版本作为底座。

NCCL自2.12版本起引入了 PXN 功能，即 PCI × NVLink。PXN 利用节点内 GPU 之间的 NVIDIA NVSwitch 连接，首先将数据移动到与目的地位于同一轨道上的 GPU 上，然后将其发送到目的地而无需跨轨道传输，从而实现消息聚合和网络流量优化。

NVIDIA NVSwitch

轨道优化拓扑即是适应这一通信特征，将不同服务器上位于相同位置（轨道）的NIC连接到同一台交换机上。

由于每个服务器有8张连接计算平面的网卡，整个计算网络被从物理上划分为8个独立并行的轨道（Rail）。由此，智算业务产生的并行通信需求（All Reduce、All-to-All 等）可以用多个轨道并行地传输，并且其中大部分流量都聚合在轨道内（只经过一跳），只有小部分流量才会跨轨道（经过两跳），大幅减轻了大规模集合网络通信压力。

轨道优化聚合了同一对 NIC 之间传递的消息，得以最大限度地提高有效消息速率和网络带宽。反观NCCL 2.12 之前，同样的端到端通信将经过三跳交换机（上图的L0、S1 和 L3），这可能会导致链路争用并被其他流量拖慢。

如何配置多轨架构的智算网络？

首先是需要明确GPU卡的连接方式。如果是N卡，你可以使用nvidia-smi topo -m的命令直接查看。但综合考虑成本因素，要想在更为通用的智算环境下达到GPU通信最优，最好的办法还是在采购和建设初期就根据业务模型特点和通信方式预先规划好机内互联（GPU-GPU、GPU-NIC）和机间互联（GPU-NIC-GPU），避免过早出现通信瓶颈，导致昂贵算力资源的浪费。

下面我们以星融元智算网络方案具体举例，使用CX-N系列RoCE交换机组网。

CX-N系列产品

100G/200G/400G/800G RoCE 端口，运行企业级SONiC/AsterNOS，转发时延约450~560ns，全面支持 EasyRoCE Toolkit

主机侧的路由配置

智算环境下以GPU卡（而非服务器）为单位的通信模式形成了服务器多网卡多出口环境的路由策略，通常会有8张网卡用于接入参数/计算网，每张网卡位于各自的轨道平面上。为避免回包通信失败，服务器上的网卡配置需要利用Linux多路由表和策略路由机制进行路由规划，这与传统云网的配置方式完全不同。

第一步是按照组网规划和网段规划，进行IP地址规划和Rail平面划分。在我们的EasyRoCE Toolkit 下的AID工具（AI Infrastructure Descriptor，AI基础设施蓝图规划）中，Notes字段用于标注Rail编号，即0代表Rail平面0、1代表Rail平面1，以此类推。

确认好了上述信息，到这里其实可以开始手动配置了，但你也可以使用另一个EasyRoCE的IRM工具（In-node Route Map，GPU内部路由规划器）。IRM 从AID 生成的配置文件中获取适合当前集群环境的路由规划信息，并且自动化地对集群中的所有GPU服务器进行IP和策略路由配置。

In-node Route Map，GPU内部路由规划器

交换机侧的主动路径规划

CLos架构下，各交换节点分布式运行和自我决策转发路径容易导致无法完全感知全局信息，在多层组网下流量若发生Hash极化（经过2次或2次以上Hash后出现的负载分担不均）将拖慢集群性能。

为解决满足AI集群规模化部署的通信需求，一般来说我们会通过规范流量路径来解决性能和规模方面的痛点（例如负载均衡、租户隔离等），按照如下转发逻辑去配置RoCE交换机：

跨 Spine上行流量进入Leaf后根据源IP和是否为跨Spine远端流量，执行策略路由转发给Spine，每网卡对应一个接口：

在上下行流量1：1无收敛的情况下，Leaf的每个下行端口绑定一个上行端口；
在n：1的情况下，上下行端口以倍数关系(向上取整)形成n:1映射。

跨Spine上行流量在Spine上按照标准L3逻辑转发，在轨道组网中多数流量仅在轨道内传输，跨轨道传输流量较小，网络方案暂不考虑Spine上拥塞的情况（由GPU Server集合通信处理）。
跨 Spine下行流量进入Leaf后根据 default 路由表指导转发。

当然，这里也可以使用EasyRoCE Toolkit 下的PPD工具（主动路径规划，Proactive Path Definer）自动生成以上配置。以下为PPD工具运行过程。

正在生成配置文件
100%[#########################]
Configuring leaf1's port 
leaf1的端口配置完成 
Generating leaf1's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf2's port 
leaf2的端口配置完成 
Generating leaf2's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf3's port 
leaf3的端口配置完成 
Generating leaf3's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
Configuring leaf4's port 
leaf4的端口配置完成 
Generating leaf4's ai network config
The ai network config finished.
 
正在生成配置文件
100%[#########################]
show running config
是否需要查看生成的配置(Y|N):

PPD可以独立运行在服务器上，也可以代码形式被集成到第三方管理软件中，利用AID工具来生成最终配置脚本，将配置呈现在统一监控面板（例如Prometheus+Grafana）进行浏览和核对。

PPD

园区网前沿实践：基于开放网络架构的云化路由设计

关注星融元

底层物理网络设计

如下图所示，区别于传统的“接入-汇聚-核心”架构，新一代云化园区比照数据中心网络采用 Leaf-Spine 的 Clos 架构组网，Leaf 和 Spine 层都被设计成独立的 AS 并通过 eBGP 互联，支持终端设备以 1GE 及以上端口速率接入网络。

园区底层物理网的云化升级关键是将 EVPN 和 BGP 等能力下沉到接入级交换机。目前全功能的企业级SONiC（AsterNOS）可稳定运行在园区交换机上，完全支持将此类成熟的云网技术引入园区。

由此，我们构建了足够灵活、可靠的全三层网络来承载园区日益复杂、多变的网络业务，消除了原有传统架构用于业务分区管理的二层网络，也无需引入堆叠架构。

根据实际需求，我们有时也会在 Spine 和 Leaf 之间添加二层交换机，但其唯一功能是扩展端口容量，不会参与路由、EVPN 或 BGP 操作。

这种设计对大型园区的好处十分明显，例如杜绝内网广播风暴，降低网络架构复杂度（一键下发配置模板做到”全自动BGP”）；同时也具备一定的内生安全性（例如隔绝了依赖广播的病毒攻击等等），以及高度适应企业数字化转型的云原生特性。

终端IP地址规划和分配

回归到路由设计的话题，构建全三层路由网络的重难点是合理规划和分配 IP 地址。

我们知道，传统园区网络设计中不可避免的一大挑战来自交换机的表项资源，其大小决定了园区接入规模的上限，这也是为什么曾经我们需要大型机框作为核心路由来支持超大型网络。

而在上述的云化园区网里，我们并未引入任何昂贵的机框设备，那么仅凭全盒式的开放交换机设备是如何做到的呢？

简言之，通过聚合路由技术和合理的IP分配策略，我们可以有效节约路由表项资源，并结合多级的 Leaf-Spine 架构将网络平滑扩容到30K+终端接入规模。

两种不同类型的终端路由信息

园区网络中的终端大体可分为漫游和非漫游两种类型。

对于非漫游终端，我们可以使用聚合路由，即将多个终端设备 IP 地址聚合到一个子网路由，以减少交换机表项空间占用。

聚合路由的正常运行需要与 IP 地址分配策略紧密结合，而借助 DHCP Option 82，我们可以确保同一 Leaf 交换机下的所有非漫游终端设备聚合在同一子网内。

DHCP Option 82 即“中继代理信息选项”。园区Leaf交换机作为 DHCP 中继代理设备，会在客户端发起的DHCP请求报文中添加 Option 82 字段，将 DHCP 客户端的位置信息附加进去提供给DHCP 服务器，后者利用该字段信息为主机分配合适的IP地址和其他配置信息；中继代理设备会在将DHCP回复转发给客户端之前删除该字段。

对于漫游终端不会使用聚合路由，而是保留其原有的 IP 地址。即使终端漫游到不同的 Leaf 交换机，也将一直使用原有的主机路由信息接入网络。

Spine 层交换机负责正确维护这些漫游终端的主机路由信息，整网范围皆为“云漫游”域。这种新架构下我们无需建立CAPWAP隧道让流量绕行转发，配置管理上也做到了高度简化。

相关阅读：下一代园区网络，“分布式网关”实现更高效的无线漫游！

以上过程中所有二层数据帧都将被转发并转换为三层报文，ARP 侦听机制在其中起到了至关重要的作用。

ARP 侦听机制

终端发起 ARP 请求时，其接入的Leaf 交换机会通过 ARP 侦听机制生成 ARP 和 IP 地址之间的映射（将ARP表项转换为32位主机路由），将这些信息同步到直连的 Spine 设备上，并通过BGP重分发学到的主机路由使其在 Spine 层传播，但不会再发送到其他 Leaf 交换机上。

最终，各类主机的路由信息会以如下方式逐级汇总：

Leaf 交换机保存本地连接的主机路由和通往上层 Spine 交换机的默认路由
Spine 层交换机维护整个网络的路由，包括整网所有终端的主机路由信息
更上层的网络设备（如FW）路由表存放非漫游终端的聚合路由和漫游终端的主机路由

如此一来，无论是 MAC 地址表还是主机路由表，Leaf 交换机都只存储本地路由和默认路由，只有高性能的 Spine 层交换机维护全局路由信息，从而给后续网络扩容留有充足空间。

BGP 路由快速收敛

我们的整个网络采用 BGP 路由协议，利用 BFD （双向转发检测）实现快速路由收敛。BGP 使用 BFD 监控链路和节点状态，可在单链路或单节点故障时实现快速恢复，故障检测时间约为 150 毫秒，性能可调。发生故障时，流量会自动切换到备用交换机，确保快速恢复端到端服务。

EVPN Multihoming 技术确保终端高可靠接入

为了保证终端访问的可靠性，接入园区网络的服务器可采用 EVPN-Multihoming 技术，将其连接到两个 Leaf 交换机上作为主-主备份的双上行接入；对于无线AP也可以采用类似的设计，将它们连接到两个 Leaf 交换机，以确保在单链路故障时业务不中断。

P4 软件开发环境（Intel P4 Studio SDE）现已开源

关注星融元

Intel P4 Studio 软件开发环境 (SDE)是一套支持用户使用P4语言对P4可编程以太网交换机数据面进行编程的软件包，编译好的数据面程序可以运行在Tofino芯片上或是SDE中的模拟芯片上。该软件包还包含用于构建和安装 SDE 的脚本。

P4 SDE 现已开源

据P4社区网站（P4.org）近期发布的公告 (https://p4.org/intels-tofino-p4-software-is-now-open-source/)，原先需由用户向Intel申请使用许可的P4软件包现已开源（仿真模型尚在开源准备过程中）。

开发人员现在可以访问整个源代码，该代码组织在 p4lang 结构内的两个主要存储库中。p4c 存储库现在还包含 Tofino 编译器组件，其子文件夹包括 arch、common、control-plane、driver、midend、test 和 docs。Tofino后端与 bmv2、ubpf 和其他后端处于同一层次。新推出的open-p4studio 存储库包含 Tofino P4 Studio 的所有其他组件，例如 bf_driver、bf_diags、bf_utils 和 tofino_model。

项目地址：https://github.com/p4lang/open-p4studio

仍需从 Intel 获取的内容

P4 Insight GUI ：用于可视化 P4 程序编译后所使用的硬件资源。（社区正在与Intel沟通，或可将其作为开源发布）
部分 bfrt_python 代码：当前开源项目已包含了一些，但目前尚不清楚是否已包含使用它所需的所有部分。
BSP（板级支持包）：使 SDE 能够访问和配置物理板上的硬件，例如配置物理以太网端口并管理相关组件，如中继器、重定时器、SFP、QSFP 等。
ASIC 专用 Serdes 驱动程序：这些对于运行仿真模型不是必需的，但对于在真实 ASIC 上运行代码至关重要。

星融元X-T系列P4硬件平台

X-T系列：全开放、可编程、高性能的P4可编程硬件平台

X-T系列可编程交换机的主图

当前星融元X-T系列硬件平台规格包含：

48 x 25GE，8 x 100GE/40GE
32 x 100GE/40GE, 2 x 25GE
64 x 100GE/40GE, 2 x 25GE
32 x 400GE, 2 x 25GE
X-T 部分款型支持搭载2块DPU架构的ARM算力扣卡，从而实现x86（SONiC/ONIE/ONL）+P4（可编程高性能硬转发）+ DPU（自定义软转发）的全栈可编程硬件架构，满足高校、科研院所和产业界承载各类创新应用所需。

相关阅读：连接SONiC与P4交换芯片的SDE

P4可编程硬件平台产品开箱图
星融元将以稳定的产品供应支持和稳步推进中的高性能替代方案，为客户业务运行的连续性保驾护航。

RoCE与IB对比分析（二）：功能应用篇

近期文章

在上一篇中，我们对RoCE、IB的协议栈层级进行了详细的对比分析，二者本质没有不同，但基于实际应用的考量，RoCE在开放性、成本方面更胜一筹。本文我们将继续分析RoCE和IB在拥塞控制、QoS、ECMP三个关键功能中的性能表现。

拥塞控制

拥塞控制即用来减少丢包或者拥塞传播，是传输层的主要功能，但需要借助链路层和网络层的帮助。

RoCEv2 的拥塞控制机制

RoCEv2通过链路层PFC、网络层ECN、传输层DCQCN三者协同配合，实现更高效的拥塞管理，可见，RoCEv2虽然使用了IB的传输层协议，但在拥塞控制方面有所不同。

基于优先级的流量控制（PFC）

PFC在RoCEv2中被用于创建无损的以太网环境，确保RDMA流量不因链路层拥塞而丢失。核心原理是下游控制上游某个通道开启和停止发送数据包，控制方式是发送PFC Pause和Resume帧，触发时机是根据下游SW的ingress的队列数量是否达到某个阈值。

而PFC允许在一条以太网链路上创建8个虚拟通道，并为每条虚拟通道指定一个优先等级，允许单独暂停和重启其中任意一条虚拟通道，同时允许其它虚拟通道的流量无中断通过。这一方法使网络能够为单个虚拟链路创建无丢包类别的服务，使其能够与同一接口上的其它流量类型共存。

如图1所示，DeviceA发送接口分成了8个优先级队列，DeviceB接收接口有8个接收缓存（buffer），两者一一对应（报文优先级和接口队列存在着一一对应的映射关系），形成了网络中 8 个虚拟化通道，缓存大小不同使得各队列有不同的数据缓存能力。

当DeviceB的接口上某个接收缓存产生拥塞时，超过一定阈值（可设定为端口队列缓存的 1/2、3/4 等比例），DeviceB即向数据进入的方向（上游设备DeviceA）发送反压信号“STOP”，如图中第7个队列。

DeviceA接收到反压信号，会根据反压信号指示停止发送对应优先级队列的报文，并将数据存储在本地接口缓存。如果DeviceA本地接口缓存消耗超过阈值，则继续向上游反压，如此一级级反压，直到网络终端设备，从而消除网络节点因拥塞造成的丢包。

显式拥塞通知（ECN）

ECN（Explicit Congestion Notification）是一种IP头部用于的拥塞控制的标记位，允许网络设备在发生拥塞时标记数据包，而不是丢弃它们。

RoCEv2利用ECN位来标记发生拥塞的数据包，接收方在检测到ECN标记后，发送CNP（Congestion Notification Packet）给发送方，后者通过拥塞控制算法（如DCQCN）调整发送速率。

数据中心量化拥塞通知（DCQCN）

DCQCN（Data Center Quantized Congestion Notification）是一种适用于RoCEv2的拥塞控制算法，是数据中心TCP(DCTCP)和量化通知算法的结合，最初在SIGCOMM’15论文”Congestion control for large scale RDMA deployments”中提出。DC-QCN算法依赖于交换机端的ECN标记。结合了ECN和速率限制机制，工作在传输层。当接收方检测到ECN标记时，触发CNP发送给发送方，发送方根据反馈调整发送速率，从而缓解拥塞。

综上，PFC、ECN、DCQCN分别工作在链路层、网络层和传输层。在RoCEv2中，它们被组合使用，以实现更高效的拥塞管理。

PFC：防止数据包在链路层被丢弃，提供无损传输，解决一段链路的问题。
ECN/DCQCN：发送方根据拥塞标记主动调整发送速率，减轻网络负载。解决端到端网络的问题。

InfiniBand 的拥塞控制机制

InfiniBand 的拥塞控制机制可分为三个主要部分：

基于信用的流量控制

IB在链路层实现基于信用的流量控制（Credit-based Flow Control），该机制实现了无损传输，是 InfiniBand 高性能的基础。发送方根据接收方提供的信用（表示可用缓冲区空间）来控制数据包的发送，接收方在处理完数据包后发送信用给发送方，以允许继续发送新的数据包，从而避免网络拥塞和数据包丢失。

如下图所示，发送方当前可用信用值2，通过流水线传输（pipelined transfer）连续向接收方发送数据包，但此时接收方缓冲区已满，发送方会暂停发送新的数据包，直到接收方发送新的信用。

ECN机制

当网络中的交换机或其他设备检测到拥塞时，会在数据包的 IP 头中标记 ECN（Explicit Congestion Notification）。接收方的 CA（Channel Adapter）接收到带有 ECN 标记的数据包后，会生成拥塞通知包（CNP），并将其反馈给发送方，通知其网络出现拥塞需要降低传输速率。

端到端拥塞控制

发送方的 CA 在收到 CNP 后，根据 InfiniBand 拥塞控制算法调整发送速率。发送方首先降低数据发送速率以缓解拥塞，之后逐步恢复发送速率，直到再次检测到拥塞信号。这个动态调整过程帮助维持网络的稳定性和高效性。IBA没有具体定义特定的拥塞控制算法，通常由厂商定制实现。（HCA，Host Channel Adapters，or IB NIC）

RoCEv2与IB拥塞控制机制比较

两者的拥塞控制机制比较如下：

可见，RoCE与IB的拥塞控制机制基本相同，区别在于IB的拥塞控制机制集成度较高，通常由单个厂家提供从网卡到交换机的全套产品，由于厂商锁定，价格高昂。而RoCE的拥塞控制机制基于开放协议，可以由不同厂家的网卡和交换机来配合完成。

随着大规模AI训练和推理集群的扩展，集合通信流量导致了日益严重的拥塞控制问题，由此出现了一些新的拥塞控制技术，如基于In-band Network Telemetry (INT)的HPCC（High Precision Congestion Control），即通过精确的网络遥测来控制流量，以及基于Clear-to-Send (CTS)的Receiver-driven traffic admission，即通过接收方的流量准入控制来管理网络拥塞等。这些新技术在开放的以太网/IP网络上更容易实现。

QoS

在RDMA网络中，不光RDMA流量要获得优先保证。一些控制报文，如CNP、INT、CTS，也需要特别对待，以便将这些控制信号无损、优先的传输。

RoCEv2的QoS

在链路层，RoCEv2采用ETS机制，为不同的流量分配不同的优先级，为每个优先级提供带宽保证。

在网络层，RoCEv2则使用DSCP，结合PQ、WFQ等队列机制，为不同的流量分配不同的优先级和带宽，实现更精细的QoS。

InfiniBand的QoS

在链路层，IB采用SL、VL及它们之间的映射机制，将高优先级的流量分配到专门的VL，优先传输。虽然VL仲裁表 (VL Arbitration Table)能够通过分配不同的权重来影响和控制带宽的分配，但这种方式不能保证每个VL的带宽。

在网络层，IB的GRH支持8个bit的Traffic Class字段，用于在跨子网的时候提供不同的优先级，但同样无法保证带宽。

由此可见，RoCE能够为不同的流量类型提供更精细的QoS 保证和带宽控制，而 InfiniBand 只能提供优先级调度，而非带宽的明确保障。

ECMP

RoCE的ECMP

数据中心IP网络为了高可靠和可扩展性，通常采用Spine-Leaf等网络架构。它们通常在一对RoCE网卡之间提供了多条等价路径，为了实现负载平衡和提高网络拓扑的利用率，采用ECMP（Equal Cost Multiple Paths）技术。对于给定的数据包，RoCE交换机使用某些数据包字段上的哈希（Hash）值在可能的多条等价路径中进行选择。由于可靠传输的要求，同一个RDMA操作应当保持在同一个路径中，以避免由于不同路径造成的乱序问题。

在IP网络中，BGP/OSPF等协议均可以在任意拓扑上计算出等价路径，然后由交换机数据平面基于IP/UDP/TCP等头部字段（如五元组）计算哈希值并轮流转发到不同路径上。在RoCE网络中，为了进一步细分RDMA操作，可以进一步识别BTH头部中的目的QP信息，从而实施更细粒度的ECMP。

InfiniBand的ECMP

在控制平面，IB的路由基于子网管理器，在拓扑发现的基础上实现ECMP，但由于集中式的子网管理器与网络设备分离，可能无法及时感知网络拓扑的变化，进而实现动态的负载均衡。

在数据平面，IB的ECMP同样基于哈希计算和轮转机制。

总结

在拥塞控制方面，RoCE结合了PFC, ECN和DCQCN提供了一套开放的方案，IB则拥有基于Credit的一套高度集成的方案，但在应对大规模集合通信流量时均有所不足。
在QoS方面，RoCE可以实现每个优先级的带宽保证，而IB仅能实现高等级的优先转发。
在ECMP方面，两者均实现了基于Hash的负载分担。

总结来看，IB具备已验证的高性能和低延时优势，RoCEv2则在互操作性、开放性、成本效益方面更胜一筹，且从市场占比及认可度来看，RoCEv2逐渐比肩IB；但不得不承认的是，RoCE和IB在应对大规模AI训练和推理中高带宽、突发式和广播型的集合通信流量时，均有所不足，而RoCE基于其广泛的以太网生态系统，能够更快速地拥抱新技术新协议，其潜力和可塑性更胜一筹，未来有望在网络格局中扮演更重要的角色。

星融元提供一系列基于RoCE的开放网络产品与解决方案：

10G-800G的全场景互联：星融元CX-N数据中心交换机的单机转发时延（400ns）低至业界平均水平的1/4~1/5；采用BGP-EVPN、VXLAN、MC-LAG等技术构建可靠的大二层网络满足生产网络稳定性需求。
搭载开放网络操作系统：星融元AsterNOS以SONiC为内核、依托容器化的系统架构，并提供RESTful API支持第三方应用快速集成，或对接上层管理调度平台，例如OpenStack，K8s等。
EasyRoCE极简运维：支持无损网络一键部署，Prometheus + Grafana 可视化监控大屏配合专用命令行，问题快速定位解决。

参考文档：

https://zhuanlan.zhihu.com/p/643007675

https://blog.csdn.net/essencelite/article/details/135492115

https://support.huawei.com/enterprise/zh/doc/EDOC1100075566/d1e17776

https://www.researchgate.net/publication/4195833_Congestion_Control_in_InfiniBand_Networks

返回资源中心

云化园区

网络操作系统（SONiC）

可视交换机

开放硬件平台

标签： 技术实现

近期文章

名词解释

背景

工作原理

IP层对ECN的支持

IP层ECN报文交互

CNP报文格式

TCP层对ECN的支持

TCP层ECN报文交互

两个ECT Codepoints机制

Fast ECN

配置实例

网络拓扑

服务器端配置

交换机端配置

配置CISCO-LIKE命令行

交换机A

发送流量包

发送流量包

交机限速

观察拥塞情况

交换机A

Server1

配置交换机ECN功能

交换机A

Server1

Server2

观察ECN功能

清空流量包计数

发送IB流量

交换机A

Server1

参考资料

最新动态

关注星融元

只需三步

第一步：设备自动连接控制器

网络中已有DHCP Server —— 自动连接

网络中没有DHCP Server ——手动连接

第二步：自动生成拓扑和基础网络配置

第三步：批量配置无线和有线业务

无线业务配置

有线业务配置

关注星融元

业务架构

网络设计规划

自动生成配置

可视化呈现和远程下发

关注星融元

TIP：电信业“开源运动”领导者

01、ACC 界面概览

02、内生的资产管理能力

03、ACC带来的运维效率提升

关注星融元

为啥出错？

场景1：

场景2：

应对思路

更高效的实现方式

关注星融元

DeepSeek的优化，精细但门槛极高

回顾：AI推理集群的PD分离和流量特征

AI推理系统的 Scale-out 组网设计

Rail-only 拓扑

小规模并行推理网络拓扑

中大规模并行推理网络拓扑

关注星融元

为什么要有轨道优化？

如何配置多轨架构的智算网络？

主机侧的路由配置

交换机侧的主动路径规划

关注星融元

底层物理网络设计

终端IP地址规划和分配

两种不同类型的终端路由信息

标签：技术实现