OSPF_1.3.6.1.2.1.14.16.2.3 ospfVirtNbrStateChange

Trap Buffer Description

The status of the virtual neighbor changes. (VirtNbrArea=[VirtNbrArea], VirtNbrRtrId=[VirtNbrRtrId], ProcessId=[ProcessId], RouterId=[RouterId], VirtNbrState=[VirtNbrState], InstanceName=[InstanceName])

The status of the neighbor on the virtual link changed.

Trap Attributes

Trap Attribute	Description
Alarm or Event	Alarm
Trap Severity	Error
Mnemonic Code	ospfVirtNbrStateChange
Trap OID	1.3.6.1.2.1.14.16.2.3
MIB	OSPF-TRAP-MIB
Alarm ID	0x08902009
Alarm Name	ospfVirtNbrStateChange
Alarm Type	communicationsAlarm
Raise or Clear	Raise
Match trap	-

Trap Buffer Parameters

Parameter	Description
VirtNbrArea	Indicates the area ID.
VirtNbrRtrId	Indicates the router ID of the neighbor on the virtual link.
ProcessId	Indicates the process ID.
RouterId	Indicates the ID of the local router.
VirtNbrState	Indicates the status of a virtual neighbor. 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
InstanceName	Indicates the instance name.

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.11.1.1	ospfVirtNbrArea	ospfVirtNbrArea ospfVirtNbrRtrId
1.3.6.1.2.1.14.11.1.2	ospfVirtNbrRtrId	ospfVirtNbrArea ospfVirtNbrRtrId
1.3.6.1.2.1.14.11.1.5	ospfVirtNbrState	ospfVirtNbrArea ospfVirtNbrRtrId

Impact on the System

This trap message gets generated when the status of the neighbor on the virtual link changes.

If the status of the neighbor on the virtual link changes from Full to lower than Full, routes are incorrectly installed to the routing table, or some routes are wrongly deleted.

This may affect services.

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 .
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 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 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 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 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 4.
- 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 3.
3. 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 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 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 4.
- If the OSPF neighbor is in the Down state, go to 4.
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 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 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 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 2.
- If it is a Huawei device, go to 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 4.
4. Collect alarm information and configuration information, and then contact technical support personnel.