disp ospf Statistics error看一下

OSPF 邻居建立失败，尤其是在广播型网络中，通常源于一些基础的配置不一致或物理层问题。33 号设备与其他设备都无法建立邻居，问题大概率出在 33 号设备自身的配置上。

这里整理了一套从基础到深入的排查思路，你可以按顺序检查：

 第一步：基础物理与连通性检查

这是最基础的一步，确保“路是通的”。

1. 检查接口状态：在 33 号设备上执行 display interface 命令，检查连接 34 和 35 的接口物理状态（Physical）和协议状态（Protocol）是否都为 UP。

2. 测试直连连通性：

   • 在 33 号设备上 ping 34 和 35 的接口 IP 地址，确认能通。

   • 进行大包 ping 测试，例如 ping -s 1500 邻居IP，检查是否存在因 MTU 不一致导致的大包不通问题。

3. 检查安全设备/ACL：如果中间有防火墙或交换机配置了 ACL，确保没有拦截 OSPF 协议报文（协议号 89）。

 第二步：OSPF 核心参数一致性检查（重点）

OSPF 邻居建立要求两端的关键参数必须一致。请逐一核对 33 号设备与 34、35 号设备的配置。

1. Router ID 唯一性：执行 display ospf brief 查看本端 Router ID。整个 OSPF 网络中 Router ID 必须唯一。如果 33 号设备的 Router ID 与其他设备冲突，需要在系统视图下修改 (ospf router-id X.X.X.X) 并重启 OSPF 进程 (reset ospf process) 才能生效。

2. 区域 ID (Area ID)：执行 display ospf brief 检查两端接口所属的区域 ID 是否完全一致。

3. Hello/Dead 时间间隔：执行 display ospf interface 查看接口的 Hello 和 Dead 时间。广播网络中，默认 Hello 为 10 秒，Dead 为 40 秒，两端必须一致。

4. IP 地址掩码：检查互联接口的 IP 地址掩码是否完全相同。

5. 网络类型：执行 display ospf interface 查看接口的网络类型。在 H3C 交换机上，接口的 OSPF 网络类型默认是 Broadcast。请确保 33 号设备与邻居的接口网络类型一致。

6. 认证配置：如果配置了认证，确保两端的认证类型（如 MD5）和密钥完全一致。

 第三步：检查 OSPF 邻居状态（判断卡在哪一步）

在 33 号设备上执行 display ospf peer 命令，查看邻居状态。根据状态可以初步定位问题：

• 状态卡在 INIT 或 2-WAY：通常意味着Hello/Dead 时间间隔不匹配、网络类型不一致或区域 ID 错误。

• 状态卡在 EXSTART 或 EXCHANGE：这通常指向 MTU 不匹配。检查两端互联接口的 MTU 值（默认 1500）是否一致。如果无法统一，可以在接口下配置 ip ospf mtu-ignore 来临时规避。

 第四步：检查特殊配置与软件版本

• Stub/NSSA 区域：如果配置了特殊区域，区域类型必须匹配。如果一端是 Stub 区域，另一端是普通区域，邻居将无法建立。

• 被动接口 (Passive-interface)：检查 33 号设备的互联接口是否被配置为 silent-interface（被动接口）。如果是，该接口将不发送 Hello 报文，导致无法建立邻居。

• 区域宣告：确认在 33 号设备的 OSPF 进程中，已使用 network 命令正确宣告了互联接口的网段。

• 软件版本与兼容性：不同厂商或不同软件版本的设备在 OSPF 实现上可能存在细微差异。确保 33 号设备与其他设备的 OSPF 软件版本兼容。

1.ping互联线路，如果这个不通，呢ospf就不通

2.确定两端是否有防火墙，防火墙需要放行ospf协议

3.检查2边ospf的类型，是否都是广播，或者都是P2P。确保一致

OSPF‑33（Router‑ID 70.10.20.33）邻居卡在 Init 状态故障分析

现象：

1. DQJ‑SWB（34）：display ospf peer看到 70.10.20.33 状态 Init/-；34 与 35 Full 正常；34 与另外一台设备 Full 正常。
2. JB7‑SWB 就是 33 设备，33 这边 ospf peer 看不到 34、35 邻居。
3. 抓包可以看到：33 向外发送 OSPF Hello 报文（224.0.0.5），Hello 报文能在链路上抓到，但是 33 收不到对方的 Hello。

Init 状态含义：本设备收到对方 Hello，但是 Hello 里面没有看到自己的 Router‑ID。 Init = 单向通：34 收到 33 的 Hello；33 收不到 34/35 的 Hello 报文。

核心逻辑

Init 状态最典型：

• 34：收到 33 发的 Hello → 邻居进入 Init；
• 33 没有收到 34、35 的 Hello 报文 → 33 邻居表为空；

Hello 报文是双向的，33 发出去的 Hello 能被抓到；但对端回复的 Hello 到不了 33 设备。

排查步骤，按优先级

1、接口基础检查（Vlan‑if20，三台交互的三层接口）

1. 确认 Vlan‑if20 UP；OSPF 在该接口使能；网络类型是 Broadcast 广播。
2. 检查接口是否配置ospf silent‑interface！静默接口会只发 Hello，不接收 / 不处理 OSPF 报文，会直接出现 Init。

如果 Vlan‑if20 被配置 silent‑interface，必须删掉。silent 接口不会建立邻居。

2、VLAN 二层问题（很高概率）

OSPF Hello 组播 224.0.0.5，组播二层不通，会出现单向 Hello。

1. 三台设备 Vlan20 对应的物理端口，确认都在 VLAN20，允许组播转发。
2. 检查是否配置了端口隔离、PVLAN。
3. 检查是否有 ACL 过滤 224.0.0.5；

ACL 禁止 OSPF 组播 224.0.0.5，会导致 33 收不到别人 Hello，别人能收到 33 发的 Hello，复现 Init 现象。

3、OSPF Hello/Dead 时间、区域 ID 校验

34 设备邻居表：

• 33 的 Dead‑Time 显示 40；
• 35 的 Dead‑Time 显示 37。

Broadcast 默认 Hello10s，Dead40s。35 的 Dead=37 是异常，说明 35 的 Hello 时间被修改过！ Hello 时间不一致，邻居无法 Full。

核对：

• Area ID：必须都是 0.0.0.0
• Hello‑interval：广播默认 10，三台必须完全一致
• Dead‑interval：默认 40，三台必须一致

从截图看邻居 35 Dead‑Time=37，不是标准 40，说明接口下手工修改了 ospf timer hello，这个参数全网接口必须统一。

4、宣告 network 检查

宣告网段必须包含 Vlan‑if20 的 IP，反掩码正确。

示例：

⚠️network 宣告的是接口 IP 所在网段，不是 Router‑ID 网段；接口 IP 必须落在 network 范围内，接口才会加入 OSPF。

如果宣告错误：接口不会收发 OSPF Hello。

5、Router‑ID、重复 Router‑ID 检查

确认三台 Router‑ID：33=70.10.20.33；34=70.10.20.34；35=70.10.20.35，三台不能重复。

Router‑ID 冲突，邻居会异常、震荡。

6、抓包现象解读（你提供的 pcap）

抓包能看到源 70.10.20.33 向外发送 Hello 报文，说明33 的 OSPF 发送是正常的。 问题点：33 收不到来自 34、35 的 Hello 报文。

• 要么：34/35 的 Hello 报文，二层组播没有转发到 33；
• 要么：33 设备 Vlan‑if20 入方向 ACL 丢弃 224.0.0.5；
• 要么：33 的 Vlan‑if20 配置了 silent‑interface。

快速定位命令执行清单（33 设备执行）

故障最可能根因排序

1. 【高概率】Vlan‑if20 配置 silent‑interface：33 可以发 Hello 出去，不能处理接收 Hello，对端看到 Init，本端看不到邻居，现象完全匹配截图。
2. 【高概率】Vlan‑if20 inbound 方向 ACL 拒绝 OSPF 组播 224.0.0.5。
3. 【中概率】三台 Vlan‑if20 下 ospf timer hello/dead 计时器不一致（截图 35 Dead=37 异常）。
4. 二层 VLAN20 组播转发异常，端口隔离等，组播报文无法送达 33。
5. network 宣告没有包含 Vlan‑if20 接口 IP。

补充现象解释

Init/- 那个横杠‑：代表还没有选举 DR/BDR，因为邻居还没有到达 2‑Way 状态，无法进入 DR 选举阶段。

验证修复

修复配置后，reset ospf process重启 OSPF 进程，观察邻居状态能否走到 Full。