ALM-1880563716 The OSPF Neighbor Is Disconnected
Description
OSPF/2/NBRCHG:OID [OID]: The status of the non-virtual neighbor changes. (NbrIpAddress=[neighbor-ip-address], NbrAddressLessIndex=[neighbor-interface-index], ProcessId=[process-id], AreaId=[area-id], IfnetIndex=[interface-ifnet-index], LocalIfIpAddress=[local-ip-address], ProcessId=[process-id], RouterId=[router-id], NbrRtrId=[neighbor-router-id], NbrState=[neighbor-state], IfName=[interface-name], InstanceName=[instance-name], NbrChgReason=[NbrStateChangeReason])
The status of the OSPF neighbor changed. The possible cause was that the status of the interface of the neighbor changed or the contents of the received Hello packets changed.
Attribute
Alarm ID |
OID |
Alarm Severity |
Alarm Type |
---|---|---|---|
1880563716 |
1.3.6.1.2.1.14.16.2.2 |
Major |
environmentalAlarm |
Parameters
Name |
Meaning |
---|---|
OID |
Indicates the MIB object ID of the alarm. |
NbrIpAddress |
Indicates the IP address of the neighbor. |
NbrAddressLessIndex |
Indicates the index of a neighboring interface. |
ProcessId |
Indicates the process ID. |
AreaId |
Indicates the area ID of the NSSA. |
IfnetIndex |
Indicates the Ifnet index of the interface. |
LocalIfIpAddress |
Indicates the IP address of the local router. |
ProcessId |
Indicates the process ID. |
RouterId |
Indicates the router ID of the local router. |
NbrRtrId |
Indicates the router ID of the neighbor. |
NbrState |
Indicates the status of the neighbor.
|
IfName |
Indicates the name of interface. |
InstanceName |
Indicates the instance name. |
NbrChgReason |
Indicates the reason why the neighbor status changes:
|
Impact on the System
When the status of the neighbor (not a neighbor of a virtual link) changes, this alarm message will be sent. This alarm message indicates the status of the neighbor changes. If the neighbor changes from a lower status to a higher status, this alarm message is informational only, and no action is required. If the neighbor changes from a higher status to a lower status, services may be interrupted. (The state transition of the OSPF neighbor in an ascending order is: Down -> Init -> 2-way -> Exstart -> Exchange -> Loading -> Full).
Possible Causes
1. The status of the interface of the neighbor changed.
2. OSPF was restarted by using the reset ospf process command or the active/standby switchover was performed by using the slave switchover command.
3. An error packet was received.
4. The link between the OSPF neighbors is disconnected.
Procedure
- Run the display ospf peer command to check the neighbor status. If the neighbor is in the Full state, go to step 7; otherwise, go to step 2.
- Run the display ip interface interface-type interface-number command to check whether the interface of the neighbor is in the Down state.
- If the physical interface is Up, go to step 3.
- If the physical interface is Down, check whether the shutdown command is configured on the interface and the link.
- If this command is configured, run the undo shutdown command and then go to step 3.
- If this command is not configured, go to step 8.
- Check whether the packet is correctly forwarded and ping the IP address of the remote interface.
- If the ping fails, go to step 7.
- If the ping succeeds, go to step 4.
- Run the display ospf interface interface-type interface-number command to view the state field and check whether the interface where the OSPF neighbor resides is in the Down state.
- If the interface is in the Down state, go to step 7.
- If the interface is in another state, go to step 5.
- Run the display ospf interface interface-type interface-number command to check whether the configurations (including the hello interval, dead interval, poll interval, and OSPF network-type) on the two ends of the link are consistent and whether the interface on one end is not an OSPF interface.
- If so, go to step 6.
- If not, modify the configurations to make them consistent. Then check whether the alarm is cleared.
- If so, go to step 6.
- If not, run the following commands to modify interface configurations on the two ends to be consistent.
- ospf timer hello interval
- ospf timer dead interval
- ospf timer poll interval
- ospf network-type { broadcast | nbma | p2mp | p2p }
Then, check whether the alarm is cleared.
- If so, go to step 8.
- If not, go to step 7.
- Run the display current-configuration interface interface-type interface-number command to check whether the interface authentication configurations on the two ends are consistent.
- If so, go to step 7.
- If not, run the following commands to modify interface configurations on the two ends to be consistent.
- ospf authentication-mode { simple [ plain plain-text | [ cipher ] cipher-text ] | null }
- ospf authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ]
- ospf authentication-mode keychain keychain-name
Then, check whether the alarm is cleared.- If so, go to step 8.
- If not, go to step 7.
To ensure high security, it is recommended that the simple, md5, hmac-md5, and null authentication modes be not used.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
Clearing
After the fault is rectified, the system clears this alarm, removing the need to manually clear it. This alarm will not be displayed on the Current Alarms page.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot