OSPF邻居卡在ExStart？MTU不匹配的排错实战与原理解析

刚处理完一个现场故障，两台核心交换机的OSPF邻居卡在ExStart状态，业务没断，但双链路变成了单链路，流量全压在一台上。排查到最后，问题出在接口MTU上——一台开了Jumbo Frame，另一台还是默认1500。这种问题在OSPF的教科书里基本不会细讲，但在现网里却是高频踩坑点。

这篇文章我不打算写成一份OSPF的官方手册，而是从一个常年被拉去救火的运维视角，把原理、配置、排错串成一条线。无论你是刚接触网络的新人，还是已经会配OSPF但没真正理解它在干什么的老手，这篇内容都能给你一些有用的参考。

1. OSPF是什么：链路状态路由协议的底层逻辑

1.1 链路状态协议和距离矢量协议的本质差异

理解OSPF之前，先搞清楚它与RIP这类距离矢量协议的根本区别。

RIP的工作方式可以类比成“邻居转告”：每台路由器只告诉邻居“我能到哪些网段”，邻居再把听到的消息转告给下一个邻居。这种方式的问题在于，每台路由器对网络的认识完全依赖邻居的描述，它自己看不到全貌。举个例子，A告诉B能到10.0.0.0/8，B把这条消息转告给C，C只知道“经过B能到10.0.0.0/8”，但至于B是通过哪条路到10.0.0.0/8的，C一概不知。如果B的路径里有环路，C也无从察觉，只能靠跳数上限硬性兜底。

OSPF则完全不同，它是链路状态协议，核心思想是“大家各自上报自己知道的那段路况，然后每台路由器都拼出完整地图”。每台路由器都会向整个区域广播链路状态通告（LSA），描述自己有哪些接口、对端是哪个邻居、链路开销是多少。区域内的所有路由器最终会拥有完全相同的链路状态数据库（LSDB），相当于人手一份完整的网络地图。

有了这张完整地图，每台路由器就不再依赖邻居的转述，而是自己独立计算去往每个目的地的最短路径。这就是OSPF天然防环的根本原因——它不是靠“听说”来判断路径，而是靠“算”出来的。环路在SPF计算阶段就会被排除，不需要额外的环路防护机制。

1.2 SPF算法：把网络当成一张带权图

SPF（Shortest Path First）算法，也叫Dijkstra最短路径算法，是OSPF的核心计算引擎。

这里用导航软件来理解最直观。地图App会先把道路抽象成一张带权图：路口是节点，道路是边，道路距离、红绿灯数、拥堵情况是权重。你的位置是起点，目的地是终点，导航App在整张图上跑一遍最短路径算法，找到权重总和最小的一条路。

OSPF的SPF计算一模一样。每台路由器以自己为根节点，把LSDB里的所有LSA当作图的信息，用Dijkstra算法计算到达每个网段的最短路径树。计算完成后，从这棵树上提取去往各网段的最优路由，写入路由表。

关键点在于，SPF算法只在网络拓扑发生变化时才重新计算，而不是像RIP那样定期把整个路由表广播一遍。OSPF的LSA也有老化机制（默认3600秒），但正常情况下只有当链路up/down、接口开销变化、新路由器加入时才会触发新的LSA泛洪和SPF重算。这也是OSPF收敛速度优于RIP的结构性原因。

1.3 区域(Area)到底是用来干什么的

区域是OSPF架构里最容易理解错的概念。很多教材直接告诉你“把网络划分成区域可以减少LSA泛洪”，但没说清楚为什么。

假设一个网络里有100台路由器，全部在同一个区域，那么任意一台路由器的接口状态变化，都会触发LSA在整个区域里泛洪，所有100台设备都要重新运行SPF算法。随着设备数量增长，这种计算量和网络冲击是平方式增长的，网络会越来越脆弱。

区域的作用就是把LSA泛洪的范围限制住。区域内产生的Router-LSA和Network-LSA只在本区域内泛洪，不会跑到其他区域去。区域之间的路由信息由ABR（区域边界路由器）汇总成Type-3 LSA（Network Summary LSA）后再传递给其他区域。这样，一个区域的网络震荡就被隔离在了区域内，不会波及全网。

不过区域设计有一条铁律：所有非骨干区域必须直接连接到骨干区域（Area 0）。原因是区域间路由必须经过骨干区域中转，如果某个区域不连Area 0，它就跟其他区域断了联系。思科和华为都有虚链路（Virtual Link）技术可以解决区域不连骨干的问题，但虚链路本质上是走一条逻辑隧道，属于过渡方案，不应该作为长期设计。

2. 邻居关系建立与LSDB同步：OSPF的“认亲”和“对账”

2.1 从Down到Full：邻居状态机的完整过程

OSPF邻居建立不是瞬间完成的，而是经历一个完整的状态机。理解这个过程，是排错的基础。

邻居状态依次经过Down、Init、2-Way、ExStart、Exchange、Loading、Full这七个状态。

• Down：初始状态，接口没有收到任何对端发来的Hello报文。
• Init：收到了对端的Hello报文，但Hello里没有包含自己的Router ID，说明对端还没“看见”我。
• 2-Way：双方都从Hello报文中看到了对方的Router ID，互相确认了对方的存在。在这个阶段，广播网络和NBMA网络会进行DR/BDR选举。如果两端只是邻居关系而不是邻接关系，状态会停留在2-Way。
• ExStart：开始协商主从关系，确定谁先发送DBD报文。这个阶段还要协商初始的DBD序列号。
• Exchange：双方互相交换DBD报文，描述自己LSDB里有哪些LSA，相当于“对账”——告诉对方我有哪些记录。
• Loading：对账发现缺失或过期的LSA后，通过LSR报文向对方请求，对方用LSU报文回应。
• Full：LSDB完全同步，邻接关系建立完成。

在以太网这类广播网络中，只有DR和BDR会与所有其他路由器建立Full状态的邻接关系，非DR/BDR设备之间只保持在2-Way状态。这是OSPF在广播网络上的一个特有设计，后面专题讲。

2.2 五种OSPF报文的角色分工

OSPF有五种报文，每种都有明确的任务：

• Hello报文：邻居发现与维护。周期性发送（广播网络默认10秒一次，Dead间隔40秒），携带Router ID、区域ID、Hello/Dead定时器、可选的DR/BDR、邻居列表等信息。
• DBD报文（Database Description）：数据库描述报文，用于主从协商和交换LSA摘要信息。
• LSR报文（Link State Request）：发送给对端，请求自己缺失或过期的LSA。
• LSU报文（Link State Update）：承载完整的LSA内容，是真正传输链路状态信息的报文。
• LSAck报文（Link State Acknowledgement）：对收到的LSU报文进行确认，保证可靠传输。

这五种报文的流程可以从一次邻居建立过程串起来：先用Hello互相发现，再用DBD对账，缺失信息用LSR请求、LSU补发、LSAck确认，最终完成LSDB同步。

2.3 DR/BDR选举：为什么广播网络非要选“代表”

在以太网这种广播网络中，如果多台路由器接在同一个二层域里，两两之间都建立Full邻接关系的话，设备数量为n时会产生n*(n-1)/2个邻接关系。8台设备就要建28个邻接，LSA泛洪时每个邻居都要发一份，效率极低。

DR/BDR机制的引入，把广播网络中的邻接关系数量从n*(n-1)/2降到了2n-3左右。所有路由器只和DR、BDR建立Full邻接，普通路由器之间不用建立邻接。LSA先发给DR，DR再转发给其他所有路由器。

选举规则不复杂：接口优先级（Priority）数值越大越优先，默认值是1，0表示不参与选举；优先级相同则Router ID大者胜出。

但有一点必须说清楚：DR/BDR是非抢占的。当网络上已经存在DR和BDR时，即使新加入的路由器优先级更高、Router ID更大，它也不会取代现有的DR/BDR。只有当前DR或BDR故障后，新的选举才会触发。这个设计是为了避免DR频繁切换导致网络震荡。实际工程中经常出现的情况是，一台高配设备因为启动晚，长期当不了DR，直到原来的DR宕机才能上位。如果想让某台设备稳定成为DR，最好把其他设备的优先级调低，或者指定DR的优先级为255，同时在其他接口上关闭DR选举（优先级设为0）。

3. 华为设备上的OSPF配置：从单区域到多区域实操

3.1 华为设备标准配置：三行命令建立邻居

以两台华为路由器为例，互联接口分别是GE0/0/0，网段10.0.12.0/24，R1的Router ID是1.1.1.1，R2是2.2.2.2。

R1的配置：

code复制system-view
sysname R1
interface GigabitEthernet0/0/0
 ip address 10.0.12.1 255.255.255.0
quit
ospf 1 router-id 1.1.1.1
 area 0
  network 10.0.12.0 0.0.0.255
quit

R2的配置类似，IP换成10.0.12.2，Router ID改为2.2.2.2，同样在Area 0里宣告10.0.12.0这个网段。

配置完成后，两台设备会自动通过Hello报文发现对方，经过状态机流程建立Full邻接关系。

这里有个新手经常踩的坑：network命令里的通配符掩码。它跟ACL里的反掩码是一个逻辑，0.0.0.255匹配的是/24位前缀，也就是只匹配前24位固定、后8位任意的地址。如果写错了，比如该写0.0.0.255写成了0.0.0.15，那就只匹配10.0.12.0到10.0.12.15这16个地址，这个网段就进不了OSPF，邻居自然起不来。

3.2 多区域与ABR汇总配置

真实网络中单区域很少见，多区域是常态。当一台路由器同时连接到Area 0和Area 1时，它就是ABR。

R3的配置示例：

code复制ospf 3 router-id 3.3.3.3
 area 0
  network 10.0.13.0 0.0.0.255
 area 1
  network 192.168.1.0 0.0.0.255
  network 192.168.2.0 0.0.0.255

配置ABR后，Area 1里的192.168.1.0/24和192.168.2.0/24会以Type-3 LSA的形式被R3通告到Area 0。默认情况下，ABR会通告每一条明细路由。如果Area 1里网段很多，在ABR上做汇总能有效减少骨干区域的LSA数量，同时还能隐藏区域内部的网络震荡。

华为的ABR汇总命令是在区域视图下配置：

code复制ospf 3
 area 1
  abr-summary 192.168.0.0 255.255.0.0

这条命令的作用是，把Area 1内192.168.1.0/24、192.168.2.0/24等都在192.168.0.0/16范围内的路由，聚合成一条汇总路由通告到Area 0。

如果网络引入了其他协议的外部路由（比如静态路由导入OSPF），并且需要对外汇总，使用asbr-summary命令，配置位置在OSPF进程视图下：

code复制ospf 3
 asbr-summary 10.0.0.0 255.0.0.0

3.3 配置验证与常用查看命令

配置完成不等于万事大吉，验证环节不能省。我常用的验证命令：

• display ospf peer：查看邻居状态，确认是否达到Full
• display ospf lsdb：查看链路状态数据库，确认LSA是否正常
• display ospf routing：查看OSPF路由表，确认路由是否计算正确
• display ospf interface：查看接口参与OSPF的状态、网络类型、定时器等

以display ospf peer为例，看到Full表示邻接关系正常。如果卡在其他状态，就要对照前面讲的状态机排查。我习惯在配置完成后把这几条命令都过一遍，确认邻居状态和路由都正常后才算配置完成。

4. 排错实录：DR和BDR的MTU不一致导致邻居卡死

4.1 故障现场：邻居卡在ExStart

回到文章开头说的那个故障场景。

网络是两台核心交换机做了双链路互联，两台设备上都运行OSPF，Area 0。核心下还挂着汇聚设备。某次割接后，其中一台核心的接口MTU被调成了9000（为了给大流量的业务开Jumbo Frame），另一台核心保持默认的1500。结果两台核心之间OSPF的邻居状态卡在了ExStart，怎么也到不了Full。

从华为设备上看到的邻居状态大致是：

code复制<DeviceA> display ospf peer

         OSPF Process 1 with Router ID 10.0.0.1
                 Neighbors

 Area 0.0.0.0 interface 10.0.12.1 (GigabitEthernet0/0/0)
 Neighbor ID      Pri  State         Dead Time  Address         Interface
 10.0.0.2          1    ExStart/Backup 00:00:34  10.0.12.2      GigabitEthernet0/0/0

State那一列显示ExStart，说明双方在协商主从关系的阶段就卡住了，根本没有进入Exchange阶段。

4.2 一步一步缩小范围：从ping到抓包

排错的时候不要一上来就怀疑协议配置，先按照从物理层到应用层的顺序排查。

第一步，确认物理链路和接口状态。看两端接口是否Up，有没有错包、丢包。这一步排除了物理链路问题。

第二步，确认三层连通性。ping对端接口地址，发现小包（比如100字节）能通，但大包（比如2000字节）不通。这是一个非常关键的信号，它说明三层可达，但可能存在MTU不匹配或者路径上有设备分片受限的问题。ping大包不通这个线索，直接指向了MTU相关的方向。

第三步，查看OSPF邻居状态，发现卡在ExStart。这说明Hello报文的收发是正常的，否则根本走不到ExStart，问题出在Hello之后的交互上。

第四步，对比两端的接口MTU。在华为设备上用display interface GigabitEthernet0/0/0查看，发现DeviceA的MTU是9000，DeviceB的MTU是1500。到这里，问题基本锁定了。

第五步，如果条件允许，在两端同时抓包看OSPF报文交互，能看到DBD报文一直在发送，但始终没有后续的LSR/LSU交互，这进一步确认了卡在DBD协商阶段。

4.3 MTU为什么能卡死OSPF邻居

很多人不理解，MTU不是只影响数据包大小吗，怎么会影响OSPF邻居状态？

关键在于DBD报文。OSPF的邻居双方在ExStart和Exchange阶段交换的DBD报文里，携带了一个字段——发送端接口的MTU值。接收方收到这个DBD报文后会检查该字段，如果对端的MTU大于自己的接口MTU，就认为无法正常接收对方后续可能发来的大尺寸报文，于是拒绝继续推进邻居状态。

在思科设备上，这个检查是严格执行的，MTU不匹配的后果就是邻居状态卡在ExStart/Exchange。华为设备默认也检查MTU，同样会卡住。这就是“DR的MTU大于BDR的MTU”时邻居建立失败的根源：DR发出的DBD里填的MTU是9000，BDR收到后发现9000大于自己的1500，判定MTU不匹配，导致协商无法完成。

这个字段的设计初衷是保证双方能够接收彼此最大尺寸的DBD报文，避免在同步LSDB时出现报文过大被丢弃、反复重传的情况。但副作用就是成了一颗雷——只要链路两端MTU不一致，OSPF邻居就起不来。

4.4 修复与预防

解决MTU不匹配的标准方案是把两端接口的MTU改成一致，这也是最推荐的做法。核心设备之间的互联链路，建议统一规划MTU，要么都开Jumbo Frame，要么都保持1500，不存在中间状态。

如果某些特殊场景确实无法统一MTU，可以关闭OSPF的MTU检查。华为设备在接口视图下配置：

code复制interface GigabitEthernet0/0/0
 ospf mtu-ignore

不同版本的华为设备命令可能有差异，敲命令时后面带问号确认一下。思科设备的对应命令是：

code复制interface GigabitEthernet0/0/0
 ip ospf mtu-ignore

这里有个重要的操作细节：修改MTU或者配置了mtu-ignore之后，OSPF进程不会自动重置，需要手动重置才能让邻居重新建立。华为设备用reset ospf process，思科设备用clear ip ospf process。不少工程师改了配置后发现邻居还是卡着，就是因为没有重置OSPF进程。

另外，排查这类问题时还有一个容易被忽略的场景：设备开启了堆叠、VXLAN、QinQ等特性，接口的实际MTU可能和你用display interface看到的MTU不完全一致。排查时要把这些因素都考虑进去。

5. 加餐：几个容易踩的坑与设计建议

5.1 定时器不匹配：一个很隐蔽的邻居故障

MTU问题的排查思路是“卡在ExStart看MTU”，但如果邻居连ExStart都到不了，一直卡在Init或者干脆显示Down，那就要检查Hello定时器了。

OSPF的Hello间隔和Dead间隔必须两端一致，否则邻居建立失败。在广播网络和点到点网络中，Hello默认10秒，Dead默认40秒；在NBMA和点到多点网络中，Hello默认30秒，Dead默认120秒。

华为设备上可以用display ospf interface查看接口的Hello/Dead定时器配置。如果发现不匹配，在接口视图下修改：

code复制interface GigabitEthernet0/0/0
 ospf timer hello 10
 ospf timer dead 40

修改的时候注意先改Dead再改Hello，避免中间状态导致邻居中断。虽然现在很少手动去改这个值，但在对接友商设备或者特殊组网时，这种问题一旦出现，排查起来非常头疼。

5.2 静默接口与认证的必要性

很多人不知道华为和思科都有“静默接口”这个功能，华为的命令是silent-interface，思科的命令是passive-interface。配置了静默接口后，该接口不再接收和发送Hello报文，因此不会和这个接口下的设备建立OSPF邻居关系，但接口所在的网段仍然会被OSPF通告出去。

这个功能主要用在连接终端的接口上。比如一台核心交换机下挂了一个终端网段，你不希望终端设备能跟核心交换机建立OSPF邻居，这个接口就应该配置成静默接口。如果不配，任何接入这个网段的设备都可以通过发送Hello报文参与OSPF交互，这是安全风险。

还有一个安全相关的建议：生产环境尽量开启OSPF认证。华为支持区域认证和接口认证两种方式，可以在区域视图下配置统一认证模式，也可以在接口下单独配置。认证方式分为明文认证和MD5认证，建议使用MD5或更强的HMAC-SHA256认证。开启认证后，未通过认证的报文会被丢弃，这能有效防止有人接入网络注入虚假路由。

5.3 双链路上行场景下的OSPF表现

双核心、双上行的组网里，OSPF的表现值得单独说。

在双链路都正常的情况下，OSPF会自动计算出两条等价的路径，形成等价负载分担（ECMP）。华为设备默认支持多条等价路由同时生效，不需要额外配置。流量会被哈希到两条链路上，链路利用率会更高。

但有些业务不希望默认的负载分担，而是希望“一主一备”。这种情况不需要复杂的策略，最简单的做法是调整备链路的OSPF开销值，让它比主链路大一点。比如主链路开销为10，备链路开销为20，OSPF会优先选择开销小的主链路；主链路故障后，备链路自动接管，主链路恢复后流量自动切回。

这个方案的关键是理解OSPF开销值的计算逻辑。华为设备默认的带宽参考值是100Mbit/s，接口开销的计算公式是参考带宽除以接口带宽。具体来说，10M接口开销是10，100M接口开销是1，千兆和万兆接口按照公式算出来小于1，实际显示为1。如果想在万兆互联的链路上区分不同路径的优劣，建议把带宽参考值调大，比如调成10000，这样万兆接口开销是1，千兆接口是10，路径选择会更精确。调整命令是：

code复制ospf 1
 bandwidth-reference 10000

另外，OSPF的收敛时间是秒级的。Hello 10秒、Dead 40秒意味着链路故障最多要等40秒才能被检测到，加上SPF重算时间，业务中断时间可能超过40秒。对于关键业务，这个时间完全无法接受。解决办法是部署BFD联动OSPF，BFD能在毫秒级检测到链路故障，然后立即通知OSPF快速收敛。华为的配置很简单，在OSPF进程视图下开启bfd all-interfaces enable，然后在接口下配置bfd min-transmit-interval和bfd min-receive-interval即可。

5.4 几个值得养成的调试习惯

最后分享几个实际排障中养成的习惯，这些都不是什么高深技术，但很实用。

第一个习惯是记录基线。每台设备的Router ID、运行OSPF的接口、区域划分、特殊配置项，都应该有一个文档记录。MTU、定时器这类参数一旦和基线不一致，排障效率会高很多。上面那个MTU问题的现场，如果不是碰巧记得两台设备原有的MTU配置，排查时间至少要翻倍。

第二个习惯是排查时先用display ospf error看看有没有协议错误计数。华为设备的display ospf error会统计各种OSPF报文错误，包括认证失败、MTU不匹配、邻居状态错误等。这个命令能快速缩小范围，不用一上来就抓包分析。

第三个习惯是修改配置后一定验证，验证完再继续改下一个配置。很多人喜欢一次性改完所有觉得有问题的地方，结果问题解决了却不知道是哪条命令起了作用，下次遇到同样的问题还得重新排查。一步步改、一步步验证，看起来慢，实际是最快的。

第四个习惯是充分理解厂商差异。华为和思科的OSPF虽然遵循同一份RFC标准，但默认参数、命令风格、部分行为细节都有差异。比如同样关闭MTU检查，华为接口下是ospf mtu-ignore，思科是ip ospf mtu-ignore；同样查看邻居，华为是display ospf peer，思科是show ip ospf neighbor。跨厂商组网时，这些差异都要心中有数。

OSPF这个协议，原理上不算复杂，但涉及的细节非常多。很多人从“会配”到“会用”，中间差的就是对协议的深入理解和对各种边界场景的认知。希望这篇内容能帮你把基础打扎实，在真正的故障面前少走一些弯路。