从180秒到10毫秒：智算中心Underlay网络路由优化实战

先说个我最近遇到的真实场景。某智算中心机房做链路演练一条Leaf上联光纤被施工误剪整个训练集群立刻炸开——RDMA重传风暴、集合通信超时、checkpoint中断等告警推送、人工定位、手动把流量切到备用链路整整过去了180秒。回来后我对着事件时间线反复复盘把同场景下的故障切换时间压到了10毫秒0.01秒级别。这篇文章就聊聊智算中心Underlay网络路由优化这件事包括180秒是怎么被攒出来的以及从配置参数到验证方法我怎么一步步把时间降下来的。如果你正在做智算中心的规划、建设或者日常维护这篇内容应该能给你一些可以直接抄作业的参考。1. 180秒的病灶在哪智算中心Underlay收敛慢的完整链路1.1 智算中心Underlay网络的真实脾性智算中心跟传统数据中心最大的区别是它的网络要为一件事服务GPU集群的高速集合通信。无论是All-Reduce、All-to-All还是checkpoint阶段的大流量同步业务模型都是典型的多打一、多打多的大象流。为了保障RDMA流量不丢包Underlay网络普遍要开PFC优先级流控和ECN显式拥塞通知构造成无损网络。拓扑上主流方案是Spine-Leaf的CLOS架构Leaf接入GPU服务器Spine负责高速转发端口普遍是400G甚至800G起步。容量大、端口多、流量模型极端这是智算中心Underlay很直观的三个特征。但很多人容易忽略的一点在于这套网络的“脾性”决定了它对链路故障的容忍度极低。一条链路抖动可能引发上千台GPU之间的重传风暴业务侧的快慢是按照毫秒甚至是微秒计算的但传统网络控制面的收敛却是按照秒来跑的。这两者之间的时间差就是故障时业务中断的窗口也是我们需要下功夫优化的核心区域。1.2 180秒是怎么一步步攒出来的很多人以为是某个环节慢导致180秒其实它是多个环节串行叠加出来的复合结果。我从故障发生那一刻开始把时间链完整拆开来看。首先是故障检测层。如果链路上没有启用BFD只靠IGP自己的Hello机制来感知链路故障OSPF的Dead间隔默认是120秒IS-IS默认是30秒。就算你开了BFD如果用的是默认参数发送/接收间隔300ms乘数3检测到链路故障也需要900毫秒。也就是说光是“发现链路断了”这一步就可能已经过去1秒到2秒。接下来是协议扩散层。链路故障被发现后OSPF需要泛洪LSA、IS-IS需要泛洪LSP整个Spine-Leaf网络里的所有设备都要收到这个消息。在大规模智算中心里Leaf动辄几百台控制面消息在全网传播需要时间而且每一跳设备都要做处理、排队、转发。如果此时还有其他路由在抖动这个扩散过程会被拉得更长。然后是SPF计算层。收到拓扑变化后每台设备都要重新跑SPF算法。问题是OSPF/IS-IS的全量SPF计算会遍历所有prefix当全网有几万甚至十几万条路由时一次SPF计算要消耗几十到几百毫秒。并且协议默认还有SPF调度延迟和Holddown时间比如OSPF默认spf-start 5秒、spf-hold 10秒。注意是“默认”。很多运维团队根本没调过这些参数于是链路故障后全网设备按部就班地等了好几个定时器周期才开始重算。再往下是路由撤销与重宣告层。故障链路上的路由要撤销备用路径的路由要重新宣告IGP和BGP叠加时这个过程还要跨越协议边界。每多一层协议时间就多一截。最后是业务层和人工层。RDMA有自己的重传超时和拥塞控制退避集合通信库比如NCCL检测到通信异常后会触发自身的超时重试一次重试几十秒反复几次几分钟就过去了。再加上告警推送、人工确认、定位、手动切换180秒就是这么一步步攒出来的。我把典型的时间预算整理成了表格方便你直观感受阶段典型耗时说明物理层检测0~2秒取决于是否启用BFD、BFD参数、物理层告警联动协议扩散数百毫秒~数秒全网泛洪、队列处理、路由抖动叠加SPF计算数百毫秒~数秒默认定时器节流路由量大时更慢路由撤销/重宣告1秒~数十秒IGPBGP跨协议传播Flap Dampening惩罚业务层重试数十秒~分钟级RDMA超时重传、NCCL重连、checkpoint重试人工介入数分钟告警确认、定位、手动切换合计180秒左右这就是我那次实测的端到端时间1.3 传统方案为什么扛不住智算流量传统数据中心网络跑OSPF或者IS-IS收敛慢一点业务是“能忍”的因为HTTP请求超时了可以重试数据库连接断了可以重连。但智算流量完全不一样集合通信对链路故障几乎是零容忍RDMA流量一旦断流整个训练任务都要回滚重来。更深层的毛病在于传统方案的架构逻辑故障恢复依赖“全网设备协同收敛”。一台Leaf出问题全网所有设备都要感知、都要重算、都要切换。这种全局耦合的控制面在规模大到一定程度后收敛时间是不可控的而且故障半径很大——一台Leaf的抖动可能影响整个Fabric的路由表稳定性。再加上智算中心流量模型本身就容易放大问题。集合通信会把大量流量集中到少数链路上出现故障后流表重哈希可能导致流量瞬间涌向某一条剩余链路直接把那条链路也打满形成次生拥塞。用传统的“全网SPF重算”的思路去做智算Underlay本质上是拿错了工具。2. 优化路线选择砍控制面还是压榨路由协议2.1 两个流派的对决在做优化之前我调研过两条主流路线业内也一直有争论。路线A是“砍控制面”Spine和Leaf之间的Underlay完全不用动态路由协议只写静态路由然后用BFD做链路检测来联动路由切换。这么做最大的好处是故障恢复路径完全确定链路断了BFD检测到直接删掉对应路由转发面硬件快速把流量切到备用等价路径整个过程不依赖任何协议收敛没有全网风暴。坏处也很明显配置量巨大每台Leaf到每个Spine都要写静态路由而且后期加设备、改拓扑都要人工维护路由表规模大了之后运维成本会爆炸。路线B是“压榨协议”继续用IS-IS或者OSPF但是把所有收敛相关的定时器调到激进开启快速泛洪、快速SPF再加上TI-LFA或者SR-TE FRR这类快速重路由技术。好处是保留了动态拓扑感知能力网络自己能适应变化适合大规模和频繁变更的场景。坏处是参数激进之后容易震荡而且在某些厂商设备上激进参数在极端故障场景下反而会引入新的不稳定因素。这两条路线不是非此即彼。实际上在智算中心的真实部署里大部分团队做的是“分层组合”——不同网络位置用不同的策略。2.2 我的选型决策按规模分层我自己在实操里总结了一套选型逻辑核心是“把不同规模的问题用不同深度的方案去处理”。对于GPU服务器接入Leaf这一段我倾向于只用静态路由加BFD联动甚至直接用接口直连路由。这一段拓扑最稳定、变更最少写成静态路由之后故障切换动作非常确定不需要等任何协议。对于Leaf到Spine的Fabric核心段则要看规模。如果整个POD内的Leaf数量在200台以内我建议也用静态路由ECMPBFD的组合把控制面彻底简化。如果规模更大或者未来预期有频繁扩容可以考虑跑IS-IS Level-2但必须配上快速收敛参数和TI-LFA FRR。注意我不建议在智算Underlay里用OSPF原因无他OSPF的LSA洪泛机制在密集拓扑下会产生大量控制面消息收敛天生比IS-IS慢而且防环机制导致它对拓扑变化更敏感调激进参数后更容易出现问题。另外有一条铁律业务前缀绝对不允许进入IGP。Underlay的IGP只承载设备的Loopback地址和互联地址业务网段走BGP或者EVPN。这样就算业务路由再多再复杂也不会拖累Underlay的收敛速度。2.3 把优化目标量化成指标光说“快”没用做网络优化必须把目标拆成可量化的指标。我自己做规划时会直接写清楚每一项的期望值指标项传统网络典型值智算中心目标值优化手段链路故障检测900ms~2秒≤50msBFD激进参数、物理层联动备用路径切换秒级全网收敛≤10ms硬件重路由静态ECMP、硬件快速重哈希、FRR全网控制面收敛数秒~数十秒不依赖全网收敛控制面最小化、收敛域隔离业务无感知恢复不可控≤10msRDMA快速重传、无损网络配合这里要明确一个概念0.01秒这个数字指的是“流量快速切到备用链路业务无感知恢复”的时间并不是“全网所有设备路由表完成收敛”的时间。后者在大型网络里很难压到10ms也没必要。只要转发面上流量已经避开故障链路业务恢复了控制面慢慢收敛完不迟。理解了这一点后续的方案设计思路就清晰了。3. 从180秒到0.01秒落地配置与实测过程3.1 物理层检测最容易被忽略的第一道关口很多人一提到快速收敛就只想着改BFD却忽视了物理层其实是整个检测链条里最前端的一环。在智算环境里我强烈建议把光模块的数字诊断监控DOM和端口状态变化直接联动到网管平台并且把端口down事件作为BFD会话快速down掉的触发条件之一。这样链路物理断开的一瞬间系统就能在微秒级感知到信号丢失而不是傻等着BFD控制报文超时。实操中还有一个细节维护时如果要做端口shutdown应该在shutdown之前先把相关路由从控制面里摘掉等流量切换到备用路径后再down端口避免“路由还没切、端口先断了”造成不必要的丢包。反过来恢复链路时应该先把端口up起来再引入路由防止出现瞬时环路。3.2 BFD参数把故障检测压进毫秒级BFD双向转发检测是我们把故障检测从秒级压到毫秒级的核心工具。它的原理很简单两端设备以固定间隔互发检测报文如果在规定时间内没有收到对端的报文就判定链路故障。检测时间 发送间隔 × 乘数。所以要压检测时间就是调小发送间隔和乘数。我在智算中心的Leaf-Spine链路上用的典型配置是这样的# 以某主流厂商设备为例 bfd 1 bind peer-ip 10.0.0.2 interface Ten-GigabitEthernet1/0/1 min-transmit-interval 50 min-receive-interval 50 detect-multiplier 3按照这个配置理论检测时间就是50毫秒×3150毫秒。如果想让检测更快可以把间隔压到30ms、乘数压到2理论检测时间60毫秒。但我不建议在智算网络里把乘数调到2以下因为网络里偶尔会有微突发乘数太小容易造成误判反而引发不必要的路由震荡。实际部署里50ms×3是性能和稳定性之间的一个比较甜的点位。BFD参数需要和静态路由做联动才能发挥效果。以静态路由为例配置方式如下# 静态路由关联BFD会话 ip route-static 100.64.0.0 255.255.255.0 10.0.0.2 track bfd-session 1 # 等价备用路径 ip route-static 100.64.0.0 255.255.255.0 10.0.0.6 track bfd-session 2这里有个很关键的点BFD检测到链路故障后设备会立即把这条静态路由从路由表里删除转发芯片同时把该路径从ECMP组中移除。这一切都是本地动作根本不需要等全网任何设备回应所以切换时间能被压缩到几十毫秒级别。3.3 流量切换硬件ECMP重哈希与路由联动说句实话把故障检测时间压到150ms还不够真正的“速度与激情”在于转发面的快速切换。智算中心的Leaf通常都有多条上联Spine的链路流量通过ECMP在等价路径之间做哈希分担。链路故障时硬件转发芯片需要快速把原本走故障链路的流量重新哈希到剩余路径上。传统设备上这个重哈希依赖软件路由表更新完成后下发到硬件所以慢。但现在的智能网卡和可编程交换芯片普遍支持硬件级别的快速重路由FRRBFD会话down的通知直接送到转发芯片芯片在几毫秒内完成等价路径组的调整不需要等CPU参与。实际配置里除了静态ECMP也要关注设备是否支持“动态负载分担”或者“增强哈希”功能。智算环境里大象流很多如果哈希算法比较弱容易出现流量分布不均——某条链路已经打满了旁边链路还在闲置。启用增强哈希比如基于IP端口报文长度的哈希能明显改善这个问题。另外有条件的话建议在Leaf和Spine上都开启硬件BFD offload让BFD报文的收发和处理都在芯片上完成不消耗CPU资源检测时间可以做得更小且更稳定。3.4 端到端压测故障注入与时间线复盘配置做完不能光看得实测。我常用的故障注入方法是直接在Leaf的上联端口执行shutdown命令模拟链路故障观察业务受影响的时间。拔光纤更真实但操作上要确保安全所以我一般是先做端口shutdown测试再做拔纤抽测。下面是某次实测的时间线记录时间点事件耗时T0msLeaf上行端口shutdown物理层信号丢失0T1ms硬件感知端口downBFD会话进入down状态1msT50msBFD乘数3超时确认故障50msT52ms静态路由从控制面路由表中删除EGP通知芯片52msT55ms转发芯片更新ECMP组故障路径移除55msT58ms备用路径开始承载流量RDMA重传恢复58ms要说的是从180秒到58毫秒再到部分场景下10ms核心的差别不在于“改大改小某个参数”而在于收敛模式的变化——从“全网协同”变成了“本地即时切换”。你链路检测再快如果切换动作要等全网SPF收敛那60ms检测和150ms检测没有本质差别。所以整个链路里硬件FRR才是最值得投资的关键能力。当然所有测试都建议选择在业务低峰期并且要提前确认备用链路有足够的剩余容量。我在一次测试里就出现过流量全部切向备用链路后备用链路带宽不足导致拥塞的情况。这个不是网络收敛慢的问题是容量规划的问题但同样会导致业务受损。所以压测之前务必先算好剩余容量。4. 智算中心Underlay规划与维护的实战细节4.1 规划阶段就要埋好的伏笔优化到10ms级别的网络很多问题在规划阶段就已经注定了。我接手过不少“后期想改却无从下手”的智算中心网络基本都是规划阶段没想清楚几个关键问题。第一是收敛域划分。不要让Underlay的收敛范围无限扩大一个好的习惯是按POD划分收敛域Pod内部跑一套IGP或者静态路由POD之间用BGP/EVPN做互联。这样即便某个POD内部的网络出问题也不会把抖动扩散到整个园区。第二是地址和路由规划。Loopback地址用于控制面和管理面互联地址单独规划网段业务地址坚决不进入Underlay IGP。同时要做好路由汇总把Leaf下面的路由尽可能聚合成少量前缀减少全局路由表的规模和SPF计算的复杂度。第三是BFD资源预算。BFD会话需要芯片资源一台设备能够承载的BFD会话数是有限的。如果在规划阶段就确定“所有Leaf-Spine链路都跑BFD”那就要提前查清楚设备规格留出余量避免后期设备资源不够导致某些链路降级为普通检测。4.2 维护圈里的经典翻车现场就算规划和参数都做好了日常维护里还是有几个典型的坑。BFD误报震荡。有一段时间我遇到Leaf和Spine之间的BFD会话每天固定时间抖动一次查了很久发现是某个巡检脚本在那个时间点会往管理网段发大量报文导致控制平面瞬时拥塞BFD报文被延迟。这种问题排查起来极其隐蔽最后是通过抓包对比时间线才定位出来。经验是BFD的发送间隔一旦压到50ms以下控制平面的健康度就直接影响到网络稳定性巡检、备份、批量操作这一类任务必须避开高峰期。ECMP哈希不均。智算流量是大象流按照传统五元组哈希很可能让几条大象流刚好命中同一条链路造成单链路拥塞而其他链路闲置。我建议在Leaf上启用增强哈希算法并且关注设备是否支持自适应负载均衡。这块如果设备能力有限可以结合业务侧的流量调度来规避。PFC死锁与路由切换交织。链路故障瞬间PFC暂停帧可能已经传到了相邻端口造成缓冲区残留。此时即便路由切换完成某些端口也可能因为暂停状态短暂阻塞。解决思路是切换完成后不要急于flush缓冲区给RDMA重传一点时间同时监控队列长度确认没有死锁再继续后续操作。这一点需要和业务团队提前对齐“切换时允许的重传窗口”。4.3 可观测性和自动化把运维变成流水线参数再优化如果故障发生时你连“从哪一秒开始断的”都说不清楚那一切等于零。智算中心的网络运维必须把可观测性作为第一优先级。我现在的做法是所有关键设备开启Telemetry订阅秒级上报端口流量、BFD会话状态、ECMP成员变化、队列长度等指标。告警不再是“链路down”这种粗粒度事件而是能精细到“某条ECMP路径的成员在几秒内被移除”。有了这些数据故障复盘才能真正量化到毫秒级。同时我写了一套简单的巡检脚本定期检查全网BFD会话状态、静态路由关联关系、ECMP成员数是否一致。核心逻辑也不复杂就是轮询设备状态并做比对import requests # 伪代码示例实际需按设备API调整 devices [leaf-01, leaf-02, spine-01, spine-02] for dev in devices: bfd_sessions fetch_bfd_sessions(dev) for session in bfd_sessions: if session.state ! up: alert(f{dev} BFD会话异常: {session.peer}) print(f{dev} 检查完成BFD会话数: {len(bfd_sessions)})自动化脚本的价值不是替你决策而是把人工巡检的随机性去掉让每次巡检的标准一致。另外任何变更操作前建议先用配置校验工具做一遍模拟确认不会引入路由黑洞再上设备。我在经历过一次“改完BFD参数后Leaf失联”的教训后就养成了所有变更先过模拟环境的习惯。说到底智算中心Underlay网络优化的核心思想不是“把协议参数调到多激进”而是“尽量减少故障时的全网联动”。把故障边界尽量控制在单台设备、单条链路的范围内让流量在本地就完成快速切换。我在实操中最大的体会是永远要把“业务无感知恢复”作为目标而不是把“全网路由收敛”作为目标——这两者在智算场景里是两码事。最后再分享一个小细节多厂商设备混布时BFD的参数协商结果是取两端的最小公倍数也就是说两端配置不一致时实际检测时间往往比预期更差。所以进场施工的时候一定要先统一所有厂商的BFD参数基线并且在验收测试时逐条链路确认实际检测时长。否则你的0.01秒很可能只是配置表里的0.01秒。