1. 为什么MPLS TE的可靠性值得单独拿出来聊很多做网络运维的朋友对MPLS TE的态度是能跑就行毕竟标签转发路径一旦建立流量按显式路由走看起来比IGP逐跳转发可控得多。但真正在生产网里跑过几年的人都知道MPLS TE最让人头疼的不是能不能通而是断了之后多久能恢复、主备切换会不会丢包、带宽预留和实际转发是不是两回事。这些问题归结起来就是一个词——可靠性。我接触过的几个中型骨干网项目里MPLS TE最初上线时大家都觉得挺稳结果一次光纤被挖断RSVP-TE的路径重新计算花了将近两秒上面的语音业务直接炸了。后来复盘才发现问题不在协议本身而在于可靠性机制压根没配全。所以这篇内容我想把MPLS TE可靠性这件事从头到尾拆一遍包括它到底靠哪些机制撑住、每种机制的适用边界在哪、配置时哪些参数是看起来无所谓但关键时刻要命的。这篇文章适合已经了解MPLS基本转发原理、正在或准备在生产网里部署TE隧道的网络工程师。如果你还在纠结MPLS是什么这个层面建议先把标签分发和LDP的基础过一遍再来看。下面我会按故障从哪来→靠什么扛→怎么配→怎么验→怎么避坑这条线展开尽量把每个机制的为什么讲透而不是只丢一堆命令。2. MPLS TE隧道的故障来源到底有哪几类要把可靠性做好第一步不是急着配FRR或者调定时器而是先搞清楚一条TE隧道可能因为什么原因失效。不同故障源的恢复手段完全不同用错了机制等于白配。2.1 链路级故障与节点级故障的区别链路级故障指的是两台直连设备之间的物理链路断了比如光纤被挖、光模块挂了、端口err-disable。这种故障的特点是IGP会很快感知到通常靠Hello或BFD然后触发TE隧道的重优化或重建。节点级故障则是整台设备宕机或重启影响面更大因为所有经过这个节点的TE隧道都要重新算路。这两者的关键差异在于链路故障时如果配了链路保护比如FRR的Bypass隧道流量可以在本地几十毫秒内切走而节点故障往往需要依赖IGP收敛加上RSVP重新信令恢复时间通常在几百毫秒到秒级。所以你在设计可靠性方案时必须区分我能容忍链路断和我能容忍节点挂这两种场景它们的SLA要求可能差一个数量级。2.2 控制平面故障与转发平面故障这是最容易被混淆的一类。控制平面故障指的是RSVP-TE的信令断了、Path消息收不到、Resv状态超时但转发平面的标签转发表项还在流量其实还能走。转发平面故障则是标签转发表项丢了或者硬件转发出问题流量直接断。我见过一个案例某台设备的RSVP进程因为内存泄漏重启了控制平面短暂中断但因为转发平面没动业务其实没受影响。结果运维看到告警就急着重启设备反而把转发也搞断了。所以理解这个区分很重要——不是所有控制平面的抖动都需要立即干预有些情况下让它自己恢复比手动介入更安全。2.3 带宽抢占与资源不足导致的隐性失效这一类最隐蔽。TE隧道建立了标签也通了但因为带宽预留没做好当高优先级隧道建立时把低优先级隧道的带宽抢走了低优先级隧道虽然还在但实际转发质量严重下降。或者更糟的情况隧道因为找不到满足带宽约束的路径而无法建立业务直接黑掉。这种隐性失效不会触发链路告警监控上看起来一切正常只有业务侧能感知到。所以可靠性设计里必须包含带宽约束的校验和抢占优先级的规划不能只盯着隧道UP没UP。3. RSVP-TE的信令可靠性靠什么撑住RSVP-TE是MPLS TE的控制核心它的可靠性直接决定了隧道能不能稳定维持。很多人配完隧道就不管了其实RSVP层面有一堆参数决定了它在网络抖动时的表现。3.1 Refresh机制与Srefresh的取舍RSVP-TE默认靠周期性的Path和Resv消息刷新状态这个周期由refresh-time控制默认30秒。问题是30秒的刷新周期意味着状态超时时间通常是刷新周期的3倍也就是90秒。如果中间丢了几条刷新消息隧道可能被误判为失效。后来引入了Summary RefreshSrefresh它把多个LSP的刷新消息合并成一条减少了消息数量同时配合reliable messaging可靠消息传递机制通过消息ID和确认机制保证刷新不丢。我的建议是在中大型网络里一定要开Srefresh加reliable messaging否则RSVP消息量会随LSP数量线性增长控制平面压力很大。配置上大致是这样mpls rsvp refresh reduction reliablerefresh reduction开启后刷新周期可以适当调长因为有了确认机制不需要靠高频刷新来保证可靠性。但注意调长刷新周期会延长故障检测时间需要和BFD配合使用。3.2 Hello机制与BFD的分工RSVP Hello是用来检测邻居可达性的默认周期比较长通常几秒到十几秒检测粒度粗。BFD则是毫秒级的快速检测。两者不是替代关系而是互补Hello负责RSVP层面的邻居状态维护BFD负责快速感知链路或邻居故障并触发保护切换。实际部署中我通常这样分工BFD用于触发FRR的快速切换Hello用于RSVP会话的保活。如果只开BFD不开HelloRSVP会话在某些异常场景下可能状态不一致如果只开Hello不开BFD故障检测太慢FRR根本来不及切。注意BFD的检测倍数不要设得太激进。我见过有人把multiplier设成3、min-interval设成50ms结果网络稍有抖动就频繁切换反而造成震荡。一般建议min-interval不低于100msmultiplier用3到5之间。3.3 信令重路由的触发条件当RSVP检测到路径失效时会触发重路由。重路由有两种模式一种是本地修复靠FRR一种是头端重算路径。头端重算依赖IGP收敛后的CSPF计算所以IGP收敛速度直接决定了重路由速度。这里有个容易忽略的点CSPF计算需要完整的TE拓扑数据库如果IGP的TE扩展比如OSPF-TE或IS-IS-TE没有正确泛洪CSPF可能算不出可行路径。所以部署时要确认TE链路信息确实在IGP里泛洪了可以用show mpls traffic-eng topology来验证。4. FRR快速重路由把恢复时间压到50ms以内的关键FRR是MPLS TE可靠性里最核心的机制没有之一。它的目标是在链路或节点故障时由本地设备直接把流量切到预先建立的备份路径上不依赖头端重算从而把恢复时间压到50ms以内。4.1 链路保护与节点保护的实现差异链路保护Link Protection是为每条被保护链路预先建立一条Bypass隧道绕过这条链路。当链路故障时本地设备把流量导入Bypass隧道从下一跳的再下一跳出去。节点保护Node Protection则是绕过整个下一跳节点Bypass隧道的终点是下下一跳。节点保护的覆盖范围更广但建立Bypass隧道时需要更多资源因为要绕过的距离更长。实际部署中我通常建议在核心层用节点保护在接入层用链路保护这样在资源消耗和保护范围之间取平衡。配置Bypass隧道时有个关键参数是bandwidth。如果Bypass隧道不预留带宽故障切换后可能因为带宽不足导致业务质量下降。但预留太多又浪费资源。我的经验是按被保护链路带宽的50%到70%预留具体看业务模型。4.2 Bypass隧道的自动创建与手动创建Bypass隧道可以手动配也可以用auto-tunnel自动创建。自动创建的好处是省事设备会根据拓扑自动为每条链路或每个节点建立Bypass。但自动创建有个坑它可能建立的Bypass路径不是你期望的比如绕了一条你不想用的链路。手动创建虽然麻烦但可控性强。在关键链路上我倾向于手动指定Bypass的显式路径确保备份路径的质量。自动创建适合拓扑规整、链路质量差异不大的场景。interface tunnel100 tunnel mode mpls traffic-eng tunnel destination 10.0.0.2 tunnel mpls traffic-eng path-option 10 explicit name BYPASS-PATH tunnel mpls traffic-eng protectiontunnel mpls traffic-eng protection这条命令是告诉设备这条隧道可以作为Bypass使用。4.3 备份路径的带宽与亲和属性校验FRR切换后流量会走Bypass隧道。如果Bypass隧道的带宽不够或者它的亲和属性affinity和被保护隧道冲突切换可能失败或者质量下降。所以配置Bypass时一定要校验这两点。亲和属性这块特别容易出问题。比如被保护隧道要求排除某类链路但Bypass隧道没有这个约束结果Bypass走了被排除的链路虽然通了但违反了策略。建议在Bypass隧道上也配置相同的亲和属性保持一致性。5. 路径计算与重优化中的可靠性考量TE隧道的路径不是建好就一劳永逸的网络拓扑变化、带宽变化都会触发重优化。重优化本身是好事但如果不加控制频繁重优化会造成流量震荡。5.1 重优化的触发时机与抑制策略重优化通常在IGP拓扑变化后触发设备会重新计算一条更优路径并切换。问题是如果网络频繁抖动重优化就会频繁发生每次切换都有短暂的流量中断风险。抑制策略主要有两个一是设置重优化的最小间隔reoptimize timer二是用make-before-break机制确保新路径建立后再切流量。make-before-break是必须开的它保证切换过程中不丢包。最小间隔建议设在300秒以上避免频繁重优化。5.2 路径锁定与显式路径的可靠性权衡显式路径explicit path可以精确控制流量走向但缺点是如果路径上的某条链路失效隧道可能无法重建因为显式路径是固定的。动态路径dynamic path灵活但不可控。实际做法通常是混合主路径用显式路径保证可控性备用路径用动态路径保证灵活性。配置多个path-option按优先级排列tunnel mpls traffic-eng path-option 10 explicit name PRIMARY tunnel mpls traffic-eng path-option 20 dynamic这样主路径失效时设备会自动尝试动态路径重建。5.3 带宽约束下的CSPF计算陷阱CSPF计算时会考虑带宽约束但有个陷阱它只看链路的预留带宽不看实际流量。如果链路上有大量未预留的流量CSPF可能算出一条看起来有带宽但实际拥塞的路径。所以带宽规划不能只依赖CSPF还要结合实际流量监控。我通常建议在核心链路上保留20%到30%的余量不要把所有带宽都预留出去。6. 实测验证怎么确认可靠性机制真的生效了配完不代表生效必须实测。下面是我常用的验证方法按从简单到复杂的顺序。6.1 用show命令确认保护状态最基本的检查是看Bypass隧道和被保护隧道的关系show mpls traffic-eng fast-reroute database show mpls traffic-eng tunnels protection输出里会显示每条被保护链路对应的Bypass隧道以及保护状态是Ready还是Active。Ready表示Bypass已建立待用Active表示正在保护。如果显示None说明保护没配上。6.2 模拟故障切换的实操步骤光看状态不够要实际制造故障验证切换。我通常这样做先起一个持续ping然后shutdown被保护链路观察丢包数量。理想情况下丢包应该在几个到十几个之间对应50ms以内的切换。ping 10.0.0.2 repeat 1000 timeout 1然后在另一个终端shutdown接口。切换完成后看ping的丢包统计。如果丢包超过50个说明切换时间超过50ms需要检查BFD配置或Bypass隧道状态。6.3 切换后的路径与带宽复核切换完成后要确认流量确实走了Bypass隧道而且带宽够用show mpls traffic-eng tunnels brief show interface tunnel100看Bypass隧道的流量计数是否增长以及是否有丢包或拥塞告警。如果Bypass隧道带宽不足可能会看到output drops。7. 那些年踩过的坑与配置心得最后这部分是我在实际项目里踩过的坑有些是配置问题有些是理解偏差希望能帮你少走弯路。7.1 BFD与RSVP定时器不匹配导致的震荡有一次我把BFD的检测时间设成100ms但RSVP的Hello周期还是默认的10秒。结果链路轻微抖动时BFD先感知到故障触发切换但RSVP还没反应过来等RSVP也感知到故障时又触发了一次重路由造成二次切换。后来把两者的检测时间做了匹配问题才解决。经验是BFD和RSVP的故障检测时间要协调BFD负责快速切换RSVP负责状态维护不要让它们互相打架。7.2 自动Bypass隧道选错路径的排查过程自动Bypass有时候会选一条经过高延迟链路的路径切换后业务质量下降。排查时用show mpls traffic-eng tunnels看Bypass的实际路径发现它绕了一条备份链路。解决办法是给Bypass隧道加亲和属性约束排除高延迟链路。7.3 带宽预留与实际转发的偏差这个坑很常见隧道预留了100M带宽但实际转发时因为标签栈深度、MTU分片等原因有效带宽可能只有90M左右。如果业务按100M规划就会出问题。建议预留时多留10%的余量并且实测转发带宽。7.4 重优化期间流量中断的定位有一次重优化时业务断了2秒排查发现是make-before-break没开。开了之后重优化就变成无缝切换了。这个命令是mpls traffic-eng reoptimize相关的具体在隧道配置里加make-before-break。7.5 多厂商互通时的保护兼容性不同厂商对FRR的实现有差异互通时Bypass隧道可能建不起来。我遇到过一家设备不支持节点保护只能做链路保护。这种情况下要么统一厂商要么在边界设备上做特殊处理。互通测试一定要提前做别等上线了才发现。8. 写在最后的一点个人体会MPLS TE可靠性这件事说到底不是配几条命令的问题而是要对故障从哪来、靠什么扛、扛不住怎么办这条链路有完整的认知。我见过太多项目把FRR配上了就觉得万事大吉结果真出故障时发现Bypass隧道带宽不够、或者BFD和RSVP打架、或者重优化把流量切丢了。我的建议是每配一个可靠性机制都要问自己三个问题——它防的是什么故障它的恢复时间是多少它失效时有没有兜底把这三个问题答清楚了可靠性设计才算及格。另外实验室验证和现网验证是两回事现网的流量模型、拓扑复杂度、设备差异都会影响可靠性表现上线前一定要做故障注入测试别怕麻烦。