1. 项目背景为什么180秒不可接受1.1 智算中心流量模型变了先还原一下那次故障现场。我们当时正在验收一个智算中心集群跑的是千卡规模的分布式训练任务网络架构是标准的Spine-Leaf两层Underlay底层跑IS-IS。突然监控大屏弹出十几个告警核心交换机之间的一根光纤链路出现误码紧接着Underlay路由开始重新收敛。结果这一收敛就是整整180秒——不是路由协议默认Hello超时的40秒而是在故障检测、SPF重算、路由表下发、流量回切几个环节层层叠加之后整个网络才恢复畅通。对于智算中心来说这种等待是无法接受的。传统数据中心的流量以南北向为主用户请求超时几秒可能只是体验变差但智算中心跑的是分布式并行训练每轮迭代里GPU之间要做AllReduce和梯度同步东西向流量占据绝对主导。链路一旦中断RoCEv2这类依赖无损传输的流量会立刻爆发丢包PFC死锁甚至能让整个集群网络瘫痪。训练框架检测到通信超时就回滚到最近的检查点180秒的故障直接意味着几百张加速卡白跑了几十分钟。1.2 180秒到底浪费在哪里很多人会问现在主流路由协议收敛不是很快吗怎么会有180秒问题就出在默认配置和极端场景的组合上。链路出现误码但不完全断掉的时候物理层不会立刻报Down设备只能靠BFD或Hello超时来感知。如果BFD没有配置IS-IS的Hello间隔默认是10秒检测失败可能需要30到40秒。检测到之后路由器开始重新计算SPF在几千条路由表项的设备上全网同步更新不是瞬时完成的期间还有路由策略、硬件转发表下发延迟。再加上当时设备上还有一些历史遗留的聚合链路和策略路由配置路由撤销和处理被反复延时最终把故障时间拖到了180秒。换句话说这180秒里真正花在路由计算上的时间并不多大部分时间浪费在检测慢、表项刷新慢、流量一直往黑洞里打。1.3 优化目标的拆解我们把故障恢复时间拆成了三段来看检测时间、切换时间、通告时间。链路故障后第一步是发现故障。物理硬故障可以用硬件信号检测但误码这种软故障必须靠BFD这类快速检测机制第二步是切换流量这一步不能等全网收敛必须在本地就有一张提前算好的备份路径表第三步才轮到向全网通告拓扑变化这个通告可以慢慢做因为流量已经在备份路径上跑了。我们的优化目标因此变得很清晰检测加切换控制在10毫秒量级也就是0.01秒全网路由收敛可以放宽到百毫秒甚至秒级只要不影响业务流量就行。如果每一步都靠故障发生后再去计算优化空间始终有限真正要做的是把备份路径预计算好让故障发生时流量可以瞬间切换。2. 方案选型与技术原理为什么选SR TI-LFA2.1 传统FRR方案的局限最开始我们考虑过传统的IP FRR比如LFALoop-Free Alternate。LFA的思路很简单当前节点找一个邻居这个邻居到达目的地不会经过故障点然后把备份下一跳指过去。听着很理想但在拓扑复杂、链路规划不规则的网络里LFA覆盖率常常只有百分之七八十。很多Leaf节点只有两条上行链路一旦其中一条断掉另一个邻居到某些目的地址的最短路径可能还要经过故障点这时LFA就失效了。后来也评估过Remote LFA引入PQ节点解决了一部分覆盖问题但仍依赖目标地址距离计算网络规模一大计算复杂度和收敛时间都跟着上来。这些方案本质上都是顺着最短路径树找旁路总有些场景覆盖不到。我们需要的是一个拓扑无关的方案也就是无论故障发生在哪条链路都能保证有一条备份路径。2.2 Segment Routing TI-LFA的组合TI-LFATopology Independent Loop-Free Alternate之所以能实现拓扑无关是因为它用Segment Routing的Segment List提前编码了一条备份路径。主路径是通过A节点到B节点A-B链路故障时备份路径不再只是简单地把流量丢给某个邻居而是封装一个显式的Segment List先走A-C再走C-D最后到目的地。这条路径预先已经通过SR的标签栈写进转发表故障时直接压标签转发根本不依赖其他节点是否完成了收敛。在这个方案里Underlay网关协议我们保留了IS-IS没有改成OSPF。原因也很简单智算中心Spine-Leaf规模大IS-IS在协议可扩展性、Level区域划分上更灵活同时IS-IS原生支持Segment Routing的扩展Prefix-SID可以直接在IGP里分发不需要维护额外的BGP-LU隧道。SR-MPLS的控制面开销比SRv6小硬件支持也非常成熟现在主流交换芯片都能线速处理SR-MPLS标签栈不存在性能瓶颈。这里要说明一下为什么不是SRv6。SRv6是未来的方向IPv6地址本身就是Segment可编程性更强但目前在智算中心里SRv6对硬件表项的要求更高报文封装开销也比SR-MPLS大。在没有硬性业务需求的情况下SR-MPLS是更稳、更成熟的选择。后续如果整个网络要平滑演进到SRv6我们的IS-IS SR设计思路完全能迁移只是把MPLS标签换成IPv6 Segment而已。2.3 TI-LFA如何实现10毫秒切换TI-LFA能做到毫秒级切换核心在于预计算。每台设备会针对每一条到达目的地址的路径提前计算好备份转发表项并且把备份路径的标签栈下发到硬件。故障发生时BFD或物理信号触发转发面硬件直接切换表项这个过程不涉及控制面计算不需要等SPF更不需要和全网设备协商。我们实测下来纯硬故障拔纤的检测在1毫秒以内备份路径转发表切换在几毫秒内完成一次故障恢复大概6到8毫秒。误码场景依靠BFD触发我们配置了10毫秒检测间隔、3倍超时也就是大约30毫秒内能感知到软故障。综合来看业务流量中断时间基本控制在10毫秒量级这就是标题里0.01秒的由来。需要注意的是这不是全网路由收敛到0.01秒而是流量恢复到0.01秒全网IGP收敛仍然需要几百毫秒但在这个过程中业务流量已经走在预计算的备份路径上了。2.4 Underlay与Overlay的分工再啰嗦一句Underlay和Overlay的关系。智算中心里Overlay常用VXLAN EVPN来承载租户隔离和虚拟网络但Overlay的控制平面依赖底层网络提供IP连通性尤其是Loopback地址之间的连通。我们这次优化的是Underlay的转发路径底层链路故障时Underlay快速切换到备份路径Loopback地址始终可达BGP会话就不会断EVPN表项也不会被撤销。如果Underlay停滞180秒BGP会话早就超时了EVPN重新建立、MAC地址重新学习那才是真正的灾难。所以Underlay路由优化是整个智算中心网络稳定性的基石这一步做不好上层再复杂的Overlay策略也是空中楼阁。3. 核心参数设计与配置实操3.1 BFD参数选择不是越快越好先看最关键的一个参数BFD。我们给IS-IS配置BFD检测标准的配置是这样的bfd interval 10 min-rx 10 multiplier 3 ! router isis 1 is-type level-2 net 49.0001.0000.0000.0001.00 fast-reroute ti-lfa segment-routing mpls ! interface Loopback0 ip address 10.0.0.1 255.255.255.255 isis prefix-sid index 101 ! interface GigabitEthernet0/0/1 ip router isis 1 isis circuit-type level-2 isis bfd bfd min-interval 10 min-rx 10 multiplier 3BFD的interval代表发送和接收报文间隔multiplier代表连续丢失多少个报文判定故障。10ms间隔、3倍超时意味着30ms没有收到对端BFD报文就宣告链路故障。这比默认的Hello检测快了一个数量级同时也避免了过度追求3.3ms检测间隔带来的风险。我见过有人为了极限性能把BFD配到3.3ms结果链条一抖动就误报路由频繁切换反而把网络搞得不稳定。智算中心链路数量多BFD报文占用的一定是硬件或CPU资源在设备和链路质量不够理想的情况下3.3ms只会放大抖动敏感度。10ms间隔已经是高性能和稳定性的平衡点。3.2 SRGB和Prefix-SID规划SR-MPLS的关键在于Segment Routing Global Block和Prefix-SID的规划。我们给所有Spine和Leaf设备的Loopback接口分配了全局唯一的Prefix-SID索引。segment-routing global-block 16000 23999这个SRGB是设备本地支持的标签范围16000到23999一共8000个标签对几百台设备的智算中心来说绰绰有余。规划时我们把Leaf设备索引分配在101-199Spine设备分配在201-299通过设备角色来划分段排查问题的时候一眼就能看出某台设备属于哪一层。Prefix-SID需要全局唯一否则不同设备通告相同SID会导致标签冲突转发面出现黑洞。3.3 TI-LFA配置的细节坑fast-reroute ti-lfa这一行看起来简单实际配置时要注意作用域。我们要在IS-IS进程下和接口下都确认配置生效同时注意SRGB下发顺序。我第一次操作的时候先启用了fast-reroute再配置segment-routing结果设备提示无法分配备份标签栈。正确的顺序是先配置全局SRGB再给Loopback分配prefix-sid最后启用TI-LFA。另外如果网络里存在level-1和level-2两种级别TI-LFA的保护也要分清。智算中心我们一般只跑level-2简化设计和排查。如果使用OSPF则要关注进程区域划分和Router-LSA的泛洪范围相比起来IS-IS更清爽一些。在实际实施时我们可以分批下发配置每台设备配置完成后用常规命令检查邻接状态、SID分发、备份路径表确认没有异常再配置下一台。任何时候都保留回滚手段比如commit confirmed避免批量配置导致全网震荡。3.4 等价路径下的备份路径策略智算中心Spine-Leaf架构里Leaf节点通常跟多个Spine建立等价链路流量本身就有多条ECMP路径。TI-LFA会对每条ECMP主路径分别计算备份路径配置命令上需要指定对哪些接口启用保护以及备份路径的偏好。我们在设计主备路径时还有一个原则主路径和备份路径尽量不在同一故障域。比如Leaf1上联Spine1为主、上联Spine2为备那么备份路径经过的节点和设备应该与主路径在物理上隔离比如不同的电源域和光缆方向。否则一个工程事故可能同时摧毁主备路径再快的切换也白搭。3.5 配置后必须检查的三张表配置完成不是只看业务通就完了。我们要分别检查IS-IS邻居、SR转发信息、TI-LFA保护覆盖率。show isis neighbors show segment-routing mpls forwarding show isis fast-reroute ti-lfa database第一条确认协议邻居正常第二条确认Label已经分配、转发表项已经下达硬件第三条是重点查看每条前缀是否都有备份路径保护以及备份路径的Segment List明细。如果某些前缀显示没有保护需要先解决否则故障发生时就可能出现流量黑洞。检查完这三张表才能说明Underlay的安全网已经铺好了。4. 实测优化过程与效果验证4.1 故障注入测试拔掉一根光纤优化完成后最紧张的就是做真实故障演练。我们在低峰期导出了一个正在跑训练的测试任务然后在业务流量通过的主路径上直接拔掉一根光纤。操作步骤大致如下先在训练任务的通信网段抓包建立基线延迟和吞吐数据。通知业务方开始一次可中断的短任务然后拔掉Spine到Leaf的主链路光纤。观察BFD状态变化、IS-IS收敛日志、转发面切换时间。记录抓包数据中是否存在丢包和重传。重新插回光纤观察流量是否回切回切过程中有没有形成环路。第一次拔纤的结果让我印象很深从拔下光纤到流量切到备份路径日志显示只用了约8毫秒业务侧几乎没有任何丢包训练任务继续跑监控面板上只有一次极其轻微的网络延迟抖动。对比优化前那次180秒的灾难完全是两个世界。4.2 实测结果对比我把优化前后的数据整理成了一张表关键指标优化前优化后链路故障检测时间需等待多个Hello周期约30-40秒BFD检测约10-30ms流量切换时间等待全网路由收敛累计180秒本地TI-LFA切换约8ms训练任务影响任务中断回滚检查点无感知任务持续运行BGP会话稳定性会话超时需重新建立会话保持无波动全网IGP收敛180秒后才稳定约200ms完成收敛这里要强调一点表格里全网IGP收敛优化后大概是200毫秒而不是0.01秒。实际上IGP收敛仍然需要向全网泛洪LSP、每台设备重新算SPF200毫秒已经是很好的成绩。业务零感知靠的是本地快速重路由而不是全网秒级收敛。理解这个差别才不会在实际运维中对着监控面板找收敛时间为什么不是10毫秒。4.3 测试过程中暴露的问题第一次测试其实并不完美。我们观察到部分Leaf设备上TI-LFA备份路径没有完全预计算排查发现是IS-IS进程里漏掉了ti-lfa protect的接口级配置。补上之后所有前缀的保护率才达到100%。另一个问题是设备型号差异。少数老型号交换机虽然支持SR-MPLS转发但在备份路径上对多播流量的处理存在缺陷。智算中心的集合通信有一部分多播流量如果多播报文走的备份路径没有被正确处理训练任务还是会出现类似网卡丢包的问题。我们最终把这些老型号设备排除在外只在支持完整的SR-MPLS硬件转发的设备上开启TI-LFA同时把多播流量单独引流到其他Plain路径上避免了兼容性隐患。在回切测试时还出现过一次短暂的微环。光纤插回去以后由于每台设备LSP更新和SPF计算完成的时间不一样部分设备先切回主路径另一部分设备还在走备份路径一瞬间形成了一个环路丢了几毫秒的包。这个现象我们放到下一章详细说。4.4 优化后的运维监控方案落地后我们在监控系统里增加了三块内容BFD会话状态和丢失率、TI-LFA保护覆盖率和设备上备份路径的Label命中次数、训练任务通信流量的重传统计。告警阈值也从网络设备接口Down这种大颗粒事件细化到了单台设备BFD会话状态变化和某条Prefix失去TI-LFA保护。这样网络还没真正中断只是保护缺失时就能提前发现问题。智算中心的网络规划从来不是上线就结束维护阶段的持续监控才能保证花大力气做的优化一直生效。5. 常见问题与排查技巧实录5.1 BFD误报导致路由振荡配置完BFD后最让人头疼的就是误报。特别是那些跨机房的长距离链路光衰波动幅度大BFD报文如果连续丢失三包设备就判定链路故障触发路由切换。切换本身是快但恢复后又会切回来整个网络在几分钟内一直抖动训练任务的TCP连接跟着遭殃。排查时先看show bfd session和接口光功率确认物理链路是否稳定。如果光模块和线路都没问题那就调整BFD参数把min-interval从10ms放宽到30msmultiplier从3调大到4或5。别觉得30ms就慢了对业务来说30ms依然远小于180秒稳定永远优先于极限性能。5.2 SRGB或SID冲突导致转发黑洞SR-MPLS环境里最隐蔽的问题就是标签冲突。有次新增了一台Leaf设备配置时模板复制漏改了prefix-sid index结果两台设备通告了相同的SID。症状表现为部分Leaf之间的流量能到达目的地但转发异常某些路径完全不通。检查SR转发表时能看到重复的标签映射整个网络里一半设备学到的下一跳是对的另一半学到的下一跳是那台错误的设备。这个问题只能靠规划保证再靠巡检发现。所有设备的Loopback IP和SID index要有一个全局清单新设备上线前必须比对。日常巡检时定期执行show segment-routing mpls forwarding检查有没有相同SID、相同Label被映射到不同前缀的情况。5.3 某些前缀保护覆盖率为空TI-LFA并非在所有场景下都能自动给出备份路径。遇到某条Prefix显示无保护时最常见的几个原因是接口没有开启isis fast-reroute ti-lfa保护备份路径经过的节点没有对应的Node SID或者链路两侧设备没有启用IS-IS的Segment Routing扩展。还有一种是备份路径的Segment List需要经过多个节点但某台设备不支持SR-MPLS的标签栈压入导致无法形成备份转发表项。排查思路是看show isis fast-reroute ti-lfa database里未保护前缀的明细再顺着路径分析每一跳。大多数情况都是配置缺失而不是算法缺陷补齐对应设备的SID分配和接口配置就能解决。5.4 故障恢复后出现微环之前提过的回切微环是IGP收敛过程中常见的现象。主路径恢复后设备A先收到LSP更新切回主路径把流量发给了设备B但设备B还没完成收敛以为备份路径还在于是又把流量发回设备A形成转发环路。现代IS-IS和OSPF都支持环路避免机制比如IS-IS的...我们用的命令是isis fast-reroute ti-lfa配合延迟收敛策略。另外运维上还会做一个操作恢复光纤前先等待几秒让LSP在网络里泛洪稳定或者人为置为最大cost待收敛后再恢复原cost。如果在恢复时不得不马上拔插光纤则建议关闭自动回切让流量继续走备份路径直到手动操作。5.5 Underlay切换后RDMA流量的余震Underlay做到10毫秒切换后仍不能说高枕无忧。RoCEv2网络对拥塞和丢包极度敏感即使只丢一个包可能触发重传严重时PFC死锁蔓延到多个交换节点。所以我们在设计无损网络时给RoCE流量走独立的队列并部署ECN而不是完全依赖Underlay快速重路由来保证无感。换句话说Underlay快速切换是兜底应用的可靠性还需要网络各个层面的协同。6. 个人心得与后续扩展说句实在话这次优化让我最大的收获不是学会配置TI-LFA而是真正理解了一个思路在智算中心这种对时间极其敏感的网络里很多问题不能等它发生了再解决要提前把答案写好故障发生时直接执行。这跟写代码做缓存是同一个道理——预计算永远比实时计算快几个数量级。如果你也在做智算中心的网络规划和维护我的建议是从一开始就把路由收敛时间纳入SLA指标。不要只盯着带宽和端口速率故障恢复时间同样会直接决定训练集群的可用性。用Segment Routing TI-LFA加BFD的组合是目前Underlay路由优化里成熟度最高、落地最平滑的方案。如果后续你的网络要支持更细粒度的流量调度可以考虑引入集中控制器和SRv6但也不需要为了追新而牺牲稳定性。最后再分享一个小技巧每次改完路由配置不要只在设备上测试通断一定要做一次真实的故障注入演练把光纤拔下来看看训练任务会不会感知。没有经过演练的优化都只是纸面上的数字。这次从180秒到0.01秒的跨越就是一次又一次拔光纤拔出来的。