1. 先搞清楚IS-IS GR到底在解决什么问题1.1 没有GR的时候路由器重启有多痛工作在骨干网、城域网或者大型数据中心出口的人对IS-IS应该都不陌生。这个链路状态路由协议依靠Hello报文维护邻居依靠LSP泛洪让全网LSDB保持一致最后用SPF算法算出一棵无环路由树。整个流程非常成熟可一旦设备需要重启问题就来了协议进程一停接口上的邻居关系立刻DownHoldtime超时之后这台设备通告出去的LSP会在全网被老化删除每一台收到拓扑变化的路由器都会重新跑一次SPF。这个连锁反应一展开就是全网路由大面积震荡数据面丢包严重的时候业务中断好几分钟。我曾经经历过一次典型的场景骨干设备升级主控软件需要整机重启。原本觉得AB两台设备互为备份断一台问题不大。结果发现根本不是“一台设备断掉”这么简单——它重启后LSP老化其他区域也收到大量路由变化反复计算转发面长时间不稳定业务侧投诉不断。那会儿我的想法很直接如果协议能“假装这台设备没重启过”上游用户就不会有任何感知。IS-IS GR解决的就是这个核心痛点。1.2 GR的核心思想就是把“重启”变成“会话保留”优雅重启GRGraceful Restart的本质是借助邻居的配合让协议进程重启期间邻居仍然认为设备可达不删除路由信息也不触发全网SPF重算。设备重启完成后不再是把自己当作一台新设备从零开始建立邻居关系而是借助邻居的LSDB快速恢复自己的数据库收敛时间大幅缩短。可以这么理解普通重启相当于把整条链路推倒重来邻居要重新协商路由要重新学GR则像家里突然停电邻居帮忙看着冰箱里的食材你只是把电闸推回去食材没坏回来继续做饭就行。但这里有一个前提必须说清楚——GR不是设备单独完成的它严重依赖邻居。只有邻居配合你“假装你没重启”GR才成立。如果邻居不支持GR或者配置上关闭了Helper能力那重启设备就退化成普通重启邻居关系重新建立该震荡还得震荡。这也是后面排障时最先要确认的方向。1.3 两个角色Restarting Router与Helper RouterGR过程中有两个固定角色。重启的那台设备叫Restarting Router重启方负责保留转发面表项在协议重启后恢复控制面状态其他配合它的邻居叫Helper Router辅助方负责在邻居重启期间继续维护这条邻居关系不删除对方通告的LSP并在重启方恢复后帮它同步LSDB。这里有一个容易被忽略的细节一台设备可能同时既是重启方也是某个邻居的Helper角色吗可以。比如一个网段里有三台路由器连在一起A重启时B帮A做Helper同时C也在重启那B又可以是C的Helper。只不过在实际网络里如果同一时间有多台设备重启互相之间的GR协商就会变得复杂很多设备在实现上会直接回退为普通重启。这也是为什么运维上有一个不成文的规矩整网做GR相关变更时一次只重启一台设备不要在拓扑里同时动两台以上。2. IS-IS GR的工作流程与状态机2.1 报文交互藏在IIH里的Restart TLVIS-IS的GR标准来自RFC 5306。它没有单独发明一种新报文而是在IS-IS的Hello报文IIH里扩展了一个Restart TLVTLV 211用一组标志位来传递GR状态。常见的标志位有RRRestarting表示重启方状态、RARestart Acknowledgement确认响应、SASuppress Adjacency抑制邻接通告等。用最简单的场景来说。路由器A要重启了它在接口上发送的IIH里带上RR标志意思是“我要重启了各位兄弟当没看见别把我的邻居关系删了”。邻居B收到带RR标志的IIH后识别出A正在执行GR于是B进入Helper状态不删除与A的邻接关系同时在LSP泛洪时继续保留A的LSDB并在拓扑中通告A仍然可达。随后A完成协议重启在数据库中学习到足够的LSP后发送撤销RR标志的IIH表示“我恢复过来了”双方恢复正常IS-IS邻居关系。这个报文交互过程在Wireshark里抓包看也非常直观。过滤IS-IS IIH报文展开TLV列表能看到211号TLV以及里面的标志位变化。排障时判断一台设备是否真的在执行GR第一件事就是看它的IIH里有没有带RR。如果配置了GR但抓包始终看不到RR标志那多半是配置下发后没有重新建立进程或者设备版本把特性隐藏了。2.2 状态机的视角GR期间邻居状态为什么一直是UpIS-IS邻居状态机本身有三个主状态Down、Init、Up。普通重启时邻居关系从Up直接掉到Down然后重新经历Init再到Up。GR的特殊之处在于在邻居侧看来与重启方的邻居关系始终保持Up并没有真正Down过。但重启方内部并不是真的“一切正常”。它会进入一个GR Recovery状态对外宣称邻居关系已经恢复但内部LSDB还没同步完也不会立刻参与SPF计算。这个状态的名字在不同厂商实现里略有区别但含义一致——它就是GR流程中的中间态。邻居侧则进入GR Helper状态持续维持与重启方之间的Hello处理并在LSP刷新方向保持克制不因为LSP超时就把对方标记为离开。有一个细节值得展开在广播网络中如果DIS路由器重启并执行GR情况会相对复杂。IS-IS广播网络依赖DIS周期发送CSNP来维护数据库同步如果DIS本身正在GR其他非DIS路由器并不会主动承担DIS职责必须等到DIS恢复。这时候如果网络规模很大广播链路上的数据库同步速度会成为GR恢复时间的主要瓶颈。所以广播网络中的GR恢复时间通常比点对点链路要更长配置T3时需要留出余量。2.3 恢复阶段CSNP/PSNP是怎么配合用的IS-IS数据库同步在广播网络和点对点网络上用的机制不一样。GR恢复阶段两种网络的差异也很明显。在广播网络里DIS会周期性发送CSNP这个CSNP等于一个数据库汇总目录。重启方收到CSNP后拿它和自己的LSDB做比对发现自己缺哪些LSP就通过PSNP去请求邻居收到PSNP再把对应的LSP发给它。而在点对点网络里链路建立时只发送一次CSNP之后主要靠PSNP按需请求。GR初始化过程中Point-to-Point链路同样是先收到邻居发来的CSNP再做差异比对和缺失请求。无论哪种网络形态GR恢复的核心理念是一样的不是让重启方从零开始泛洪学习而是借着邻居的帮助以CSNP为“目录”做一次快速比对和差异同步。这也是GR能够大幅缩短收敛时间的根本原因。需要额外提醒一句GR全程中Helper一侧的LSP老化时间并不会因为进入Helper状态而自动停止它必须靠实现上主动延长或冻结相关LSP的剩余生命周期。如果Helper设备没有做这一层处理GR恢复还没完成对方的LSP可能已经在全网被老化删除了。2.4 三个定时器T1、T2、T3的设计逻辑IS-IS GR定义了三层定时器理解它们互相之间的包含关系比死记命令里的参数更有用。T1是重启方首次发送带RR标志的IIH之后等待邻居确认报文的时间。如果在这个窗口内没有收到邻居的任何响应重启方会再次发送初始化IIH同时增加重试计数。T1默认通常为30秒重试次数可以按需调整。T2是等待LSP数据库同步完成的时间。重启方从邻居收到CSNP、执行差异比对并请求缺失LSP整个过程不应该超过这个窗口。默认一般是60秒比T1稍长因为LSP同步涉及实际数据传送。T3是整个GR过程的上限默认通常是300秒。它同时也是整个调度逻辑里的兜底机制无论T1和T2设成多少整机重启总时长不能超过T3。如果T3超时还没完成数据库同步GR就宣告失败回退为普通重启所有邻居关系重新建立。理解T1、T2、T3的嵌套关系有一个生活化的类比T1是等一个快递回执T2是等所有快递全部送达T3则是这一单业务能忍受的最晚时间。超过最晚时间只能取消订单走紧急预案。实际配置中多数厂商允许修改T3常见做法是把T3与设备的主备切换时间、板卡加载时间对齐既留足余量又不要大到把故障影响窗口拖得过长。3. 配置IS-IS GR的实操步骤与验证这一节我以运维视角整理一套从设备检查、系统配置到验证收尾的完整流程。考虑到不同厂商的命令风格有差异我不逐条贴某个品牌的私有命令而是把关键配置项和命令形态讲清楚大家照着自家设备的对应命令去查就行。3.1 动手前先回答三个问题配置GR之前先确认三件事这台设备是否支持IS-IS GR如果支持是只支持Helper模式还是同时支持Restarting模式设备的软件版本和授权是否覆盖了GR特性有些中低端型号虽然支持IS-IS但GR功能默认不启用需要额外开启。网络的邻居设备是否也支持GR如果一半支持一半不支持整体效果会大打折扣。这些问题看着简单实际翻车的人很多。曾经在一个多厂商混合组网的项目里A设备的默认配置是开启GRB设备完全没开。A设备重启时B设备按普通重启流程直接删了邻居关系整个收敛过程不但没变快反而因为A的GR等待逻辑和B的下删逻辑互相干扰比完全不开GR还慢。所以配置GR之前第一步永远是让两端能力对齐。3.2 配置步骤以主流设备为例多数主流网络设备的配置流程是这样先进入IS-IS进程视图开启GR相关开关命令形态类似graceful-restart部分产品叫nsf含义一致。随后设置T3的值比如把整机最大重启时间改成300秒对应命令一般可以在IS-IS进程下配置比如graceful-restart t3 timer 300。一些设备还支持严格模式如果邻居没有通告支持GR这侧就拒绝配合或拒绝发起GR。严格模式能提升一致性但也会带来兼容性问题现网建议按需开启。如果设备多条链路同时承担转发业务通常还会建议开启与接口保障相关的联动参数确保重启期间各链路转发面不因协议进程停摆而全部失效。另外很多设备支持带内控制通道和带外控制通道的概念。简单说带内GR依赖转发平面还能工作时的数据通道来同步控制信息带外GR则依赖专门的控制通道。绝大多数现网设备默认跑带内GR因为控制通道已经随物理链路建立起来了。配置时不需要纠结选哪种但要清楚自己设备的控制方式排查时就不会被报文流向带偏。3.3 让GR真正起作用与BGP GR的联动IS-IS GR保护的是IS-IS协议自身产生的路由。但承载业务的往往不只是IS-IS还有BGP。如果IS-IS做了GR而BGP没做IS-IS层面邻居关系虽然保住了设备重启期间BGP邻居却断掉了BGP路由全部重新收敛业务该丢包还是丢包。所以面向业务不中断的目标IS-IS GR通常会和BGP GR、MPLS GR一起启用。BGP GR靠另一套机制实现核心概念包括Peer Active标志和Stale Route原理不一样但目标一致。配好IS-IS GR之后再往上看一层把BGP GR、LDP会话保护这些全部检查一遍才算是完整方案。更进一步很多高端设备支持NSRNon-Stop Routing。NSR不需要邻居配合而是通过主备板卡协议状态实时同步在主控切换时由备板无缝接管邻居完全感知不到。相比GRNSR更彻底但资源开销更大对硬件要求也更高。现在的高端设备通常两种模式都支持具体选哪种要看设备能力、业务级别和运维习惯。GR更适合兼容性要求高的多厂商混合网络NSR更适合单一厂商的高端框式设备。3.4 配置验证的检查清单GR配置完成后用几条查询命令验证状态基本就能确定配置是否生效查看设备GR能力与状态。关注本地GR状态是否为Capable或Active如果显示Disabled说明特性没真正打开。查看邻居设备的GR能力。确保每个关键邻居的协商结果都是支持并启用只要有一个不支持就要评估影响范围。查看GR统计信息。关注LSP同步计数、回退事件计数。如果回退事件频繁说明GR配置或邻居配合存在问题。做完静态检查后更稳妥的做法是在变更窗口内选一台低峰期设备做一次冷切换或者主备切换演练观察整网是否出现路由震荡。这是最直观的验证方式不要在业务高峰期临时验证所有GR相关操作都应该有预案。4. 常见问题与排查技巧实录4.1 现象一GR倒计时超时回退为普通重启最典型的故障表现是设备执行重启后相邻路由器的日志里出现邻居Down然后重新UpGR状态从Recovery直接跳成Normal或者统计信息中显示多次Restart Failed。第一步确认邻居有没有真正进入Helper状态。可以找一台直连设备查邻居详情看看它是否识别了对方的GR标志。如果邻居侧没有进入Helper通常是因为它没开GR或版本不支持。第二步分析为什么在限定时间内没有完成数据库同步。常见原因是链路拥塞导致LSP丢失、设备负载过高导致协议进程调度慢或者T3设置得太紧。可以适当调大T3同时排查底层链路质量。这里有个需要权衡的地方T3越大GR期间潜在的转发黑洞风险窗口越长T3越小GR越容易失败。合理值建议结合设备主备切换时间和网络收敛要求综合设定。4.2 现象二重启方“假死”邻居也帮不上忙还有一种情况设备发出带RR标志的IIH之后邻居也进入了Helper状态但重启方迟迟没有完成LSDB同步邻居上的数据库就一直保留着旧LSP。如果此时网络拓扑中发生变化比如另一条链路闪断整网计算就会拿着过期的LSDB算出现路由黑洞。这其实是GR的天然缺陷GR假设重启期间网络拓扑不变。所以有经验的运维人员在执行GR切换前会事先检查全网告警确认没有其他链路故障或协议抖动的迹象。如果重启过程中发生非预期拓扑变化最合理的做法是立即终止GR流程让它回退为普通重启用正常的收敛流程重新建立LSDB。宁可多几分钟收敛也不能用错误LSDB长时间驱动转发。4.3 现象三GR结束后路由表还是不一致GR结束的标志是双方恢复正常邻居关系重启方重新运行SPF。但有些时候在LSDB同步完成后路由层面还是出现短暂丢包。这不一定是IS-IS GR的问题很可能是BGP、LDP等更高层协议没有同步恢复。IS-IS只是把底层链路状态恢复好了上层控制面可能还在重新协商。遇到这种情况诊断思路应该是分平面检查先看IS-IS LSDB是否一致再看BGP邻居是否重建完成最后检查MPLS LSP是否刷新。另外一个容易忽略的点是硬件转发表刷新。GR期间转发面保持旧表项GR完成后还要等硬件把新路由刷下来才能真正恢复业务。如果设备型号偏老转发引擎刷新慢也会出现短暂丢包。这类问题不是GR本身没生效而是设备整体恢复流程里的物理瓶颈只能靠设备升级或调整业务切换策略来规避。4.4 参数速查与排查要点参数常见默认值建议设置思路对应阶段T130秒链路质量差时可适当调大重试次数首轮IIH发送与确认T260秒与LSDB规模相关大网可适度增大LSP数据库同步T3300秒对齐设备主备切换和板卡加载时间整个GR上限排障时我常用这几类手段抓包看IIH里的Restart TLV确认RR标志和SA标志的变化这是GR是否真正启动的微观证据用协议调试命令观察LSP同步与PSNP请求是否正常确认LSDB同步阶段有没有卡住查看邻居状态与定时器配置确认Helper侧没有把GR相关定时器设为0或者直接禁用了Helper能力最后再结合网络管理平台的告警视图观察收敛事件的时间线与GR超时是否重叠。这里有一个关于报文字段的经验抓包时如果看到一台设备发出的IIH里一直带着RR标志但从不撤销通常说明它已经进入GR恢复但一直等不到数据库同步完成。这时候直接查它和邻居之间LSP交互比反复重置GR状态更有效。另外多厂商混合组网里经常出现“双方都认为自己是Helper但没人当重启方”的情况本质是GR实现细节有差异协商逻辑对不上。遇到这种问题简化验证环境在一对直连链路上先做最小化复现比在大型网络上反复切换效率高得多。我在实际维护里最大的体会是GR不是在某台设备上打开开关就完了它是整网设备协同工作的结果。你这边规划得再好邻居不配合或者上层协议没跟上效果都一样大打折扣。所以每次做GR相关变更我都会做三件事先确认全网各协议版本的GR能力再核对T1、T2、T3参数与设备加载时间是否匹配最后在变更前的网络静默期做一次预演切换。另外GR期间的拓扑变化风险往往比参数本身更重要别在链路故障还没处理完的时候做重启操作这个坑踩过的人都懂。希望这些经验能帮你少走些弯路。