OSPF/3/NBBRCHG:OID [oid]: The status of the virtual neighbor changes. (VirtNbrArea=[area-id], VirtNbrRtrId=[neighbor-router-id], ProcessId=[process-id], RouterId=[router-id], VirtNbrState=[neighbor-state], InstanceName=[instance-name])
The status of the neighbor on the OSPF virtual link changed because the interface status of the virtual link changed.
| Name | Meaning |
|---|---|
oid |
Indicates the MIB object ID of the alarm. |
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 switch. |
VirtNbrState |
Indicates the status of the neighbor.
|
InstanceName |
Indicates the instance name. |
This trap message will be 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.
1. The status of the physical interface of the virtual link changed.
2. The configured parameters (such as Hello timer, dead timer and interface authentication) of the interfaces that set up the neighbor relationship were inconsistent.
3. OSPF was restarted by using the reset ospf process command or the active/standby switchover was performed.
4. An error packet was received.
5. The overflow function is configured and the process entered the Overflow state.
6. Routes of the area configured with the virtual link were added or deleted.
7. The ping operation failed, which indicated that an error occurred during the transmission of the packet.
If the physical interface is Down, check whether the link or interface is configured with the shutdown command.
If the protocol status of the interface is Down, check whether the interface is configured with an IP address.
If the interface status is normal, go to Step 2.
If the neighbor relationship is abnormal, check whether trap 1.3.6.1.2.1.14.16.2.2 exists. If the trap exists, locate the problem according to the trap. If the trap does not exist, go to Step 6.
If the neighbor relationship is normal, go to Step 3.
If the route does not exist, go to Step 4.
If the route exists, go to Step 5.
If so, go to Step 7.
If not, go to Step 5.
If the trap exists, rectify the fault according to the related procedure of the trap.
If the trap does not exist, go to Step 6.
If not, run the following command to modify the configurations on the two ends to be consistent.
vlink-peer router-id [ dead dead-interval | hello hello-interval | retransmit retransmit-interval | smart-discover | trans-delay trans-delay-interval | [ simple [ plain plain-text | [ cipher ] cipher-text ] | { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ] | authentication-null | keychain keychain-name ] ] *
Then, check whether the trap is cleared.
If so, go to Step 7.
If not, go to Step 6.