OSPF MTU 检查是什么
OSPF 邻居建立到 DBD 交换阶段时，两端会在报文里携带自己的接口 MTU，值不一致就无法继续，邻居长期停在 EXSTART/EXCHANGE。关键差异在默认行为：思科默认在 DBD 中检查 MTU，华为/H3C 默认不检查、需要显式开启。跨厂商互联最容易踩这个坑——思科侧默认严、华为/H3C 侧默认松。
基本信息
| 适用设备 | 三层设备（OSPF 邻居两端） |
|---|---|
| 思科默认 | 检查 MTU；接口下 ip ospf mtu-ignore 可关闭 |
| 华为/H3C 默认 | 不检查；接口下 ospf mtu-enable 可开启 |
| 典型现象 | 邻居长时间停留在 EXSTART / EXCHANGE，日志提示 MTU 不一致 |
| 常见诱因 | 隧道接口（GRE/IPSec）与物理口 MTU 不同、跨厂商默认策略差异 |
三厂默认行为
| 厂商 | 默认是否检查 MTU | 开关命令 |
|---|---|---|
| 华为 VRP | 不检查 | 接口下 ospf mtu-enable 开启 |
| 思科 IOS | 检查 | 接口下 ip ospf mtu-ignore 关闭 |
| H3C Comware | 不检查 | 接口下 ospf mtu-enable 开启 |
典型使用场景
- 邻居卡在 EXSTART：MTU 不一致比区域号、认证错误更常见，应优先核对
- 跨厂商对接：两端默认行为不对称，配置前先明确谁检查、谁不检查
- 隧道互联：GRE/IPSec 会减小可用 MTU，需要两端统一改小
- 更换板卡或接口类型后：默认 MTU 可能随之变化，触发邻居重建失败
- 设备替换验收清单：把 MTU 检查项写进核对表，避免上线后才暴露
华为 VRP
华为 VRP
[Huawei-GigabitEthernet0/0/1] ospf mtu-enable
! 缺省不检查；开启后 DBD 携带接口 MTU，两端不一致则邻居无法 FULL
[Huawei] interface GigabitEthernet0/0/1
[Huawei-GigabitEthernet0/0/1] mtu 1400 # 治本：两端统一改小
<Huawei> display ospf interface GigabitEthernet0/0/1思科 IOS
思科 IOS
SW-CORE-01(config-if)# ip ospf mtu-ignore
! 缺省检查；两端 MTU 不一致时邻居卡 EXSTART，临时绕过用本条
SW-CORE-01(config-if)# mtu 1400 # 或者统一改 MTU 治本
SW-CORE-01# show ip ospf interface GigabitEthernet0/1H3C Comware
H3C Comware
[H3C-GigabitEthernet1/0/1] ospf mtu-enable
! 同华为：缺省不检查，开启后严格校验
[H3C-GigabitEthernet1/0/1] mtu 1400
<H3C> display ospf interface GigabitEthernet1/0/1治本做法是两端把接口 MTU 改一致（隧道场景统一改小），mtu-ignore 或「不开检查」只是让协议层不再报错：大包路径的问题依然存在，只是被推到了业务层。
检查的是 OSPF DBD 中的接口 MTU 字段，不是配置里所有 MTU 相关项。开启检查会让不一致显式暴露，是推动全网 MTU 统一的有效抓手。