震惊，一个问题让众多大佬夜不能寐，原因竟然是……

简短场景复述：

华为交换机对接 H3C 路由器，中间透传3台安全设备。OSPF 邻居建立停在 Exstart，error 计数全 0，抓包/日志也没明显丢包或错误——这种情况非常常见于跨厂商互联。

下面先做原因分析（为什么会卡），再给出一步步可执行的解决方案，便于直接复制到运维工单使用。

一、为什么会卡在 Exstart（分析 —— 趋势与机理）

MTU/数据库描述（DD） 字段不一致 — 高概率（≈90%）

Exstart/Exchange 阶段交换的是 DD 包，DD 包里包含接口 MTU。若一端严格检查 MTU（H3C/Cisco 类行为），另一端忽略或使用不同 MTU（华为默认可能不检查或接口 MTU 不同），会导致一端丢弃对方的 DD 包，邻居无法进入 Exchange/Full。错误计数为 0 很可能是因为包被接收但不认（不计为 error）。

OSPF 接口 / 网络类型不匹配（Broadcast vs P2P 等）

若两侧把同一链路配置为不同 network-type，会影响 DR/BDR 选举与 DD 行为，有时导致卡在 Exstart。

认证/Area/计时器不一致

认证类型或密钥不一致通常会更早失败，但在某些实现上也会表现为交换阶段异常。Hello/Dead 定时器不一致也会影响邻居稳定性。

Router ID 冲突 / DR/BDR 优先级问题

相同 RID、DR 优先级设置异常，可能导致主从（Master/Slave）选举失败或角色错乱，从而卡在 Exstart。

单向包/ACL/设备实现差异或 BUG

ACL/防火墙 过滤 OSPF（协议 89）单播包；或厂商实现细节（DD 标志处理、MTU 检查逻辑等）差异；固件 BUG 也会出现这种“无报错但卡住”的现象。

物理/链路层问题

Duplex/Speed 不匹配、链路错误导致帧错误，虽然不一定产生 OSPF error，但会干扰 DD 交换。

二、快速排查流程（按优先级，越早越能命中问题）

原则：从最常见 → 最复杂，先排 MTU，再看配置，然后抓包/调试。每一步我给出华为与 H3C 常用命令，便于直接执行。

1) 确认邻居状态与角色（Master/Slave）

华为：

display ospf peer verbose

H3C（Comware）：

display ospf peer verbose

看点：是否都显示 Exstart，以及哪一侧是 Master、哪一侧是 Slave。Master 一般先发 DD 包。

2) 核对接口 MTU（首要步骤）

华为查看接口 MTU：

display interface GigabitEthernet0/0/1 
# 或 Vlanif
display interface Vlanif10

华为查看 OSPF 接口信息（是否启用 MTU 检查）：

display ospf interface GigabitEthernet0/0/1

查找 MTU Enable: Yes/No、OSPF 接口显示的 MTU 值。

H3C 查看接口 MTU：

display interface GigabitEthernet1/0/1

对比两端 MTU（物理与 SVI 都要看）。注意 VLAN tag 会使有效 MTU 差 4 字节的场景（某些平台默认考虑/不考虑）。

3) 立即试验性修复（快速验证 MTU 是否为罪魁）

方案 A（统一 MTU）—— 在双方将接口 MTU 设为相同（例如 1500）：

华为：

interface GigabitEthernet1/0/1 
  mtu 1500

H3C：

interface GigabitEthernet1/0/1 
  mtu 1500

方案 B（绕过 MTU 检查）—— 在华为侧临时禁用 OSPF MTU 检查（若已开启）：

interface Vlanif10
  undo ospf mtu-enable

说明：若修改 MTU 或禁用后邻居由 Exstart → Exchange → Full，MTU 问题基本确认。

4) 核对 OSPF 基本配置（Area / Network-type / Auth / Timers）

华为查看 OSPF 接口配置：

display ospf interface Vlanif10
display current-configuration | include ospf

H3C 查看：

display ospf interface GigabitEthernet1/0/1
display current-configuration | include ospf

重点比对：

• Area ID 是否完全一致（注意十进制 vs 点分表示）
• network-type（broadcast/p2p）是否一致
• authentication mode & key 是否一致
• hello/dead timers 是否一致

如果直连链路，建议临时将两端都设为 p2p（point-to-point）来简化 DR/BDR 与 MTU 问题：

华为：

interface  X
  ospf network-type p2p

H3C：

interface  X
  ospf network-type p2p

5) 看 Router ID / DR 优先级

查看 RID:

display ospf brief

# 华为
interface X
  ospf dr-priority 0/100

# H3C
interface X
  ospf priority 0/100

（设置优先级为 0 可以避免成为 DR，便于做测试）

6) 抓包 / 调试（当上面没定位到问题）

在设备上开启 OSPF 包级 debug，或在链路上用 Wireshark 抓包（过滤 ospf）

# H3C
debugging ospf packet

# 华为
debugging ip packet error 

抓到的关键点：DD 包里 MTU 字段、DD 包的 flags（I/ M/ MS/ More/ Master/Slave）。若一侧持续发带有本端 MTU 的 DD，而另一侧不回以合适的应答，很可能是 MTU/实现差异。

7) 最后手段：重启 OSPF 进程（谨慎）

# 华为
reset ospf process

# H3C
reset ospf x

（会短暂影响路由，生产环境谨慎，最好在维护时段或先在一端做）

三、为什么“拔插线”能救命？

这不是玄学，是网络现实。 所谓“透明安全设备”，其实从不真的“透明”。

常见原因如下

而拔插线同时触发了三件事：

1️⃣ 刷新 MAC/ARP 表（重新学习邻居）；

2️⃣ 清空安全设备会话表；

3️⃣ 重新协商物理层链路（Link Re-Negotiation）。

结果——链路“洗白”，DD 包终于能正常往返。

四、为什么 Error=0 ？

因为设备认为：

“我收到的包格式没问题呀。”

OSPF 只统计格式错误、认证失败、校验错误；逻辑不同步（比如包延迟、乱序、丢失）并不会计入 error。所以 Error=0 反而是陷阱： 看似一切正常，其实邻居“卡在中间”谈崩了。

五、以后遇到这种情况怎么办？

六、总结一句话

逻辑问题分析半天，物理层动手三秒。

在网络世界里，“透明”设备往往最不透明，“Error=0”并不代表世界安宁。

下次再遇到 OSPF 卡在 Exstart， 别急着背锅给 MTU 或厂商兼容， 先看看—— 中间那几台“透明设备”， 是不是该被拔醒了