OSPF Neighbor、Adjacency、DR、BDR、DROTHER 与 2-Way、Full 有什么区别？
Neighbor 是在同一链路上通过 Hello 发现并维护的 OSPF 邻居；Adjacency 是为了同步链路状态数据库而从部分 Neighbor 中建立的更深层关系。DR 是广播或 NBMA 网段的指定路由器，BDR 是备份指定路由器，DROTHER 是既非 DR 也非 BDR 的路由器接口角色。2-Way 表示双向 Hello 已确认，Full 表示需要建立邻接的双方已完成数据库同步。
本文目录（25 节）
直接答案
Neighbor 是在同一链路上通过 Hello 发现并维护的 OSPF 邻居；Adjacency 是为了同步链路状态数据库而从部分 Neighbor 中建立的更深层关系。DR 是广播或 NBMA 网段的指定路由器，BDR 是备份指定路由器，DROTHER 是既非 DR 也非 BDR 的路由器接口角色。2-Way 表示双向 Hello 已确认，Full 表示需要建立邻接的双方已完成数据库同步。
在广播网段，两个 DROTHER 之间通常停在 2-Way，但它们分别与 DR、BDR 达到 Full。这不是故障，而是 OSPF 用星形邻接结构减少全互联数据库交换的设计。只有在本应建立邻接的两端长期无法进入 Full 时，才需要按参数、MTU、网络类型和数据库交换阶段排错。
一、概念快速对比
| 概念 | 所属层次 | 表示什么 | 是否要求数据库完全同步 |
|---|---|---|---|
| Neighbor | 邻居关系 | 收到并维护对方 Hello | 不一定 |
| Adjacency | 数据库交换关系 | 两端参与 LSA 同步与洪泛 | 最终应达到 Full |
| DR | 接口角色 | 多路访问网段的指定路由器 | 与网段内其他路由器建立邻接 |
| BDR | 接口角色 | DR 的备份 | 与网段内其他路由器建立邻接 |
| DROTHER | 接口角色 | 非 DR、非 BDR | 通常只与 DR/BDR 建立邻接 |
| 2-Way | Neighbor 状态 | 双向通信已确认 | 否 |
| Full | Neighbor 状态 | 链路状态数据库同步完成 | 是 |
DR、BDR、DROTHER 描述接口在某个网段上的角色；2-Way、Full 描述本路由器与某个邻居的会话状态，两组词不能相互替换。
二、Neighbor 是怎样形成的
OSPF 在接口上周期性发送 Hello。收到有效 Hello 后，本地为对端维护 Neighbor 数据结构，其中包括 Router ID、优先级、状态、计时器以及数据库交换所需列表。两台路由器共享链路，并不自动保证能成为有效 Neighbor，Hello 参数必须满足协议检查。
当本路由器在对端 Hello 的邻居列表中看到自己的 Router ID，说明通信已经双向，Neighbor 可以进入 2-Way。只收到对方 Hello 而对方尚未列出自己时，通常处于 Init。
三、Adjacency 与 Neighbor 为什么不同
RFC 2328 将 Adjacency 定义为在选定 Neighbor 之间形成、用于交换路由信息的关系，并明确指出不是每一对 Neighbor 都会成为相邻接关系。Neighbor 主要由 Hello 维持，Adjacency 还需要协商主从、交换数据库摘要、请求缺失 LSA 并完成同步。
若所有共享以太网的路由器两两建立 Full Adjacency，邻接数量和洪泛开销会随路由器数快速增长。DR/BDR 机制让网段以较少邻接完成可靠传播。
四、Down、Attempt 和 Init 表示什么
Down 表示最近没有收到该 Neighbor 的有效信息，是邻居会话初始或失效状态。Attempt 主要与 NBMA 上为手工配置的邻居主动发送 Hello 有关，并非普通广播以太网必须经历的通用状态。
Init 表示已经收到对方 Hello，但对方的 Hello 尚未列出本路由器。持续停在 Init 常提示单向连通、组播被过滤、ACL 不对称、二层问题或对端没有正确接收本端 Hello。
五、2-Way 到底证明了什么
进入 2-Way 证明 Hello 通信双向，并且邻居发现阶段已成功。它不证明双方已经交换完整链路状态数据库，也不证明一定需要继续进入 ExStart。
在广播和 NBMA 网络上，Adjacency 选择在 2-Way 阶段发生。如果双方都不是 DR 或 BDR，状态可以有意停在 2-Way。判断是否异常必须先看网络类型和双方角色。
六、ExStart 阶段做什么
需要建立 Adjacency 时，状态从 2-Way 进入 ExStart。两端在此阶段决定数据库描述交换的主从关系，并选择初始 DD 序列号。Router ID 等协议规则参与主从决定，主从只用于交换流程，不表示业务主备或路由优先级。
长期卡在 ExStart 常与接口 MTU 不一致、DD 包到达问题、网络类型不匹配、重复 Router ID 或实现互操作异常有关。应抓取 OSPF Database Description 包并对照日志，不要只重启进程。
七、Exchange、Loading 和 Full 的区别
在 Exchange 阶段，两端通过 Database Description 包描述各自链路状态数据库的摘要，并据此找出需要更新的 LSA。若还缺少较新 LSA，就进入 Loading，发送 Link State Request 并接收相应更新。
请求列表清空后进入 Full，表示两端已经完全相邻接。Full 是数据库同步状态，不等于一定学习到新的最优路由；路由还要经过 LSA 处理、SPF 计算和路由表选择。
八、DR 的职责是什么
在支持选举的多路访问网段，DR 与所有其他路由器建立 Adjacency，并在该网段的 LSA 洪泛中承担中心角色。DR 还为多路访问网络生成 Network-LSA，用一个网络节点描述已完全相邻接的路由器集合。
DR 是每个网段上的接口角色，不是整台路由器全局永久身份。一台路由器可以在一个 VLAN 上是 DR，在另一个 VLAN 上是 DROTHER。
九、BDR 的职责是什么
BDR 与网段内其他路由器建立 Adjacency，并监听洪泛过程，为 DR 故障后的接替做准备。当前 DR 失效时，BDR 被提升为 DR，再选出新的 BDR，这样可以缩短拓扑角色切换时间。
BDR 不是始终沉默的冷备。它保持完整邻接和链路状态信息，只是在正常情况下与 DR 承担的发送职责有所不同。
十、DROTHER 是什么
DROTHER 是厂商命令输出中常用的角色名，表示本接口既不是 DR 也不是 BDR。它仍是正常参与 OSPF 的路由器，可以发送 Hello、拥有 LSDB、计算 SPF 并转发业务流量。
“OTHER”只描述它在该多路访问网段选举中的角色，不表示次要路由器、备用路由器或不可发布路由。DROTHER 与 DR、BDR 一般达到 Full，而与其他 DROTHER 保持 2-Way。
十一、为何 DROTHER 之间不必 Full
假设同一广播网段有多台路由器。若每两台都 Full，就形成全网状 Adjacency。OSPF 通过 DR/BDR 把交换拓扑收敛为以 DR 和 BDR 为中心的结构，使每个 DROTHER 无需与所有其他 DROTHER 直接同步数据库。
因此在 DROTHER 上看到其他 DROTHER 为 2-Way/DROTHER 通常符合预期。在 DR 或 BDR 上查看同一个 DROTHER，则常见显示为 Full/DROTHER，因为观察者角色不同。
十二、哪些网络类型会选 DR/BDR
OSPFv2 的 Broadcast 和 NBMA 网络会选举 DR/BDR。Point-to-Point、Point-
接口实际跑在以太网上，也可能被配置成 Point-to-Point 等 OSPF 网络类型。邻接逻辑取决于 OSPF 接口类型，而非仅凭物理介质名称判断。
十三、DR/BDR 如何选举
广播或 NBMA 网段依据接口 OSPF Priority 和 Router ID 进行选举。Priority 为 0 的接口不具备成为 DR 或 BDR 的资格；在有资格者中，高优先级更有利，优先级相同再比较 Router ID。
选举具有稳定现有角色的行为，并非每当更高优先级路由器上线就立即抢占当前 DR。改变优先级后若想观察新结果，需要理解对现有邻接的影响并安排受控维护，不能把生产邻接重置当作无风险操作。
十四、Router ID 与接口 IP 的区别
Router ID 是 32 位 OSPF 标识，看起来像 IPv4 地址，但用途是唯一识别 OSPF 路由器，并不要求它本身可路由。重复 Router ID 会破坏邻居和 LSA 身份判断，应在域内保持唯一且稳定。
OSPFv2 在不同网络类型上识别邻居时会涉及 Router ID 或邻居接口 IPv4 地址。OSPFv3 更广泛地按 Router ID 识别 Neighbor，并使用链路本地地址进行链路通信。排错时应同时记录 Router ID 与实际接口地址。
十五、Hello 和 Dead 参数为何关键
同一链路上的路由器需要对 HelloInterval 和 RouterDeadInterval 等关键参数达成一致。Hello 周期用于邻居维护，Dead 计时器到期意味着近期未收到 Hello，Neighbor 会被判定失效。
一端修改计时器而另一端未同步，可能根本无法形成 Neighbor，或反复上下线。还应核对 Area ID、认证、网络掩码相关检查、Stub 区域选项和协议版本。
十六、MTU 不一致为何常卡在 ExStart/Exchange
OSPF Database Description 包包含接口 MTU 字段。RFC 2328 规定，如果该值大于接收接口可接受且不分片的 IP 数据报大小，DD 包会被拒绝。双方可能已经 2-Way，却无法完成数据库交换。
应先修正链路两端真实 MTU，而不是长期依赖忽略 MTU 检查的厂商选项。隧道、VLAN、PPPoE 和加密封装都可能让名义物理 MTU 与实际可用值不同。
十七、Full 后反复重建说明什么
从 Full 掉回 ExStart、Exchange 或 Down，可能由 Hello 丢失、接口抖动、邻接重置、DD 序列号不匹配、LSA 请求异常、重复 Router ID 或 DR 角色变化触发。偶发一次与持续周期性重建的含义不同。
记录状态变化时间、Neighbor 事件、接口错误计数和控制平面负载，再与链路日志对齐。只看最终又回到 Full 会遗漏稳定性问题。
十八、2-Way 什么时候才是异常
在 Point-to-Point 网络上，正常可达双方应继续建立 Adjacency，长期 2-Way 需要检查网络类型配置。在广播网络上，如果本路由器或对端是 DR/BDR，却仍长期停在 2-Way，也应检查角色信息是否一致以及 AdjOK 决策是否被触发。
若双方都是 DROTHER，2-Way 通常正常。先通过接口命令确认本地网络类型、DR、BDR、Priority，再解释邻居表，不能仅凭状态字符串报警。
十九、OSPFv2 与 OSPFv3 是否相同
OSPFv3 为 IPv6 引入报文和寻址变化，但 RFC 5340 说明洪泛、DR 选举、区域和 SPF 等基础机制保持不变。Neighbor 状态机和 DR/BDR 设计的核心判断仍可沿用。
差异包括 OSPFv3 按链路运行、使用 IPv6 链路本地地址、报文中地址语义变化和 Instance ID 等。配置命令及认证机制因实现而异，不能把 OSPFv2 配置逐行复制后只替换地址。
二十、标准排错顺序
第一，确认接口 Up、协议包可达且组播未被过滤。第二，核对版本、Area ID、网络类型、Hello/Dead、认证和 Router ID。第三，确认 DR/BDR 角色与 Priority。第四，判断当前状态是否按拓扑本来就应停在 2-Way。第五，若进入 ExStart 后失败，再查 MTU 与 DD 交换。
随后检查 Loading 阶段的请求列表、LSA 错误和 CPU/内存压力。每一步都以两端同一时刻的输出和必要抓包为证据，避免只根据单端邻居表下结论。
二十一、变更前后如何验收
变更前保存接口参数、Neighbor 状态、DR/BDR 身份、LSDB 摘要和路由表。变更后确认预期 Neighbor 恢复、需要的 Adjacency 达到 Full、DROTHER 间 2-Way 符合设计，并观察一段稳定窗口内是否再次重建。
还要验证实际前缀、下一跳和故障切换，而不是仅以 Full 作为完成标准。Full 证明数据库同步，却不能证明所有路由策略、区域汇总或转发路径都正确。
常见问题
1. OSPF 邻居必须全部显示 Full 吗？
不必须。广播或 NBMA 网段的两个 DROTHER 通常保持 2-Way；它们分别与 DR、BDR 建立 Full Adjacency。
2. 2-Way/DROTHER 是故障吗？
多数广播网段中这是正常状态。需结合本地角色、对端角色和接口网络类型判断。
3. DR 是整台路由器的主设备吗？
不是。DR 是某个多路访问网段上的接口角色，一台路由器在不同接口上可以拥有不同角色。
4. Full 就表示路由一定正确吗？
不是。Full 只说明相邻接双方完成 LSDB 同步。路由是否进入 RIB/FIB 还受 SPF、Metric、策略和其他协议优先级影响。
5. 卡在 ExStart 最先检查什么？
先核对两端 MTU、网络类型、Router ID 和 DD 包交换，再检查 ACL、链路丢包与实现日志。
结论
Neighbor 是 Hello 层面的邻居，Adjacency 是数据库同步关系；DR、BDR 和 DROTHER 是多路访问网段角色；2-Way 表示双向发现完成，Full 表示需要的数据库同步完成。正确判断 OSPF 状态的关键是先确认网络类型和双方角色，再按状态机定位故障，不能把所有非 Full 邻居都视为异常。
参考来源
- IETF RFC 2328：OSPF Version 2，https:
/ / www. rfc- editor. org/ rfc/ rfc2328 - IETF RFC 5340：OSPF for IPv6，https:
/ / www. rfc- editor. org/ rfc/ rfc5340 - IETF RFC 6845：OSPF Hybrid Broadcast and Point-
to- Multipoint Interface Type，https: / / www. rfc- editor. org/ rfc/ rfc6845 - FRRouting Documentation：OSPFv2，https:
/ / docs. frrouting. org/ en/ latest/ ospfd. html - FRRouting Documentation：OSPFv3，https:
/ / docs. frrouting. org/ en/ latest/ ospf6d. html - Cisco：Understand OSPF Neighbor States，https:
/ / www. cisco. com/ c/ en/ us/ support/ docs/ ip/ open- shortest- path- first- ospf/ 13685- 13. html - Cisco：Review OSPF Frequently Asked Questions，https:
/ / www. cisco. com/ c/ en/ us/ support/ docs/ ip/ open- shortest- path- first- ospf/ 9237- 9. html