会话为什么会反复重建
LDP 会话反复重建的直接后果是标签反复重分发，转发面出现短时黑洞或路径抖动。成因大致分四类：传输地址依赖的 IGP 路由抖动、两端定时器不匹配、控制面过载导致保活超时、以及链路层频繁 Up/Down。定位的关键是把会话日志与链路事件按时间对齐，而不是单看某一侧计数。
基本信息
| 路由侧 | 传输地址依赖的 IGP 路由抖动，套接字随之重建 |
|---|---|
| 定时器侧 | 两端 hello/hold 参数不一致，保活被判超时 |
| 资源侧 | 控制面负载高，保活报文处理不及时 |
| 物理侧 | 链路误码或光功率异常导致频繁 Up/Down |
| 取证点 | 会话日志、接口错误计数、邻居建立时间 |
典型使用场景
- 监控报 LDP 邻居反复 Up/Down，业务出现间歇性丢包
- 割接或链路调整后标签重分发频繁
- 排查「业务时好时坏」：确认是否与会话重建时间吻合
- 巡检接口错误计数，提前发现误码隐患
- 与对端联调时核对两端定时器参数是否一致
取证命令
取证命令
show mpls ldp neighbor # 会话状态、建立时间与传输地址
show mpls ldp discovery # 发现关系是否稳定
show interfaces GigabitEthernet0/1 | include error|drops # 物理层异常
show logging | include LDP # 会话 Down 的原因与时间点
# 关键动作：把日志时间点与接口事件对齐，判断谁先动成因对照
| 侧别 | 典型证据 | 处理方向 |
|---|---|---|
| 路由抖动 | IGP 邻居或前缀同步变化 | 先稳住 IGP，再谈 LDP |
| 定时器不匹配 | 对端保活超时集中出现 | 统一两端 hello/hold 参数 |
| 控制面过载 | CPU 偏高、协议报文延迟 | 降低收敛压力，排查异常更新 |
| 物理层 | 接口误码、光功率越界 | 处理链路质量问题 |
只把责任推给对端是常见误判：本端链路层抖动与传输地址路由变化同样会让会话重建，取证应双侧同时进行。
LDP 依赖 IGP 提供的传输地址路由：IGP 一抖动，即使物理链路正常，会话也会跟着重建，这属于预期行为，不是 LDP 本身缺陷。
调大 hold 时间只能让检测更迟钝，并不会消除触发源；若根因是物理误码，问题迟早复现，应先取证再决定参数。