从理想到现实：RDMA无损网络PFC配置的”血泪史”

在过去这段时间，我们从开始的用OSPF打通Underlay网络（双Spine架构实战：OSPF+ECMP打通智算中心任督二脉），再到使用BGP + EVPN + VXLAN技术搭建Overlay网络（从零搭建EVPN/VXLAN网络：4-Spine架构下的高性能Overlay完全配置指南，打通智算中心任督二脉），再到搭建4-Spine + 12-Leaf的Clos架构大规模集群（挑战极限！4-Spine+12-Leaf超大规模BGP/EVPN集群收敛性能的”终极考验”实战），到最终使用Border Leaf架构给智算网络集成外网出口（从东西向到南北向：Border Leaf如何实现智算中心网络的”全向通达”），都离不开EVE-NG的默默付出。

说实话，罗马不是一天建成的，没有什么成功是一蹴而就的，尤其是这样的大型网络模拟，光接线就有60根，配置更是上千行，一旦接错了，排查起来跑是要一个头两个大。

我自认为是比较细心的人，这么多次实验，接线一次都没错，但是EVE-NG的接线限制对我的实验也确实有影响，那就是设备一旦启动便无法再执行线路相关的调整，只能确认没问题之后再启动设备。

其实，这就是EVE-NG后台“节点运行时锁定接口”的限制，通过PHP逻辑和数据库验证做的强行限制。要解决，理论上很简单，修改EVE-NG后台的PHP逻辑，解除它在节点运行时对接口状态的锁定就行了。但实际上，如果你配置了，可能就会导致数据库和前端UI发生逻辑死锁，出现前后端脱节的情况。例如我试了一下，删除接线之后，两台设备认为连接还没有断，仍然可以通信。

所以说，如果你对线路的热插拔非常在意，可以试试PNETLab或者付费订阅EVE-NG Pro版，暂时不要尝试破解EVE-NG了。

回到我们的智算中心网络，虽然南北向的海关已经打通，但AI集群最核心的竞争力不是能上网，而是RDMA（RoCEv2）的极速互连，我们今天就要尝试攻克网络世界的珠穆朗玛峰——RDMA无损网络。

RDMA跑得快，全靠“无损”二字。完成从“尽力而为”到“绝对可靠”的跨越，全靠配置PFC（802.1Qbb），可以说，没有PFC，RDMA就是无米之炊。

本次实验，我们继续在上个实验的基础上进行操作。实验平台还是48核vCPU、96 GB内存的EVE-NG社区版6.2.0，实验设备配置为4-Spine + 4-Leaf + 8-Server 的标准Clos架构，并且配置Leaf1设备为Border Leaf上连接外网。组网拓扑图如下所示：

其中，Spine/Leaf交换机均使用Arista vEOS的4.35.1版本，资源配置为2核CPU、4 GB内存；服务器使用Ubuntu 20.04，资源配置为2核CPU、2 GB内存。Spine设备与Leaf设备之间的互联情况如下所示：

开始之前，我们先看看现在的网络容量有多大，我们使用Server3、Server5和Server7同时向Server2打流，使用Server4、Server6和Server8同时向Server1打流。

结果有点惨不忍睹，每条流差不多只有255 kbps，最大的也就是510 kbps，整体性能大概在2 Mbps左右。

我们再试试不跨Leaf设备的情况。

确实也没有好多少，最高只有1.27 Mbps，这么看单设备的性能确实不高。那单条转发路径带宽能有多少呢？

单条流的带宽值一直在255 kbps、510 kbps、765 kbps之间跳跃，平均带宽为406 kbps。

知道了基础性能怎么样，接下来，我们开始配置定义QoS映射并激活PFC和DCBX（数据中心桥接交换协议）。

注意，不要在所有优先级上开PFC，全开会导致控制协议流量（如BGP等）也被暂停，造成全网瘫痪。在大厂的生产环境，我们通常只在 Priority 3（RoCEv2 专用）上开PFC。正常情况下，还要将PFC与ECN搭配使用，PFC是暴力刹车，ECN是温柔减速。

本次实验，我们先聚焦PFC的PAUSE帧观察。需要在所有Spine设备和Leaf设备上都配置流量映射，将DSCP 24（CS3）映射到Priority 3，确保RoCEv2流量在每一跳都能进入那个不丢包的队列。

qos map dscp 24 to traffic-class 3
此外，PFC是一种端到端的背压机制，不是只在接服务器的接口上开就行，必须端到端启用。也就是说，从Leaf设备连接Server终端的接入侧接口，到Leaf设备连接Spine设备的物理上行口，再到Spine设备连接所有Leaf设备的物理下行口，全都都要开启PFC模式。因为拥塞往往发生在Spine设备往Leaf设备发包的下行链路上（Incast场景），如果中间有设备/接口没开PFC，会导致缓存满了直接丢包，根本不会给上游发PAUSE帧。

!
interface Ethernet1-4
priority-flow-control on
priority-flow-control priority 3 no-drop
而DCBX的主要作用是交换机和网卡之间对暗号，商量好大家用哪个优先级跑PFC，所以只需要在Leaf设备连接终端的接口上配置即可。

!
interface Ethernet5
dcbx mode ieee
但是，理想很丰满，现实很骨感，PFC是802.1Qbb协议，它极其依赖交换机芯片（ASIC）的Ingress/Egress Buffer阈值管理。Arista vEOS这个纯软件镜像，其转发代理主要是为了跑通协议逻辑，无法完美模拟出ASIC级别的队列挤压和PAUSE帧产生机制过程，配置命令直接报错。

我尝试了集中破解之法，都失败了，也给大家分享一下。

1、尝试在vEOS内部“暴力劫持”环境标识。

Arista vEOS启动时会检测vEOS_PLATFORM变量，如果这个变量被识别为普通Lab环境，它会为了稳定性禁用PFC。我尝试进Bash强行修改它，但是失败了，提示参数错误。

2、我查了一下Arista的内部调试指令，针对4.3.x以上版本，有个隐藏的硬件校验豁免开关，使用模拟器豁免命令可能能打开特定版本的隐藏开关。不过很不幸，还是失败了。

3、最后，还是从底层模拟器EVE-NG下手修改。在EVE-NG中，vEOS默认可能使用的是e1000这种老网卡驱动，在底层就不支持802.1Qbb。我们需要先关闭节点，然后在QEMU Options后面追加参数，尝试强制使用virtio-net-pci。

-device virtio-net-pci,netdev=net0,mac=50:00:00:01:00:01,mq=on,vectors=10
在很多实验中，只有这种驱动模式能让Arista的内核开启某些高级硬件加速特性的仿真。

但是，很不幸，修改之后这个节点再也起不来了。因为这个参数删不掉了！

尝试破解vEOS的PFC限制就像堂吉诃德战风车，虽然勇气可嘉，但注定徒劳。

理论上讲，在智算中心，多台Server同时向一个目标发送数据时（Incast场景），交换机缓存会瞬间爆满。在PFC网络中，当交换机缓存快满时，设备会向上游发送PAUSE帧，让上游缓一缓再发，从而实现零丢包。我们设计的让6台Server同时冲击Leaf1设备也是这个目的，企图打满Leaf1设备的上行接口。如果实验顺利，我们会看到接口下有PAUSE帧产生。

而在Server终端，即使即使时延变大，但丢包会一直维持为0，也就是领丢包。

纸上得来终觉浅，绝知此事要躬行。本次实验虽然未能成功配置PFC，但其价值远比一次成功的实验更加珍贵。失败是成功之母，这次经历为我们后续的真实设备测试积累了宝贵经验。它让我们清醒认识到：模拟环境与生产环境之间存在鸿沟，真正的RDMA无损网络需要专门的硬件支持。