LDP 优雅重启
LDP GR 让控制面重启期间保留既有的标签绑定，由邻居协助完成恢复，从而减少转发中断。它覆盖的是控制面重启这一类场景，不覆盖硬件失效；而且需要邻居支持并配合，单侧启用很难达到预期效果。
基本信息
| Cisco | 全局执行 mpls ldp graceful-restart |
|---|---|
| 验证命令 | show mpls ldp graceful-restart 查看状态 |
| 协同要求 | 邻居需支持并协助恢复 |
| 覆盖范围 | 仅控制面重启，不含硬件失效 |
| 概念对照 | 与路由协议的 GR 概念相近，但作用对象不同 |
典型使用场景
- 高可用设计：减少控制面重启带来的转发中断
- 升级或重启前评估：确认 GR 能覆盖的操作范围
- 排障「重启后标签丢失」：确认邻居是否协助恢复
- 验收测试：演练控制面重启并观察转发是否保持
- 协议评审：与 BFD、路由协议 GR 等机制配合使用
配置与核查
配置与核查
mpls ldp graceful-restart # 全局启用 LDP 优雅重启
!
show mpls ldp graceful-restart # 查看 GR 状态与相关参数
show mpls ldp neighbor 1.1.1.1 # 确认邻居关系与恢复情况适用范围
| 场景 | 是否覆盖 | 说明 |
|---|---|---|
| 控制面重启 | 覆盖 | 借助邻居协助恢复绑定 |
| 进程异常重启 | 部分覆盖 | 取决于实现与邻居配合 |
| 硬件失效 | 不覆盖 | 需要其他冗余机制 |
| 链路中断 | 不覆盖 | 属于转发面问题 |
GR 不是万能的高可用方案：它只覆盖控制面重启这一类场景，硬件失效与链路中断仍需要其他冗余机制兜底。
单侧启用难以达到预期效果：邻居需要支持并配合恢复，部署前确认两端能力。
演练比配置更重要：只有实际做过控制面重启演练，才能知道恢复需要多久、转发是否真的保持。
GR 的效果依赖邻居的协助能力：部署前先确认对端是否支持，并在两端同时开启相关参数。
恢复时间要在验收中量化：记录从控制面重启到绑定恢复的耗时，才能判断是否满足业务要求。