03-OSPFv3故障处理手册
本章节下载: 03-OSPFv3故障处理手册 (213.56 KB)
· OSPFv3邻居Down
· OSPFv3邻居震荡
本类故障的常见原因主要包括:
· BFD会话Down,即BFD检测到链路故障。
· 对端设备故障。
· CPU利用率或内存利用率过高。
· 链路故障。
· OSPFv3接口没有Up。
· 两端IP地址不在同一网段。
· 两端OSPFv3参数的配置不匹配:
¡ RouterID配置冲突。
¡ 两端区域类型配置不一致。
¡ 两端OSPFv3认证配置不匹配。
¡ 两端定时器参数配置不一致。
¡ OSPFv3接口的网络类型不匹配。
本类故障的诊断流程如图1-1所示。
图1-1 OSPFv3邻居Down的故障诊断流程图
(1) 通过命令行查看OSPFv3邻居状态变为Down的原因。
执行display ospfv3 event-log peer命令,显示信息中的Reason字段为邻居状态发生变化的原因,一般包含如下几种情况:
¡ DeadExpired
表示在邻居失效定时器超时前没有收到Hello报文,导致OSPFv3邻居状态变为Down。出现这种情况请执行步骤(2)。
¡ BFDDown
表示BFD会话Down导致OSPFv3邻居状态变为Down。出现这种情况请执行步骤(2)。
¡ 1-Way
表示对端OSPFv3状态首先变成Down,然后向本端发送1-way Hello报文,导致本端OSPFv3状态变为Init。出现这种情况请排查对端设备的故障。
¡ IntPhyChange
表示接口Down或者接口MTU改变导致邻居关系变为Down。此时,执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口的运行状态和相关信息,排查接口故障。其他情况请执行步骤(11)。
执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看OSPFv3接口物理层的状态是否为UP。
¡ 如果接口物理层的状态为DOWN,说明接口故障,请首先解决此问题。
¡ 如果接口物理状态为UP,则执行步骤(3)。
请执行ping命令,检查链路是否故障。如果链路正常,请执行步骤(4)。
(4) 检查CPU利用率是否过高。
请执行display cpu-usage命令检查CPU利用率。如果故障设备的主控板和接口板的CPU利用率过高,会导致OSPFv3无法正常收发协议报文,继而导致邻居震荡。可通过关闭一些不必要的功能解决此问题。如果CPU利用率不高,则执行步骤(5)。
请执行display memory-threshold命令,查看显示信息中的Current free-memory state,即系统当前内存使用状态。如果Current free-memory state为Minor、Severe或Critical,表示剩余空闲内存较少,可能会导致设备无法收发OSPFv3报文或处理OSPFv3报文速度较慢,请关闭一些不必要的功能尝试解决此问题。如果系统当前内存使用状态为Normal,则执行步骤(6)。
(6) 检查接口在OSPFv3协议下的状态是否正常。
执行display ospfv3 interface查看接口在OSPFv3协议下状态是否为正常状态。
¡ 如果OSPFv3接口状态为Down,检查接口是否使能了OSPFv3功能。如果使能了OSPFv3功能,请处理网络层接口故障问题。
¡ 如果OSPFv3接口协议状态正常,即接口状态为DR、BDR、DROther或P-2-P时,请执行步骤(7)。
(7) 检查各OSPFv3接口的MTU是否一致。
如果接口下未配置ospfv3 mtu-ignore命令,则要求接口的MTU一致,否则无法建立OSPFv3邻居关系。请执行display interface [ interface-type [ interface-number | interface-number.subnumber ] ]命令查看接口MTU信息。
¡ 如果接口的MTU值配置不一致,请在接口视图下执行mtu size命令,将各个接口的MTU值修改为一致。
¡ 如果接口的MTU值一致,请执行步骤(8)。
(8) 检查各接口的DR优先级是否非零。
对于Broadcast和NBMA类型的网络,为了保证正确选举出DR,需要保证至少有一个OSPFv3接口的DR优先级是非零的,否则两边的邻居状态只能达到2-Way。请使用display ospfv3 interface命令查看OSPFv3接口信息,其中的Priority表示接口的DR优先级。
如果接口的DR优先级非零,请执行步骤(9)。
(9) 是否手工为NBMA网络或P2MP单播网络指定了邻居。
OSPFv3网络类型为NBMA或P2MP(unicast)时,必须通过ospfv3 peer命令手工指定邻居接口的链路本地地址。请在OSPFv3接口视图下使用display this命令查看接口的网络类型,如果接口的网络类型为NBMA或P2MP(unicast),请在OSPFv3接口视图下使用ospfv3 peer命令手工指定邻居接口的链路本地地址。
如果手工为NBMA网络或P2MP单播网络指定了邻居接口的链路本地地址,请执行步骤(10)。
(10) 检查两端OSPFv3的参数配置是否有错误。
a. 请使用display ospfv3命令检查两端OSPFv3 Router ID配置是否冲突。如果OSPFv3 Router ID配置冲突,请修改配置保证OSPFv3 Router ID不再冲突。如果OSPFv3 Router ID配置不冲突,请继续执行以下检查。
b. 请使用display ospfv3 interface命令检查两端OSPFv3 Area ID配置是否一致。如果OSPFv3 Area ID配置不一致,请修改配置保证OSPFv3 Area ID配置一致。如果OSPFv3 Area ID配置一致,请继续执行以下检查。
c. 请使用display ospfv3 interface命令检查两端接口的OSPFv3网络类型是否一致。如果OSPFv3网络类型不一致,请修改配置保证OSPFv3网络类型一致。需要说明的是,如果双方一端为PTP,另一端为Broadcast,那么邻居关系可以达到Full状态,但无法计算出路由信息。
如果接口的OSPFv3网络类型一致,请继续执行以下检查。
d. 请每隔10秒钟使用display ospfv3 statistics error命令检查一次OSPFv3的错误统计信息,并持续5分钟。需要查看的信息包括:
- 查看Authentication failure字段。如果这个字段值持续增长,说明建立OSPFv3邻居关系的两台设备上配置了不同的认证类型,请修改认证类型的配置,使两台设备上的认证类型保持一致。
- 查看HELLO: Hello-time mismatch字段。如果这个字段值持续增长,说明OSPFv3接口上配置的Hello定时器的值不同,请修改Hello定时器的配置,使OSPFv3接口的Hello定时器的值保持一致。
- 查看HELLO: Dead-time mismatch字段。如果这个字段值持续增长,说明OSPFv3接口上配置的Dead定时器的值不同,请修改Dead定时器的配置,使OSPFv3接口的Dead定时器的值保持一致。
- 查看HELLO: Ebit option mismatch字段。如果这个字段值持续增长,说明OSPFv3区域类型不一致(例如,一端的OSPFv3区域类型为普通区域,另一端的OSPFv3区域类型为Stub)。请修改OSPFv3区域配置,使两端的区域类型保持一致。
如果故障依然存在,请执行步骤(11)。
(11) 如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
模块名:OSPFV3-MIB
· ospfv3VirtIfStateChange (1.3.6.1.2.1.191.0.1)
· ospfv3NbrStateChange (1.3.6.1.2.1.191.0.2)
· ospfv3VirtNbrStateChange (1.3.6.1.2.1.191.0.3)
· OSPFV3/6/OSPFV3_LAST_NBR_DOWN
· OSPFV3/5/OSPFV3_NBR_CHG
OSPFv3的状态机包括Down、Init、2-way、Exstart、Exchange、Loading和Full。其中,稳定状态包括Down、2-way和Full:
· Down:表示未使能OSPFv3。
· 2-way:DRother之间的邻居关系。
· Full:形成邻接关系。
对于使用OSPFv3进行路由计算和路由转发的网络中,只有2-way和Full是正常的邻居状态。如果邻居状态既未处于2-way状态,也未处于Full状态,说明邻居关系不正常。
本类故障的常见原因主要包括:
· 链路故障,OSPFv3报文被丢弃。
· 接口的DR优先级配置不合理。
· 两端配置的OSPFv3 MTU值不同。
本类故障的诊断流程如图1-2所示。
图1-2 OSPFv3邻居Down的故障诊断流程图
(1) 使用display ospfv3 peer命令查看OSPFv3邻居信息,并根据不同的邻居状态进行相应的处理。
¡ 没有邻居信息。
请检查是否在OSPFv3进程下设置了Router ID,如果未设置Router ID,则OSPFv3进程无法运行。如果设置了Router ID,则表示OSPFv3邻居Down或者邻居震荡,请参见“1.1.1 OSPFv3邻居Down”故障处理。
¡ 邻居状态一直为Init。
表示对端设备收不到本端发送的Hello报文,此时请排查链路和对端设备是否故障。
¡ 邻居状态一直为2-way。
执行命令display ospfv3 interface verbose命令查看设备在OSPFv3接口的DR优先级是否为0:
如果OSPFv3接口的DR优先级为0,那么邻居状态为2-way属于正常情况。
如果OSPFv3接口的DR优先级不为0,请执行步骤(2)。
¡ 邻居状态一直是Exstart。
表示设备一直在进行DD协商,但无法进行DD同步,出现该情况有两种可能性:
- 接口无法正常收发超大报文
可以通过多次执行命令ping -s packet-size neighbor-address查看超大报文收发情况,将packet-size设置为1500或更大数值。如果无法Ping通,请先解决链路问题。
- 两端OSPFv3 MTU配置值不一致
如果OSPFv3接口下配置了ospfv3 mtu-ignore命令,则无需检查两端的OSPFv3 MTU值是否一致。
如果OSPFv3接口下未配置ospfv3 mtu-ignore命令,则需要检查两端的OSPFv3 MTU值是否一致。如果不一致,请修改OSPFv3接口的MTU值,使两端的OSPFv3 MTU值保持一致。
如果故障没有解决,请执行步骤(2)。
¡ 邻居状态一直是Exchange。
表示设备在进行DD交换,请参见邻居状态一直为Exstart状态的处理。
如果故障没有解决,请执行步骤(2)。
¡ 邻居状态一直是Loading。
如果使用display ospfv3 peer命令查看到邻居状态一直处于Loading,可以尝试执行reset ospfv3 [ process-id ] process命令重启OSPFv3进程。
如果故障没有解决,请执行步骤(2)。
(2) 如果故障仍然未能排除,请收集如下信息,并联系技术支持人员。
¡ 上述步骤的执行结果。
¡ 设备的配置文件、日志信息、告警信息。
无
无
不同款型规格的资料略有差异, 详细信息请向具体销售和400咨询。H3C保留在没有任何通知或提示的情况下对资料内容进行修改的权利!