No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade

Alarm Handling

CloudEngine 12800 and 12800E V200R005C00

This document provides the explanations, causes, and recommended actions of alarms on the product.
Rate and give feedback:
Huawei uses machine translation combined with human proofreading to translate this document to different languages in order to help you better understand the content of this document. Note: Even the most advanced machine translation cannot match the quality of professional translators. Huawei shall not bear any responsibility for translation accuracy and it is recommended that you refer to the English document (a link for which has been provided).
OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange

OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange

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 non-virtual neighbor changes:

  • An alarm was generated when the DR Other neighbor status changed from 2-way to Down in a broadcast or NBMA network, when the neighbor status changed from Full or Init to Down, or when other neighbor status changed from Full to non-Full.
  • After the OSPF neighbor state became Full again, services were restored and the alarm was cleared.
  • For a broadcast or NBMA network, after the DR Other neighbor state became 2-way again, services were restored and the alarm was cleared.
  • After the neighbor relationship was deleted, a clear alarm was not sent.

Attribute

Description

Alarm or Event

Alarm

Trap Severity

Critical

Mnemonic Code

ospfNbrStateChange

Trap OID

1.3.6.1.2.1.14.16.2.2

Alarm ID

0x08900005

Alarm Type

communicationsAlarm

Raise or Clear

None

Match trap

The fault trap and service restoration trap are in the same format except that the value of NbrState is different. The trap is a service restoration trap only when the value of NbrState is 8: Full. Otherwise, it is a fault trap.

Parameters

Parameter Description

oid

Indicates the ID of the MIB object.

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.
  • 1: Down
  • 2: Attempt
  • 3: Init
  • 4: 2Way
  • 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.

SubReason

Indicates the detailed reason.

Reason

Indicates the reason why the neighbor status changes:
  • 1 (adjacencyHoldTimerExpired): The timer of the adjacent device times out.
  • 2 (physicalInterfaceChange): The status of the physical interface on the device changes.
  • 3 (ospfProtocolReason): An alarm is generated because of the OSPF protocol.
  • 4 (bfdSessionStateChange): The BFD session is closed.
  • 5 (configureChange): The OSPF configuration changes.
  • 6 (peerRouterReason): An alarm is generated because of the neighboring device.
  • 100 (alarmCleared): The alarm is cleared because services are restored , OSPF is disabled, or the neighbor is deleted.

VB

VB OID

VB Name

VB Index

1.3.6.1.2.1.14.1.1

ospfRouterId

N/A

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.
NOTE:
The OSPF neighbor states arranged in ascending order are: down->init->2-way->exstart->exchange->loading->full.

Possible Causes

Cause 1: The adjacency HoldTimer expired.

Cause 2: The physical interface changed.

Cause 3: The protocol did not work correctly.

Cause 4: The BFD session was interrupted.

Cause 5: OSPF configurations changed.

Cause 6: The peer device did not work properly.

Cause 100: The alarm was cleared.

Procedure

  • Cause 1: The 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. Run the ping multicast -i interface-name command to ping 224.0.0.5 and 224.0.0.6, and check whether the interfaces have joined the multicast group.

      • If either of the two IP addresses fails to be pinged, check whether the interface has joined the multicast group. If no, configure the interface to join the multicast group.
      • If the ping succeeds, go to Step 3.

    3. Collect log messages and contact technical support personnel technical support engineers.
  • Cause 2: The physical interface changed.
    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 log messages and contact technical support personnel technical support engineers.
  • Cause 3: The protocol did not work correctly.
    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 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 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.
        NOTE:

        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 log messages and contact technical support personnel technical support engineers.
  • Cause 4: The BFD session was interrupted.
    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, go to Step 5.

    4. Run the ping multicast -i interface-name command to ping 224.0.0.5 and 224.0.0.6, and check whether the interfaces have joined the multicast group.

      • If the ping fails, check whether the interfaces have joined the multicast group. If no, add the interfaces to the multicast group.
      • If the ping succeeds, go to Step 5.

    5. Collect log messages and contact technical support personnel technical support engineers.
  • Cause 5: OSPF configurations changed.
    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 log messages and contact technical support personnel technical support engineers.
  • Cause 6: The peer device did not work properly.
    1. Check whether the peer device 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 device or the OSPF process has been restarted.

      • If the peer device or the OSPF process has been restarted, refer to alarm and log information to identify the cause.
      • If the peer device or the OSPF process has not been restarted, go to Step 4.

    4. Collect log messages and contact technical support personnel technical support engineers.
Translation
Download
Updated: 2019-04-20

Document ID: EDOC1100039527

Views: 91388

Downloads: 21

Average rating:
This Document Applies to these Products
Related Documents
Related Version
Share
Previous Next