📚 课程目录第4章 OSPF邻居关系故障诊断

4. OSPF邻居关系故障诊断

OSPF邻居关系是链路状态数据库同步的前提。邻居关系卡在 Init、ExStart、ExChange 或反复 Down，绝大多数原因集中在五类：Hello参数不匹配、区域ID冲突、MTU不一致、认证失败、网络类型不一致。本节围绕这五类故障，给出可复现的排查路径与判断依据。

一、先看邻居状态，再定位故障层

在Juniper设备上，第一步永远是查看邻居状态与停留阶段：

show ospf neighbor
show ospf neighbor detail
show ospf interface
show ospf interface detail

状态与故障的对应关系是排查的起点：

Down：未收到Hello，或Hello被丢弃（认证、区域、网络类型、掩码问题）。
Init：收到了对端Hello，但对端Hello里没有自己的Router-ID，通常是单向可达或Hello参数不匹配。
2-Way：双向Hello成功，但在广播网络中未成为DR/BDR，属正常状态。
ExStart：进入DD交换但主从协商失败，典型原因是MTU不一致。
ExChange/Loading：LSA交换异常，多为MTU或LSA过滤问题。
Full：邻接建立完成。

下面这张图把五类故障与邻居状态、关键判断命令对应起来，便于现场快速定位。

二、Hello参数不匹配

Hello报文携带Hello间隔、Dead间隔、区域ID、认证类型、网络类型、掩码等字段。任意一项不一致，邻居都无法进入2-Way。Juniper默认Hello间隔10秒、Dead间隔40秒，Dead通常是Hello的4倍。

# 查看接口OSPF参数
show ospf interface ge-0/0/0.0 detail

# 修改Hello/Dead间隔
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 hello-interval 5
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 dead-interval 20

排查时先确认两端 hello-interval 与 dead-interval 是否一致。若一端为10/40，另一端为5/20，邻居会反复在 Down 与 Init 之间跳变。注意：Dead间隔必须至少是Hello间隔的4倍，否则配置会被拒绝。

三、区域ID冲突

OSPF要求同一链路上两端接口必须属于同一区域。若一端配置 area 0.0.0.0，另一端配置 area 0.0.0.1，Hello报文中的Area ID字段不一致，邻居无法建立。

# 查看接口所属区域
show ospf interface ge-0/0/0.0 detail | match "Area"

# 修正区域
delete protocols ospf area 0.0.0.1 interface ge-0/0/0.0
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0

区域ID冲突的典型现象是邻居停留在 Init 或直接 Down，且 show ospf interface detail 中两端Area字段明显不同。注意区域ID用点分十进制表示，0.0.0.1 与 1 等价，但 0.0.0.1 与 0.0.0.0 不同。

四、MTU问题

MTU不一致是 ExStart 卡死的头号原因。OSPF在DD交换阶段会协商主从关系，若两端接口MTU不同，DD报文中的MTU字段不匹配，主从协商失败，邻居停留在 ExStart。

# 查看接口MTU
show interfaces ge-0/0/0.0 extensive | match "MTU"

# 修改MTU（两端必须一致）
set interfaces ge-0/0/0 mtu 9000

常见场景：一端为默认1500，另一端为9000（Jumbo Frame）。此时 show ospf neighbor 显示 ExStart，show ospf log 中可见DD报文重传。解决方法是统一两端MTU，或使用 set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 mtu-ignore 忽略MTU检查（不推荐，可能引发后续LSA传输问题）。

五、认证失败

OSPF支持简单密码和MD5认证。认证类型或密钥不一致时，Hello报文被丢弃，邻居无法建立。Juniper配置示例：

# 简单密码认证
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 authentication simple-password "ospf123"

# MD5认证
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 authentication md5 1 key "ospf123"

排查时确认两端认证类型（simple-password / md5）和密钥完全一致。MD5认证还需确认key-id相同。认证失败时邻居状态为 Down，且 show ospf log 中会出现认证失败记录。注意：认证配置在接口级别，同一区域不同接口可以有不同的认证方式。

六、网络类型不一致

OSPF网络类型决定DR/BDR选举和Hello行为。常见类型：broadcast、p2p、p2mp、nbma。若一端为broadcast，另一端为p2p，Hello报文中的Network Type字段不一致，邻居无法建立。

# 查看网络类型
show ospf interface ge-0/0/0.0 detail | match "Type"

# 修改网络类型
set protocols ospf area 0.0.0.0 interface ge-0/0/0.0 interface-type p2p

典型场景：以太网接口默认broadcast，若一端改为p2p，另一端仍为broadcast，邻居停留在 Init 或 Down。解决方法是统一两端网络类型。注意：p2p类型不进行DR/BDR选举，适合点对点链路；broadcast类型会选举DR/BDR，适合广播网络。

七、综合排查流程与案例

下面给出一个综合排查流程，按顺序执行可覆盖五类故障：

执行 show ospf neighbor，记录邻居状态与停留阶段。
执行 show ospf interface detail，比对两端Area、Hello/Dead、Auth、Network Type、MTU。
若状态为 Down：检查认证、区域ID、网络类型、Hello/Dead间隔。
若状态为 Init：检查单向可达、Hello参数、认证。
若状态为 ExStart：检查MTU。
若状态为 ExChange：检查MTU、LSA过滤。
修正配置后，执行 clear ospf neighbor 或等待Dead超时重建邻居。

案例：某企业两台Juniper MX设备通过ge-0/0/0直连，OSPF邻居停留在 ExStart。排查发现一端MTU为1500，另一端为9000。统一MTU为9000后，邻居进入 Full。该案例说明MTU不一致是 ExStart 卡死的典型原因。

提示：修改OSPF参数后，建议使用 clear ospf neighbor 强制重建邻居，避免等待Dead超时。同时使用 show ospf log 查看详细日志，辅助定位认证失败、DD重传等问题。

注意：MTU-ignore虽然能临时解决 ExStart 问题，但可能导致后续LSA传输时大报文被丢弃，引发路由黑洞。生产环境应统一MTU，而非忽略检查。

总结：OSPF邻居故障排查的核心是“先看状态，再比对参数”。五类故障中，Hello参数不匹配和区域ID冲突导致 Down/Init，MTU问题导致 ExStart，认证失败导致 Down，网络类型不一致导致 Init/Down。掌握状态与原因的对应关系，配合 show ospf interface detail 和 show ospf log，即可快速定位并修复。