OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange

Trap Buffer Description

The status of the non-virtual neighbor has changed. (RouterId=[RouterId], NbrIpAddress=[NbrIpAddress], NbrAddressLessIndex=[NbrAddressLessIndex], NbrRtrId=[NbrRtrId], NbrState=[NbrState], ProcessId=[ProcessId], AreaId=[AreaId], IfnetIndex=[IfnetIndex], LocalIfIpAddress=[LocalIfIpAddress], IfName=[IfName], VpnName=[VpnName], Reason=[NbrStateChangeReason], SubReason=[SubReason])

The status of the neighbor on the non-virtual link changed. The neighbor status changes from Full or Init to Down. For broadcast and NBMA networks, the neighbor status between DR Others changes from 2-way to Down and an alarm is reported. Other neighbor status changes are repeated as the full-to-non-full alarm. After the neighbor relationship is restored to the Full state, services are restored, and an alarm clearance message is reported. For broadcast and NBMA networks, when the neighbor status between DR Other devices becomes 2-way again, a message indicating that the alarm is cleared is reported. The device has been disabled from sending a clear alarm after the neighbor is deleted.

Trap Attributes

Trap Attribute	Description
Alarm or Event	Alarm
Trap Severity	Critical
Mnemonic Code	ospfNbrStateChange
Trap OID	1.3.6.1.2.1.14.16.2.2
MIB	OSPF-TRAP-MIB
Alarm ID	0x08900005
Alarm Name	ospfNbrStateChange
Alarm Type	communicationsAlarm
Raise or Clear	Raise
Match trap	-

Trap Buffer Parameters

Parameter	Description
RouterId	Indicates the router ID.
NbrIpAddress	Indicates the IP address of the neighbor.
NbrAddressLessIndex	Indicates the interface index.
NbrRtrId	Indicates the router ID of the neighbor.
NbrState	Indicates the neighbor status. The trap is a service restoration trap only when the value of Full. Otherwise, it is a fault trap. 1: Down. 2: Attempt. 3: Init. 4: 2-Way. 5: ExStart. 6: Exchange. 7: Loading. 8: Full.
ProcessId	Indicates the process ID.
AreaId	Indicates the area ID.
IfnetIndex	Indicates the physical interface index.
LocalIfIpAddress	Indicates the IP address of the local interface.
IfName	Indicates the physical interface name.
VpnName	Indicates the VPN name.
NbrStateChangeReason	Indicates the reason why the neighbor status changes. [1]Adjacency HoldTimer Expired. [2] Physical Interface State Change. [3] Protocol reason. [4] BFD session state change. [5] Configuration change. [6] Peer router reason. [7] Waiting for establishing neighbor. [99] Alarm clear. [101] Neighbor deleted. [102] Neighbor full. [103] Interface silent. [104] Interface deleted. [105] DR/BDR change.
SubReason	Indicates the detailed reason. [57] Neighbor deleted. [58] Neighbor full. [59] Interface silent. [60] Interface deleted. [61] DR/BDR change. [62] Configuration change.

VB Parameters

VB OID	VB Name	VB Index
1.3.6.1.2.1.14.1.1	ospfRouterId	-
1.3.6.1.2.1.14.10.1.1	ospfNbrIpAddr	ospfNbrIpAddr ospfNbrAddressLessIndex
1.3.6.1.2.1.14.10.1.2	ospfNbrAddressLessIndex	ospfNbrIpAddr ospfNbrAddressLessIndex
1.3.6.1.2.1.14.10.1.3	ospfNbrRtrId	ospfNbrIpAddr ospfNbrAddressLessIndex
1.3.6.1.2.1.14.10.1.6	ospfNbrState	ospfNbrIpAddr ospfNbrAddressLessIndex

Impact on the System

Whenever the non-virtual neighbor status changes, the trap will be sent.

If the neighbor changes from a lower state to a higher state, this trap message is informational only and no action is required.
If the neighbor changes from a higher state to a lower state, services may be interrupted.

The OSPF neighbor states arranged in ascending order are: down->init->2-way->exstart->exchange->loading->full.

Possible Causes

Cause 1: Adjacency holdTimer expired
Cause 2: Physical interface change
Cause 3: Protocol reason
Cause 4: BFD session state change
Cause 5: Configuration change
Cause 6: Peer router reason

Procedure

Cause 1: Adjacency holdTimer expired
1. Run the ping command to check whether the link that connects the local and remote devices functions properly.
- If the ping fails, check the transport devices, link status, and interface status and rectify faults (if any) on the physical devices to restore OSPF services.
- If the ping succeeds, go to Step 2.
2. Collect alarm information and configuration information, and then contact technical support personnel.
Cause 2: Physical interface change
1. Run the display ospf interface command to check the status of the physical interface used to set up the OSPF neighbor relationship.
- If the physical interface is in the Down state, check whether the optical power of the physical interface is within the permitted range and whether the transport device works properly. Restore the physical interface status to clear the alarm.
- If the physical interface is in the *down state, the interface has been shut down. Then run the undo shutdown command on the interface to clear the alarm.
- If the physical interface is in the Up state, go to Step 2.
2. Run the display ospf interface command to check the protocol status of the interface used to set up the OSPF neighbor relationship.
- If the protocol state is Down, check whether the interface IP addresses are configured correctly. If no, configure the IP addresses correctly to clear the alarm.
- If the protocol state is Up, go to Step 3.
3. Collect alarm information and configuration information, and then contact technical support personnel.
Cause 3: Protocol reason
1. Run the display this command in both the interface view and OSPF view of the local and remote devices to check whether the two devices use the same protocol.
- If the two devices use the same protocol, go to Step 2.
- If the two devices use different protocols, configure the same protocol for the interfaces.
2. Run the display ospf peer command to view OSPF neighbor information.
- If no OSPF neighbor information is displayed, the local device cannot receive any Hello messages from the remote device or the received Hello messages have been discarded. Then go to Step 3.
- If Init is displayed, the local device can receive Hello messages from the remote device, whereas the remote device cannot receive any Hello messages from the local device. Run the ping command to check whether the link that connects the local and remote devices functions properly. A common cause for the OSPF neighbor to stay in the Init state is that a fault occurs in packet forwarding and hence packets are discarded. If the alarm persists after the fault in packet forwarding is rectified, go to Step
- If 2-way is displayed, the value of ospf dr-priority is 0. Run the ospf dr-priority command to set the DR priority of the interface to a value larger than 0 to clear the alarm.
- If Exstart is displayed, the device generating this alarm keeps performing DD negotiation but fails to complete DD synchronization. Then go to Step 3.
- If Loading is displayed, the local device has received invalid LSA packets and keeps sending LSA requests. Run the reset
ospf process command at both ends of the link to clear the alarm.

The OSPF neighbor relationship may be deleted after you run the reset ospf process command to reset the OSPF connection. Run this command only when it is very necessary.

3. Run the display this command in the interface view and OSPF view to check whether authentication modes configured for both ends are the same.
- If the authentication modes configured for both ends are the same, go to Step 4.
- If the authentication modes configured for both ends are different, change them to be the same.
4. Collect alarm information and configuration information, and then contact technical support personnel.
Cause 4: BFD session state change
1. Run the ping command to check whether the link that connects the local and remote devices functions properly.
- If the ping fails, check the transport devices, link status, and interface status and rectify faults (if any) on the physical devices to restore OSPF services.
- If the ping succeeds, go to Step 4.
2. Run the ping command in the interface view to check whether the link is configured correctly.
- If the link is correctly configured, go to Step 3.
- If the link is incorrectly configured, correct link configurations.
3. Run the display ospf peer command to check whether the OSPF neighbor is in the Up state.
- If the OSPF neighbor is in the Up state, go to Step 4.
- If the OSPF neighbor is in the Down state, correct link configurations.
4. Collect alarm information and configuration information, and then contact technical support personnel.
Cause 5: Configuration change
1. Run the display this command in the OSPF view to check whether area configurations at both ends of the neighbor are consistent.
- If area configurations at both ends are inconsistent, change them to be the same.
- If area configurations at both ends are consistent, go to Step 2.
2. Run the display this command in the OSPF view to check whether opaque-capability has been enabled for the OSPF processes at both ends.
- If opaque-capability has been enabled only for one OSPF process, enable opaque-capability for the OSPF process at the other end.
- If opaque-capability has been enabled for the OSPF processes at both ends, go to Step 3.
3. Run the display ospf interface command to check whether OSPF network types configured on the interfaces at both ends are consistent.
- If OSPF network types configured on the interfaces at both ends are inconsistent, change them to be the same.
- If OSPF network types configured on the interfaces at both ends are consistent, go to Step 4.
4. Collect alarm information and configuration information, and then contact technical support personnel.
Cause 6: Peer router reason
1. Check whether the peer router is a non-Huawei device.
- If it is a non-Huawei device, go to Step 2.
- If it is a Huawei device, go to Step 3.
2. Contact the non-Huawei device manufacturer to check its operating status and rectify the fault.

3. Check whether the peer router or the OSPF process has been restarted.
- If the peer router or the OSPF process has been restarted, refer to alarm and log information to identify the cause.
- If the peer router or the OSPF process has not been restarted, go to Step 4.
4. Collect alarm information and configuration information, and then contact technical support personnel.