对滞留在Exstart/Exchange状态的OSPF邻居进行故障排除

下载选项

  • PDF     (408.2 KB)
    在各种设备上使用 Adobe Reader 查看
  • ePub     (91.3 KB)
    在 iPhone、iPad、Android、Sony Reader 或 Windows Phone 上使用各种应用查看
  • Mobi (Kindle)     (106.4 KB)
    在 Kindle 设备上查看或在多个设备上使用 Kindle 应用查看
已更新: 2024 年 10 月 3 日
文档 ID:13684

非歧视性语言

此产品的文档集力求使用非歧视性语言。在本文档集中，非歧视性语言是指不隐含针对年龄、残障、性别、种族身份、族群身份、性取向、社会经济地位和交叉性的歧视的语言。由于产品软件的用户界面中使用的硬编码语言、基于 RFP 文档使用的语言或引用的第三方产品使用的语言，文档中可能无法确保完全使用非歧视性语言。 深入了解思科如何使用包容性语言。

关于此翻译

思科采用人工翻译与机器翻译相结合的方式将此文档翻译成不同语言，希望全球的用户都能通过各自的语言得到支持性的内容。 请注意：即使是最好的机器翻译，其准确度也不及专业翻译人员的水平。 Cisco Systems, Inc. 对于翻译的准确性不承担任何责任，并建议您总是参考英文原始文档（已提供链接）。

    简介

    本文档介绍如何对开放最短路径优先(OSPF)邻居停滞在Exstart和Exchange状态的情况进行故障排除。 

    先决条件

    要求

    建议用户熟悉基本OSPF操作和配置，特别是OSPF邻居状态。

    使用的组件

    本文档中的信息基于以下软件和硬件版本：

    • Cisco 2503 路由器

    • 要在两台路由器上运行的Cisco IOS®软件版本12.2(24a)

    本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始（默认）配置。如果您的网络处于活动状态，请确保您了解所有命令的潜在影响。

    规则

    有关文件规则的更多信息请参见“ Cisco技术提示规则”。

    背景信息

    形成邻接的OSPF状态包括Down、Init、2-way、Exstart、Exchange、Loading和Full。开放最短路径优先(OSPF)邻居停滞在Exstart/Exchange状态的原因可能很多。本文档重点介绍导致Exstart/Exchange状态的OSPF邻居之间的MTU不匹配。有关如何排除OSPF故障的详细信息，请参阅OSPF常见问题故障排除。

    Exstart 状态

    当两个 OSPF 邻居路由器建立双向通信并完成 DR/BDR 选择（在多路访问网络上）之后，路由器将转换到 exstart 状态。在此状态下，相邻路由器建立主/从关系并确定交换DBD数据包时使用的初始数据库描述符(DBD)序列号。

    交换状态

    一旦协商好Primary/Subordinate关系（具有最高路由器ID的路由器成为主要路由器），相邻路由器就会过渡到Exchange状态。在此状态下，路由器将交换 DBD 数据包，这些数据包描述了其整个链路状态数据库。路由器还会发送链路状态请求数据包，这些数据包从邻居请求更新的链路状态通告(LSA)。

    虽然 OSPF 邻居在正常的 OSPF 邻接关系构建过程中会转入 exstart/exchange 状态，但是 OSPF 邻居停滞在此状态是不正常的。下一节将介绍OSPF邻居停滞在此状态的最常见原因。有关不同OSPF状态的详细信息，请参阅了解OSPF邻居状态。

    邻居停滞在准备/交换状态

    当您尝试在Cisco路由器和其他供应商路由器之间运行OSPF时，问题最常出现。当路由器接口的最大传输单位(MTU)设置不匹配时neighboring，会发生此问题。如果MTU较大的路由器向邻居路由器发送了一个数据包，该数据包的大小大于邻居路由器上设置的MTU，则邻居路由器会忽略该数据包。发生此问题时，show ip ospf neighbor命令的输出将类似于下图所示。

    OSPF Neighbor

    本节介绍此问题的实际重现过程。

    本图中的路由器6和路由器7通过帧中继连接，并且路由器6已配置了5条重新分发到OSPF的静态路由。路由器 6 上串行接口的默认 MTU 为 1500，而路由器 7 上串行接口的 MTU 为 1450。每个路由器的配置都显示在表中（仅显示必要的配置信息）：

    路由器 6 配置 路由器 7 配置 
    interface Serial2

!--- MTU is set to its default value of 1500.

 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 no ip mroute-cache
 frame-relay lmi-type ansi
!
interface Serial2.7 point-to-point
 ip address 10.170.10.6 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 101
!
router ospf 7
 redistribute static subnets
 network 10.170.10.0 0.0.0.255 area 0
!
ip route 192.168.0.10 255.255.255.0 Null0
ip route 192.168.10.10 255.255.255.0 Null0
ip route 192.168.10.0 255.255.255.0 Null0
ip route 192.168.37.10 255.255.255.0 Null0
ip route 192.168.38.10 255.255.255.0 Null0
    		 
    interface Serial0
 mtu 1450
 no ip address
 no ip directed-broadcast
 encapsulation frame-relay
 frame-relay lmi-type ANSI
!
interface Serial0.6 point-to-point
 ip address 172.16.7.11 255.255.255.0
 no ip directed-broadcast
 frame-relay interface-dlci 110
!
router ospf 7
 network 172.16.11.6 0.0.0.255 area 0

    每个路由器的 show ip ospf neighbor 命令输出为：

    router-6#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
172.16.7.11      1   EXCHANGE/  -    00:00:36    172.16.7.11    Serial2.7
router-6#

router-7#show ip ospf neighbor

Neighbor ID     Pri   State           Dead Time   Address         Interface
10.170.10.6      1   EXSTART/  -     00:00:33    10.170.10.6    Serial0.6
router-7#

    当路由器 6 在 exchange 状态下发送大于 1450 字节（路由器 7 的 MTU）的 DBD 数据包时，将会发生问题。请在每个路由器上使用 debug ip packet 和 debug ip ospf adj 命令，以便查看OSPF邻接过程的发生。路由器 6 和 7 从步骤 1 到 14 的输出依次为：

    1. 路由器 6 的 debug 输出：

      <<<ROUTER 6 IS SENDING HELLOS BUT HEARS NOTHING, STATE OF NEIGHBOR IS DOWN>>>
      
00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on 
Serial2.7 is dead
00:03:53: OSPF: 172.16.7.11 address 172.16.7.11 on 
Serial2.7 is dead, state DOWN

    2. 路由器 7 的 debug 输出：

      <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

    3. 路由器 6 的 debug 输出：

      <<<ROUTER 6 SENDING HELLOS>>>
      
00:03:53: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), len 64, sending broad/multicast, proto=89
00:04:03: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 64, sending broad/multicast, proto=89

    4. 路由器 7 的 debug 输出：

      <<<OSPF NOT ENABLED ON ROUTER7 YET>>>

    5. 路由器 7 的 debug 输出：

      <<<OSPF ENABLED ON ROUTER 7, BEGINS SENDING HELLOS AND BUILDING A ROUTER LSA>>>
      
00:17:44: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 64, sending broad/multicast, proto=89
00:17:44: OSPF: Build router LSA for area 0, 
router ID 172.16.7.11, seq 0x80000001

    6. 路由器 6 的 debug 输出：

      <<<RECEIVE HELLO FROM ROUTER7>>>
      
00:04:04: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, 
Len 64, rcvd 0, proto=89
00:04:04: OSPF: Rcv hello from 172.16.7.11 area 0 from 
Serial2.7 172.16.7.11
00:04:04: OSPF: End of hello processing

    7. 路由器 6 的 debug 输出：

      <<<ROUTER 6 SEND HELLO WITH ROUTER7 ROUTERID IN THE HELLO PACKET>>>
      
00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 68, sending broad/multicast, proto=89

    8. 路由器 7 的 debug 输出：

      <<<ROUTER 7 RECEIVES HELLO FROM ROUTER6 CHANGES STATE TO 2WAY>>>
      
00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
Len 68, rcvd 0, proto=89
00:17:53: OSPF: Rcv hello from 10.170.10.6 area 0 from 
Serial0.6 10.170.10.6
00:17:53: OSPF: 2 Way Communication to 10.170.10.6 on 
Serial0.6, state 2WAY

    9. 路由器 7 的 debug 输出：

      <<<ROUTER 7 SENDS INITIAL DBD PACKET WITH SEQ# 0x13FD>>>
      
00:17:53: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32
00:17:53: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:17:53: OSPF: End of hello processing

    10. 路由器 6 的 debug 输出：

      <<<ROUTER 6 RECEIVES ROUTER7'S INITIAL DBD PACKET CHANGES STATE TO 2-WAY>>>
      
00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5, 
Len 52, rcvd 0, proto=89
00:04:13: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state INIT
00:04:13: OSPF: 2 Way Communication to 172.16.7.11 on 
Serial2.7, state 2WAY

    11. 路由器 6 的 debug 输出：

      <<<ROUTER 6 SENDS DBD PACKET TO ROUTER 7 (PRIMARY/SUBORDINATE NEGOTIATION - ROUTER 6 IS SUBORDINATE)>>>

      00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
      seq 0xE44 opt 0x2 flag 0x7 Len 32 
      00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), 
      Len 52, sending broad/multicast, proto=89 
      00:04:13: OSPF: NBR Negotiation Done. We are the SLAVE

    12. 路由器 7 的 debug 输出：

      <<<RECEIVE ROUTER 6'S INITIAL DBD PACKET (MTU MISMATCH IS RECOGNIZED)>>>
      
00:17:53: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
Len 52, rcvd 0, proto=89
00:17:53: OSPF: Rcv DBD from 10.170.10.6 on Serial0.6 
seq 0xE44 opt 0x2 flag 0x7 Len 32 mtu 1500 state EXSTART
00:17:53: OSPF: Nbr 10.170.10.6 has larger interface MTU

    13. 路由器 6 的 debug 输出：

      <<<SINCE ROUTER 6 IS SUBORDINATE SEND DBD PACKET WITH LSA HEADERS, SAME SEQ# (0x13FD) TO ACK ROUTER 7'S DBD. (NOTE SIZE OF PKT)>>>

      00:04:13: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
      seq 0x13FD opt 0x2 flag 0x2 Len 1472 
      00:04:13: IP: s=10.170.10.6 (local), d=224.0.0.5 (Serial2.7), 
      Len 1492, sending broad/multicast, proto=89

    14. 路由器 7 的 debug 输出：

      <<<NEVER RECEIVE ACK TO ROUTER7'S INITIAL DBD, RETRANSMIT>>>
      
00:17:54: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 68, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [1]

    此时，路由器6继续尝试确认来自路由器7的初始DBD数据包。

    00:04:13: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 68, rcvd 0, proto=89
00:04:13: OSPF: Rcv hello from 172.16.7.11 area 0 from
Serial2.7 172.16.7.11
00:04:13: OSPF: End of hello processing

00:04:18: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:18: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

00:04:18: OSPF: Send DBD to 172.16.7.11 on Serial2.7 
seq 0x13FD opt 0x2 flag 0x2 Len 1472
00:04:18: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 1492, sending broad/multicast, proto=89

00:04:23: IP: s=10.170.10.6 (local), d=224.0.0.5 
(Serial2.7), Len 68, sending broad/multicast, proto=89

00:04:23: IP: s=172.16.7.11 (Serial2.7), d=224.0.0.5,
Len 52, rcvd 0, proto=89
00:04:23: OSPF: Rcv DBD from 172.16.7.11 on Serial2.7
seq 0x13FD opt 0x2 flag 0x7 Len 32 mtu 1450 state EXCHANGE

    由于来自路由器 7 的 DBD 数据包对于路由器 7 MTU 而言太大，因此，路由器 7 从未得到路由器 6 的确认。路由器 7 将重复地重新传输 DBD 数据包。

    0:17:58: IP: s=172.16.7.11 (local), d=224.0.0.5
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [2]

00:18:03: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
00:18:03: IP: s=10.170.10.6 (Serial0.6), d=224.0.0.5, 
Len 68, rcvd 0, proto=89
00:18:03: OSPF: Rcv hello from 10.170.10.6 area 0 from
Serial0.6 10.170.10.6
00:18:03: OSPF: End of hello processing

00:18:04: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 68, sending broad/multicast, proto=89

00:18:03: OSPF: Send DBD to 10.170.10.6 on Serial0.6 
seq 0x13FD opt 0x2 flag 0x7 Len 32 00:18:03: OSPF: 
Retransmitting DBD to 10.170.10.6 on Serial0.6 [3]

00:18:08: IP: s=172.16.7.11 (local), d=224.0.0.5 
(Serial0.6), Len 52, sending broad/multicast, proto=89
router-7#

    由于路由器 6 的 MTU 较大，因此，它将继续接受来自路由器 7 的 DBD 数据包，以尝试对其进行确认，从而保持在 EXCHANGE 状态。

    由于路由器 7 的 MTU 较小，因此，它将忽略来自路由器 6 的确认以及一同出现的 DBD 数据包，继续重新传输初始的 DBD 数据包，从而保持在 EXSTART 状态。

    在步骤9和11中，路由器7和路由器6将带有标记0x7设置的首个DBD数据包作为主/从协商的一部分。确定Primary/Subordinate后，路由器7被选为主要路由器，因为它具有较高的路由器ID。步骤13和步骤14中的标志清楚地显示路由器7是主路由器（标志0x7），而路由器6是从属路由器（标志0x2）。

    在步骤 10 中，路由器 6 收到路由器 7 的初始 DBD 数据包，并转换到 2-way 状态。

    在步骤 12 中，路由器 7 收到路由器 6 的初始 DBD 数据包，并识别出 MTU 不匹配。（由于路由器 6 在 DBD 数据包的接口 MTU 字段中说明了其接口 MTU，因此，路由器 7 可识别出 MTU 不匹配。）路由器7拒绝了路由器6的初始DBD。路由器7重新传输初始DBD数据包。

    第13步显示，作为subordinate，路由器6采用路由器7的序列号，并发送包含其LSA报头的第二个DBD数据包，这将增加数据包的大小。但是由于此 DBD 数据包大于路由器 7 的 MTU，因此，路由器 7 从未收到此 DBD 数据包。

    在步骤13之后，路由器7继续将初始DBD数据包重新传输到路由器6，而路由器6继续发送遵循主序列号的DBD数据包。此循环无限期地继续下去，从而阻止任一路由器退出 exstart/exchange 状态。

    解决方案

    由于问题是由 MTU 不匹配导致的，因此，解决方案是更改任一路由器的 MTU，以便与邻居路由器的 MTU 匹配。

    注意：Cisco IOS软件版本12.0(3)引入了接口MTU不匹配检测。此检测包括OSPF，它在DBD数据包中通告接口MTU，这与OSPF RFC 2178附录G.9中的内容一致。当路由器收到通告的DBD数据包时，如果该MTU大于该路由器可以接收的MTU，则路由器会忽略该DBD数据包，且邻居状态仍处于Exstart状态。这将阻碍邻接的形成。要解决此问题，请确保链路两端上的 MTU 相同。

    在Cisco IOS软件12.01(3)中还引入了ip ospf mtu-ignore接口配置命令，此命令可关闭MTU不匹配检测；但是，此命令仅在极少数情况下需要，如下图所示：

    OSPF Turn Off MTU Mismatch Detection

    上图显示了Cisco Catalyst 5000上的一个光纤分布式数据接口(FDDI)端口，该端口有一个路由交换模块(RSM)连接到路由器2上的FDDI接口。RSM 上的虚拟 LAN (VLAN) 是 MTU 为 1500 的虚拟以太网接口，而路由器 2 上 FDDI 接口的 MTU 为 4500。在交换机的 FDDI 端口上收到数据包时，数据包将会进入背板，并且在交换器自身内部将会发生 FDDI 到以太网的转换/分段。这是一个有效的设置，但使用MTU不匹配检测功能时，路由器和RSM之间未形成OSPF邻接关系。由于FDDI和以太网MTU不同，因此，该ip ospf mtu-ignore 命令对于RSM的VLAN接口十分有用，可停止MTU不匹配的OSPF检测，并形成邻接。

    请注意，MTU不匹配虽然是最常见的原因，但并不是导致OSPF邻居停滞在Exstart/Exchange状态的唯一原因。此问题通常是由于无法成功交换 DBD 数据包而导致的。但是，根源可能在于以下原因之一：

    • MTU 不匹配

    • 单播中断。在Exstart状态下，路由器将单播数据包发送到邻居以选择Primary和Subordinate。这是正常的，但如果拥有点对点链路，就会发送多播数据包。以下为可能的原因：

      • 在高度冗余的网络中，异步传输模式(ATM)或帧中继环境中的错误虚电路(VC)映射。

      • MTU问题，这意味着路由器只能对特定长度的数据包执行ping操作。

      • 访问列表阻止单播数据包。

      • NAT在路由器上运行并转换单播数据包。

    • PRI 和 BRI/拨号器之间的邻居。

    • 两台路由器具有相同的路由器ID（配置错误）。

    此外，OSPF RFC 2328第10.3部分中指明，针对以下任一事件（任何事件都可能由内部软件问题引起）会启动Exstart/Exchange过程：

    • 序列号不匹配。

      • 意外的 DD 序列号.

      • 意外地设置了“I”位.

      • 选项字段与 DBD 数据包中收到的上一个选项字段不同.

    • BadLSReq

      • 邻居在交换过程中发送了无法识别的 LSA。

      • 邻居在交换过程中请求的 LSA 无法找到.

    当OSPF未形成邻居时，请考虑前面提到的因素，例如物理介质和网络硬件，以便排除故障。

    相关信息

    修订历史记录

    版本 发布日期 备注
    3.0
    03-Oct-2024
    已删除PII。 已更新标题、替代文本和格式。
    2.0
    18-Sep-2023
    重新认证
    1.0
    10-Dec-2001
    初始版本
    TAC Authored

    由思科工程师提供

    • 思科TAC工程师

    此文档是否有帮助?

    Feedback反馈

    联系我们