OSPF 高发的七类配置错误
OSPF 出问题绝大多数不是协议本身的缺陷，而是配置上的单侧修改与遗漏。最高频的一条是只改一端：网络类型、计时器、认证参数只要两侧不一致，邻居就起不来或者反复超时。其次是思科平台上默认开启的 MTU 检查导致邻接卡在交换阶段，以及重分发时忘记带子网参数导致明细路由被吞。这份清单适合作为配置完成后的自查项：逐条对照，比等故障出现再回头查要省力得多。
基本信息
| 适用场景 | 配置自查、培训与事故复盘 |
|---|---|
| 常见根因 | 只改单侧、改完不验证、忽视平台默认行为 |
| 自查命令 | display ospf error、display ospf interface brief、display ospf peer brief |
| 收工动作 | 两端对照区域、Cost、计时器、网络类型、MTU |
典型使用场景
- 新设备接入后邻居起不来，按清单逐项排除而不是盲改配置
- 变更完成后的自查：按顺序核对两端参数，作为变更单的验证记录
- 事故复盘：把实际发生的故障归入清单中的某一类，沉淀成团队检查项
- 人员培训：用真实事故原型讲解协议参数不匹配的后果
- 批量部署前评审：提前识别重分发、汇总等高风险配置项
Top 7 错误
| 序号 | 错误 | 症状 |
|---|---|---|
| 1 | 只改一侧网络类型或计时器 | 邻居起不来或反复超时 |
| 2 | 思科侧 MTU 检查未对齐（默认开启） | 邻接卡在交换状态长时间不动 |
| 3 | 思科重分发忘记带子网参数 | 明细子网被吞，只剩主类网段 |
| 4 | 认证模式、Key ID 或密钥不一致 | 邻居卡在初始状态，错误计数持续增长 |
| 5 | 汇总配置写错区域或漏配边界 | 汇总不生效或出现路由黑洞 |
| 6 | 被动接口用在需要建邻居的接口上 | 邻居永远不出现且无明确报错 |
| 7 | 改完 Router ID 不重置进程 | 仍在使用旧标识，行为与预期不符 |
收工前的对照检查
收工前的对照检查
<Huawei> display ospf error ! 错误计数增长说明参数不匹配
<Huawei> display ospf interface brief ! 各接口区域、网络类型与 Cost
<Huawei> display ospf peer brief ! 邻居状态是否稳定在 Full
! 思科对应 show ip ospf interface brief / show ip ospf neighbor
! 再补一条：show running-config | section router ospf两端要对比的字段
| 对比项 | 为什么必须一致 | 不一致的表现 |
|---|---|---|
| 区域号 | 同一链路必须属于同一区域 | 邻居不建立，接口不参与计算 |
| 网络类型 | 决定是否选 DR、Hello 行为 | 一侧广播一侧点到点，邻居起不来 |
| 计时器 | Hello 与 Dead 需匹配 | 邻居反复超时中断 |
| MTU | 思科默认校验两端 MTU | 邻接卡在交换状态无法完成 |
| 认证参数 | 模式、Key 与密钥三者一致 | 邻居卡在初始状态并累计错误 |
共同根因只有一个：改配置只改单侧、改完不验证。收工前的标准动作是两端同时执行显示命令，对照区域、Cost、计时器、网络类型与 MTU 五项，最后确认邻居稳定在 Full 状态。
错误计数是很好的线索。display ospf error 里某一类计数持续增长，通常能直接指向是认证、计时器还是报文格式不匹配，比逐条猜配置快得多。