摘要：很多人学 OSPF，配置一套就觉得搞定了。可一旦邻居状态卡在 EXSTART、FULL 死活不上，就只能瞪眼看日志。
号主：老杨丨11年资深网络工程师，更多网工提升干货，
很多人学 OSPF，配置一套就觉得搞定了。可一旦邻居状态卡在 EXSTART、FULL 死活不上，就只能瞪眼看日志。
其实只要把这6个邻居状态吃透，你就知道 OSPF 其实就是个“认识邻居、交换信息”的流程。
今天这篇，就来一步步过一遍。
这是 OSPF 邻居建立的起点。设备启动 OSPF 后，还没收到任何邻居发来的 Hello 报文，就处于 Down 状态。
常见场景：
接口未启用 OSPF；对端没配置 OSPF 或没在该网段；接口未 UP；网络类型不一致（如点对点 vs 广播）。注意：这一步状态在实际日志中很少“卡住”，因为只要有 Hello 报文，就会自动进入下一阶段。
设备收到邻居的 Hello 报文，但对方发来的报文里没有自己的 Router ID，说明你发出 Hello 了，但人家还没“认你”。
关键特征：
收到 Hello 报文；Hello 包中不包含本设备 Router ID。常见问题点：
Hello/Dead 时间不一致；区域号不一致；网络类型不同；认证方式或密码不同；MTU 不一致（在某些设备会卡在这儿）；排障建议：
用 display ospf interface 或抓包看 Hello 内容，确认参数一致。
你在邻居的 Hello 报文中看到了自己的 Router ID，说明双方都“看见彼此”了。
但还没到交换路由表阶段，这个状态是多访问广播网络（如以太网）上，非 DR/BDR 的邻居最终状态。
重点：
如果你不是 DR 或 BDR，也不是对端，那你们就在 2-Way 终止；对 DR/BDR 会继续进入下一阶段。常见迷惑点：
“为啥我两个设备就是 2-Way 不往下走？”
检查是不是都不是 DR/BDR？这就正常。
到了这一步，双方开始“协商谁先来发数据库描述信息”。这需要根据 Router ID 进行对比。
主从协商：
Router ID 大的做 Master，先发；小的做 Slave，等对面说话。问题高发点：
MTU 不一致（最常见故障点之一！）；如果两边 MTU 不一样，有些设备默认 Drop DBD 报文，邻居就永远卡在这一步。排障建议：display ospf peer 查看状态，或者 debug ip ospf 看 DBD 报文收发是否成功。
主从确定后，就开始真正交换 DBD（Database Description）报文，也就是 LSDB 的摘要信息。
这个阶段干了啥？
告诉对方：我有哪些 Link-State 记录（不发全内容，只发“目录”）；比较对方有没有自己没有的，如果有，后面去要细节。风险点：
如果有大量链路状态变化，这步可能花不少时间；报文校验出错、过期、路由不一致等也可能中断。在 Exchange 之后，设备会根据对方 DBD 中“自己没有”的部分，发 Link State Request 请求，然后对方返回 LS Update 报文，完成真正的 LSDB 同步。
Loading：正在请求 Link-State 数据Full：邻接完成，数据库完全同步到 Full 状态，邻居关系才算“完全建立”，也才能真正参与 SPF 计算。
一图总结：OSPF 邻居状态六部曲每一步都有其定位：
Down：啥都没有；Init：收到 Hello；2-Way：互相 Hello；ExStart：抢谁先来；Exchange：交换目录；Loading：拉取内容；Full：同步完成！常见问题合集问：为什么邻居状态卡在 2-Way 不动？
→ 很可能你不是 DR 或 BDR。正常情况，不会进入后续阶段。
问：配置一模一样，邻居就是不上 FULL？
→ 先查 MTU、认证、区域号、Hello 时间，尤其 MTU 是高频杀手。
问：OSPF 状态突然从 FULL 变成 INIT 再回来，正常吗？
→ 可能链路波动，也可能是对端重启或 Hello 超时。建议检查接口状态、链路稳定性。
OSPF 并不难，但很多“诡异的邻居不上线”“路由不通”“状态反复抖动”，基本都出在这6个阶段某个点。
display ospf peer：看邻居状态display ospf interface：看参数对不对display ospf lsdb：确认同步情况debug ip ospf / 抓包：终极排障法宝来源：网络工程师俱乐部一点号