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

E9000 Server V100R001 HMM Alarm Handling 19

This document describes E9000 server alarms in terms of the meaning, impact on the system, possible causes, and solutions.
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

OSPF

OSPF_1.3.6.1.2.1.14.16.2.1 ospfVirtIfStateChange

Description

OSPF/3/VIFCHG:OID [oid]: The status of the virtual interface changes. (VirtIfAreaId=[area-id], VirtIfNeighbor=[neighbor-router-id], ProcessId=[process-id], RouterId=[router-id], VirtIfState=[neighbor-state], InstanceName=[instance-name])

The interface status of the OSPF virtual link changed. The possible cause was that the router ID of the neighbor changed after the virtual link was configured or the status of the physical interface of the virtual link changed.

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.1

Trap severity

Minor

Parameters

Parameter

Description

oid

Indicates the ID of the MIB object.

VirtIfAreaId

Indicates the area ID.

VirtIfNeighbor

Indicates the router ID of the neighbor on the virtual link.

ProcessId

Indicates the process ID.

RouterId

Indicates the router ID of the local switch modules.

VirtIfState

Indicates the status of the neighboring interface.

  • 1: Down
  • 2: Loopback
  • 3: Waiting
  • 4: Point-to-Point
  • 5: DR
  • 6: Backup
  • 7: DROther

InstanceName

Indicates the instance name.

Impact on the System

If the interface status of the virtual link changes from Down to P2P (Point-to-Point), this trap message is informational only, and no action is required. If the interface status of the virtual link changes from P2P to Down, the virtual link will be disconnected, the OSPF route calculation will be incorrect, and services may be interrupted.

Possible Causes

1. The status of the physical interface of the virtual link changed.

2. Router ID of the neighbor on the virtual link changed.

Procedure
  1. Run the display ospf vlink command to check whether the interface status of the virtual link is P2P.
  • If so, it indicates that this trap message is informational only, and no action is required. Go to Step 4.
  • If not, go to Step 2.
  1. Run the display ospf process-id routing router-id neighbor-router-id command to check whether the area has the route to the remote switch modules.

    • If so, collect the configuration of the remote switch modules, and go to Step 3.
    • If not, run the display ospf interface command to check whether the status of the local interface is Down.
      • If so, run the display ip interface command to check whether the local interface goes Down.
    • If so, collect interface information, and go to Step 3.
    • If not, collect log information, and go to Step 3
      • If not, collect the configuration of the remote switch modules, and go to Step 3.

  2. Contact Huawei technical personnel.
  3. End.

OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange

Description

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

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.

    Attributes

    Description

    Trap OID

    1.3.6.1.2.1.14.16.2.2

    Trap severity

    Major

    Match trap

    The clear-alarm trap is in the format of OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange. 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

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 or the neighbor is deleted.
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 7: 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 Huawei 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 Huawei 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 Huawei 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 Huawei 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 Huawei 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 Huawei technical support engineers.

OSPF_1.3.6.1.2.1.14.16.2.3 ospfVirtNbrStateChange

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 OSPF virtual link changed.

Attributes

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.3

Trap severity

Minor

Match trap

The clear-alarm trap is in the format of OSPF_1.3.6.1.2.1.14.16.2.3 ospfVirtNbrStateChange. 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

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 modules.

VirtNbrState

Indicates the status of the neighbor.

  • 1: Down
  • 2: Attempt
  • 3: Init
  • 4: 2–Way
  • 5: ExStart
  • 6: Exchange
  • 7: Loading
  • 8: Full

InstanceName

Indicates the instance name.

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: 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 router did not work properly.

Cause 7: 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 b.
    2. Collect the alarm information, log information, and configuration information, and then contact Huawei technical support personnel.
  • Cause 2: The physical interface changed.
    1. Run the display ip 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 b.
    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 c.
    3. Collect the alarm information, log information, and configuration information, and then contact Huawei technical support personnel.
  • 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 b.
      • 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 c.
      • 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 d.
      • 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 c.
      • 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 d.
      • If the authentication modes configured for both ends are different, change them to be the same.
    4. Collect the alarm information, log information, and configuration information, and then contact Huawei technical support personnel.
  • 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 c.
    2. Run the display ospf peer command to check whether the OSPF neighbor is in the Up state.
      • If the OSPF neighbor is in the Down state, go to c.
      • If the OSPF neighbor is in the Up state, go to step 1.
    3. Collect the alarm information, log information, and configuration information, and then contact Huawei technical support personnel.
  • 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 b.
    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 c.
    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 d.
    4. Collect the alarm information, log information, and configuration information, and then contact Huawei technical support personnel.
  • Cause 6: The peer router did not work properly.
    1. Check whether the peer router is a non-Huawei device.
      • If it is a non-Huawei device, go to b.
      • If it is a Huawei device, go to c.
    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 d.
    4. Collect the alarm information, log information, and configuration information, and then contact Huawei technical support personnel.

OSPF_1.3.6.1.2.1.14.16.2.4 ospfIfConfigError

Description

A packet is received on the non-virtual interface from a device whose configuration conflicts with the local configuration. (RouterId=[RouterId], IfIpAddress=[IfIpAddress], AddressLessIf=[AddressLessIf], PacketSrc=[PacketSrc], ConfigErrorType=[ConfigErrorType], PacketType=[PacketType])

The configurations of the interfaces used to establish an OSPF neighbor are inconsistent. Possible causes are that the Hello, Dead, or Poll timer configurations on both ends were inconsistent or the interface configurations on both ends were not performed in the same area.

Attributes

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.4

Trap severity

Warning

Parameters

Parameter

Description

RouterId

Indicates the router ID.

IfIpAddress

Indicates the interface IP address.

AddressLessIf

Indicates the interface index.

PacketSrc

Indicates the source IP address of the packet.

ConfigErrorType

Indicates the error type.

PacketType

Indicates the packet type.

Impact on the System

Interface parameter settings are inconsistent. The alarm can be rectified by adjusting the parameter settings. This alarm does not affect services.

Possible Causes

Cause 1: Interface configurations on both ends of the link were inconsistent.

Cause 2: The link protocol changed.

Procedure
  1. Use the display ospf interface interface-type interface-number command to check whether the interface configurations on both ends of the link are consistent.
  • If they are consistent, go to Step 3.
  • If they are inconsistent, go to Step 2.
  1. Perform the following operations based on the networking condition:

    • If the configurations on both ends can be changed to be consistent, set the same Hello timer value, Dead timer value, and Poll timer value on both ends. Then check whether the alarm is cleared.
      • If the alarm is cleared, go to Step 4.
      • If the alarm persists, go to Step 3.
    • If the configurations on both ends of the link cannot be changed to be consistent, go to Step 3.

  2. Collect trap, log, and configuration information, and contact Huawei technical support personnel.
  3. End.

OSPF_1.3.6.1.2.1.14.16.2.5 ospfVirtIfConfigError

Description

OSPF/3/VIFCFGERR:OID [oid]: A packet is received on the virtual interface from a router whose configuration conflicts with the local configuration. (VirtIfAreaId=[area-id], VirtIfNeighbor=[neighbor-router-id], ProcessId=[process-id], RouterId=[router-id], ConfigErrorType=[error-type], PacketType=[packet-type], InstanceName=[instance-name])

Configurations of the interfaces on the two ends of the virtual link were incorrect. The possible cause was that the configurations of the parameters conflicted.

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.5

Trap severity

Minor

Parameters

Parameter

Description

oid

Indicates the ID of the MIB object.

VirtIfAreaId

Indicates the area ID.

VirtIfNeighbor

Indicates the router ID of the neighbor on the virtual link.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the local switch modules.

ConfigErrorType

Indicates the error type.

  • 1: Bad Version
  • 2: Area Mismatch
  • 3: Unknown Nbma Neighbour
  • 4: Unknown Virtual Neighbour
  • 7: NetMask Mismatch
  • 8: Hello Interval Mismatch
  • 9: Dead Interval Mismatch
  • 10: Option Mismatch
  • 11: Mtu Mismatch
  • 12: Duplicate RouterId

PacketType

Indicates the type of the packet.

  • 1: Hello packet
  • 2: DD packet
  • 3: Request packet
  • 4: Update packet
  • 5: Acknowledgement packet
  • 6: Update packet Retrans
  • 7: Update packet flood

InstanceName

Indicates the instance name.

Impact on the System

This trap message is generated after the virtual interface receives a packet indicating parameters are incorrectly configured.

Possible Causes

The configurations of the interfaces on the two ends of the virtual link conflicted.

Procedure
  1. Run the display ospf vlink and display current- configuration configuration commands to check whether the configurations of the two interfaces are consistent.
  • If so, go to Step 3.
  • If not, go to Step 2.
  1. Perform the following operations according to the networking:

    • If it is allowed to modify the configurations on the two interfaces to be consistent, run the following command to modify the configurations on the two interfaces 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 tap is cleared.

      • If so, go to Step 4.
      • If not, go to Step 3.
    • If it is not allowed to modify the configurations on the two interfaces to be consistent, go to Step 3.

  2. Collect the trap information, log information, and configuration of the switch modules, and contact Huawei technical personnel.
  3. End.

OSPF_1.3.6.1.2.1.14.16.2.6 ospfIfAuthFailure

Description

A packet is received on a non-virtual interface from a device whose authentication key or authentication type conflicts with the local authentication key or authentication type. (RouterId=[RouterId], IfIpAddress=[IfIpAddress], AddressLessIf=[AddressLessIf], PacketSrc=[PacketSrc], ConfigErrorType=[ConfigErrorType], PacketType=[PacketType])

A packet is received on a non-virtual interface from a device whose authentication key or authentication type conflicts with the local authentication key or authentication type.

Attributes

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.6

Trap severity

Warning

Parameters

Parameter

Description

RouterId

Indicates the router ID.

IfIpAddress

Indicates the interface IP address.

AddressLessIf

Indicates the interface index.

PacketSrc

Indicates the source IP address of packets.

ConfigErrorType

Indicates the configuration error type.

PacketType

Indicates the packet type.

Impact on the System

You can modify parameters on the two devices to be consistent to solve this problem. Services are not affected in most cases.

Possible Causes

The interface authentication was incorrectly configured.

Procedure
  1. Run the display current-configuration command to check whether the area authentication modes on the two devices are consistent; run the display current-configuration interface command to check whether the interface authentication modes on the two devices are consistent. Priority of the interface authentication mode is higher than that of the area authentication mode.
  • If they are consistent, go to Step 3.
  • If they are inconsistent, go to Step 2.
  1. Perform the following operations according to networking status:

    • If the networking status allows consistent configurations on both ends, go to Step 3.
    • If the networking status does not allow consistent configurations on both ends, go to Step 4.

  2. Set the same authentication password on both ends if the plaintext authentication mode is set. Reconfigure authentication modes. Then check whether the alarm is cleared.

    • If the alarm is cleared, go to Step 5.
    • If the alarm persists, go to Step 4.

  3. Collect trap, log, and configuration information, and contact Huawei technical support personnel.
  4. End.

OSPF_1.3.6.1.2.1.14.16.2.7 ospfVirtIfAuthFailure

Description

OSPF/3/VIFAUTFAIL:OID [oid]: A packet is received on a virtual interface from a router whose authentication key or authentication type conflicts with the local authentication key or authentication type. (VirtIfAreaId=[area-id], VirtIfNeighbor=[neighbor-router-id], ProcessId=[process-id], RouterId=[router-id], ConfigErrorType=[error-type], PacketType=[packet-type], InstanceName=[instance-name])

The virtual-link interface authentication failed. The possible cause was that the configuration of the virtual-link interface authentication was incorrect.

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.7

Trap severity

Minor

Parameters

Parameter

Description

oid

Indicates the ID of the MIB object.

VirtIfAreaId

Indicates the area ID.

VirtIfNeighbor

Indicates the router ID of the neighbor on the virtual link.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the local switch modules.

ConfigErrorType

Indicates the error type.

  • 5: Auth type Mismatch
  • 6: Auth Failure

PacketType

Indicates the type of the packet.

  • 1: Hello packet
  • 2: DD packet
  • 3: Request packet
  • 4: Update packet
  • 5: Acknowledgement packet
  • 6: Update packet Retrans
  • 7: Update packet flood

InstanceName

Indicates the instance name.

Impact on the System

This trap message is generated after the virtual link interface receives a packet indicating authentication parameters are incorrectly configured.

Possible Causes

The configuration of authentication of the virtual link interface was incorrect.

Procedure
  1. Run the display current-configuration configuration ospf command to check whether the interface authentication configurations on the two ends of the virtual link are consistent.
  • If so, go to Step 3.
  • If not, go to Step 2.
  1. Perform the following operations according to the networking:

    • If it is allowed to modify the configurations on the two ends to be consistent, go to Step 3.
    • If it is not allowed to modify the configurations on the two interfaces to be consistent, go to Step 4.

  2. If the authentication is in plain text, modify the authentication password. If the authentication is in cipher text, run the following command to reconfigure the authentication on the two interfaces as required.

    • 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 ] ] *

    Check whether the trap is cleared.

    • If so, go to Step 5.
    • If not, go to Step 4.

  3. Collect the trap information, log information, and configuration of the switch modules, and contact Huawei technical personnel.
  4. End.

OSPF_1.3.6.1.2.1.14.16.2.8 ospfIfRxBadPacket

Description

An OSPF packet that is received on a non-virtual interface cannot be parsed. (RouterId=[RouterId], IfIpAddress=[IfIpAddress], AddressLessIf=[AddressLessIf], PacketSrc=[PacketSrc], PacketType=[PacketType])

An OSPF packet that could not be parsed was received from a non-virtual interface because the Huawei device was attacked or failed to communicate with non-Huawei devices.

Attributes

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.8

Trap severity

Minor

Parameters

Parameter

Description

RouterId

Indicates the router ID.

IfIpAddress

Indicates the interface IP address.

AddressLessIf

Indicates the interface index.

PacketSrc

Indicates the source IP address of packets.

PacketType

Indicates the packet type.

Impact on the System

This trap message is generated when a common interface receives an incorrect packet and discards this packet, which may change the state of neighbor relationship to Down.

Possible Causes

An incorrect packet was generated on the peer non-virtual interface.

Procedure
  1. Run the display ospf error packet command in the diagnosis view to check the incorrect packet. This trap message indicates that the packet cannot be parsed. Save information about the incorrect packet.
  2. Collect trap, log, and configuration information, and contact Huawei technical support personnel.
  3. End.

OSPF_1.3.6.1.2.1.14.16.2.9 ospfVirtIfRxBadPacket

Description

OSPF/4/VIFBADRX:OID [oid]: An OSPF packet that is received on a virtual interface cannot be parsed. (VirtIfAreaId=[area-id], VirtIfNeighbor=[neighbor-router-id], ProcessId=[process-id], RouterId=[router-id], PacketType=[packet-type], InstanceName=[instance-name])

An OSPF packet that cannot be parsed was received from a virtual-link interface. The possible cause was that the device was attacked or the interconnection between the Huawei device and non-Huawei device failed.

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.9

Trap severity

Warning

Parameters

Parameter

Description

oid

Indicates the ID of the MIB object.

VirtIfAreaId

Indicates the area ID.

VirtIfNeighbor

Indicates the router ID of the neighbor on the virtual link.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the local switch modules.

PacketType

Indicates the type of a packet.

  • 1: Hello packet
  • 2: DD packet
  • 3: Request packet
  • 4: Update packet
  • 5: Acknowledgement packet
  • 6: Update packet Retrans
  • 7: Update packet flood

InstanceName

Indicates the instance name.

Impact on the System

This trap message is generated when a virtual-link interface receives a packet that cannot be parsed and then discards this packet. This may cause the neighbor to be Down.

Possible Causes

An incorrect packet was generated by the virtual-link interface on the peer end.

Procedure
  1. Run the display ospf error packet command in the diagnosis view to check the contents of the error packet. This trap message indicates that a packet that cannot be parsed is received, and the information about the error packet is saved.
  2. Collect the trap information, log information, and configuration of the switch modules, and contact Huawei technical personnel.
  3. End.

OSPF_1.3.6.1.2.1.14.16.2.10 ospfTxRetransmit

Description

An OSPF packet is retransmitted on a non-virtual interface. (RouterId=[RouterId], IfIpAddress=[IfIpAddress], AddressLessIf=[AddressLessIf], NbrIfIpAddress=[NbrIfIpAddress], NbrAddressLessIf=[NbrAddressLessIf], IfNeighbor=[IfNeighbor], PacketType=[PacketType], LsdbAreaId=[LsdbAreaId], LsdbType=[LsdbType], LsdbLsid=[LsdbLsid], LsdbRouterId=[LsdbRouterId])

An OSPF packet was retransmitted on a non-virtual interface because the physical link became faulty.

Attributes

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.10

Trap severity

Warning

Parameters

Parameter

Description

RouterId

Indicates the router ID.

IfIpAddress

Indicates the interface IP address.

AddressLessIf

Indicates the interface index.

NbrIfIpAddress

Indicates the IP address of the neighbor.

NbrAddressLessIf

Indicates the index of the neighbor IP address.

IfNeighbor

Indicates the interface neighbor.

PacketType

Indicates the packet type.

LsdbAreaId

Indicates the ID of the LSDB area.

LsdbType

Indicates the LSDB type.

LsdbLsid

Indicates the LS ID of the LSDB.

LsdbRouterId

Indicates the ID of the LSDB device.

Impact on the System

When a packet is retransmitted on a non-virtual interface because the network is busy, this trap message will be generated, which leads to longer route synchronization and convergence.

Possible Causes

Cause 1: The IP address to which the packet will be forwarded could not be pinged.

Cause 2: The peer device determined that the packet was invalid.

Procedure
  1. Run the display ospf retrans-queue command to check the number of the retransmitted packets.
  • If only one or two packets are transmitted, go to step 5.
  • If a large number of packets are continuously retransmitted, go to step 2.
  1. Check the IP address of the neighbor where a packet is retransmitted, and run the ping command to check whether the link functions properly.

    • If the ping operation succeeds, go to step 3.
    • If the ping operation fails, go to step 4.

  2. Check whether the OSPF_1.3.6.1.2.1.14.16.2.8 ospfIfRxBadPacket alarm is generated on the local and peer devices. If the alarm is generated, locate the fault according to the trap message. If no such alarm is generated, go to step 4.
  3. Collect trap, log, and configuration information, and contact Huawei technical support personnel.
  4. End.

OSPF_1.3.6.1.2.1.14.16.2.11 ospfVirtIfTxRetransmit

Description

OSPF/3/VIFRETX:OID [oid]: An OSPF packet is retransmitted on a virtual interface. (VirtIfAreaId=[area-id], VirtIfNeighbor=[neighbor-router-id], LsdbAreaId=[lsdb-area-id], LsdbType=[lsa-type], LsdbLsid=[lsdb-ls-id], LsdbRouterId=[lsdb-router-id], ProcessId=[process-id], RouterId=[router-id], PacketType=[packet-type], InstanceName=[instance-name])

OSPF packets were retransmitted on virtual-link interfaces. The possible cause was that the physical link was unreachable or the information about entries in the routing table was incorrect.

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.11

Trap severity

Minor

Parameters

Parameter

Description

oid

Indicates the ID of the MIB object.

VirtIfAreaId

Indicates the area ID.

VirtIfNeighbor

Indicates the router ID of a neighboring switch modules.

LsdbAreaId

Indicates the area ID of an LSDB.

LsdbType

Indicates the type of the LSA.

  • 1: Router LSA
  • 2: Network LSA
  • 3: Summary LSA type 3
  • 4: Summary LSA type 4
  • 5: AS External LSA
  • 7: NSSA LSA
  • 9: Opaque LSA - scope Local
  • 10: Opaque LSA - scope area
  • 11: Opaque LSA - scope AS

LsdbLsid

Indicates the LS ID of an LSDB.

LsdbRouterId

Indicates the router ID of an LSDB.

ProcessId

Indicates the process ID.

RouterId

Indicates the router ID of the local switch modules.

PacketType

Indicates the type of a packet.

  • 1: Hello packet
  • 2: DD packet
  • 3: Request packet
  • 4: Update packet
  • 5: Acknowledgement packet
  • 6: Update packet Retrans
  • 7: Update packet flood

InstanceName

Indicates the instance name.

Impact on the System

This trap message is generated when an OSPF packet is retransmitted on a virtual link interface. The cause may be that the network is busy, and thus LSDB update and route calculation convergence are slow.

Possible Causes

1. The address used to forward the packets could not be pinged through.

2. The peer regarded the packet as an invalid packet.

Procedure
  1. Check the retransmission times of each packet.
  • If packets are retransmitted for 1 or 2 times and the number of such packets is small, the trap is informational only and no action is required. Go to Step 5.
  • If lots of packets are retransmitted constantly and the number of retransmission times is large, go to Step 2.
  1. Run the display ospf vlink command to check the peer switch modules of the vlink. Then log in to this switch modules and run the display ospf vlink command again to check the vlink interface status or neighbor status.

    • If the vlink interface status or neighbor status is Down, see the procedures in traps OSPF_1.3.6.1.2.1.14.16.2.1 ospfVirtIfStateChange and OSPF_1.3.6.1.2.1.14.16.2.3 ospfVirtNbrStateChange.
    • If the vlink neighbor status is Full, find the IP address displayed in the interface field in the output and ping this address from the switch modules that generates the alarm.
      • If the ping fails, go to Step 4.
      • If the ping succeeds, go to Step 3.

  2. Check whether the local switch modules and the neighbor have trap OSPF_1.3.6.1.2.1.14.16.2.9 ospfVirtIfRxBadPacket and locate the fault according to the trap. Otherwise, go to Step 4.
  3. Collect the trap information, log information, and configuration of the switch modules, and contact Huawei technical personnel.
  4. End.

OSPF_1.3.6.1.2.1.14.16.2.12 ospfOriginateLsa

Description

An LSA is generated. (RouterId=[RouterId], LsdbAreaId=[LsdbAreaId], LsdbType=[LsdbType], LsdbLsid=[LsdbLsid], LsdbRouterId=[LsdbRouterId])

An LSA is generated. The possible cause is that the interface status alternated between Up and Down, the OSPF neighbor status changed, or the role of a device changed (for example, a route was imported).

Attributes

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.12

Trap severity

Cleared

Parameters

Parameter

Description

RouterId

Indicates the router ID.

LsdbAreaId

Indicates the ID of the LSDB area.

LsdbType

Indicates the type of the LSDB connection status.

LsdbLsid

Indicates the LSDB connection status.

LsdbRouterId

Indicates the ID of the LSDB device.

Impact on the System

If both OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange and OSPF_1.3.6.1.2.1.14.16.2.16 ospfIfStateChange alarms are generated, services may be affected.

Possible Causes

Cause 1: The interface status alternated between Up and Down.

Cause 2: The OSPF neighbor relationship status changed.

Cause 3: The route that the OSPF imported changed.

Procedure
  1. 1. Check whether both OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange and OSPF_1.3.6.1.2.1.14.16.2.16 ospfIfStateChange alarms are generated.
  • If yes, locate the fault according to the trap message.
  • If not, go to Step 2.
  1. Run the display ip routing-table command and check whether information about the routing table changes.

    • If information about the routing table does not change, go to Step 3.
    • If information about the routing table changes, check the reason and go to Step 3.

  2. Collect trap, log, and configuration information, and contact Huawei technical support personnel.
  3. End.

OSPF_1.3.6.1.2.1.14.16.2.13 ospfMaxAgeLsa

Description

An LSA is aged. (RouterId=[RouterId], LsdbAreaId=[LsdbAreaId], LsdbType=[LsdbType], LsdbLsid=[LsdbLsid], LsdbRouterId=[LsdbRouterId])

An LSA in the LSDB device reached its maximum aging time. The possible cause is that routes imported by the OSPF were deleted or the OSPF interface went Down.

Attributes

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.13

Trap severity

Cleared

Parameters

Parameter

Description

RouterId

Indicates the router ID.

LsdbAreaId

Indicates the ID of the LSDB area.

LsdbType

Indicates the type of the LSDB connection status.

LsdbLsid

Indicates the LSDB connection status.

LsdbRouterId

Indicates the ID of the LSDB device.

Impact on the System

The route forwarding may be affected. If the network segment where the LSA resides belongs to a service route network segment, the services will be affected.

Possible Causes

Cause 1: The interface status changed.

Cause 2: The neighbor status changed.

Cause 3: Routes imported by the OSPF changed.

Procedure
  1. Check the LsdbRouterId of the LSA in the trap message.
  • If the trap message is generated on the local device, go to step 2.
  • If the trap message is not generated on the local device, go to step 4.
  1. Check whether both OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange and OSPF_1.3.6.1.2.1.14.16.2.16 ospfIfStateChange alarms are generated.

    • If yes, locate the fault according to the trap message.
    • If no, go to step 3.

  2. Contact Huawei technical support engineers.
  3. End.

OSPF_1.3.6.1.2.1.14.16.2.16 ospfIfStateChange

Description

The status of the non-virtual interface changes. (RouterId=[RouterId], IfIpAddress=[IfIpAddress], AddressLessIf=[AddressLessIf], IfState=[IfState], ProcessId=[ProcessId], AreaId=[AreaId], IfnetIndex=[IfnetIndex], LocalIfIpAddress=[LocalIfIpAddress], IfName=[IfName])

The status of the non-virtual OSPF interface changed. The possible cause is that the physical interface went Down.

Attributes

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.16

Trap severity

Cleared

Parameters

Parameter

Description

RouterId

Indicates the router ID.

IfIpAddress

Indicates the interface IP address.

AddressLessIf

Indicates the interface index.

IfState

Indicates the interface status.

ProcessId

Indicates the process ID.

AreaId

Indicates the area ID.

IfnetIndex

Indicates the physical interface index.

LocalIfIpAddress

Indicates the local interface IP address.

IfName

Indicates the physical interface name.

Impact on the System

This trap may affect the neighbor status. If the interface goes Down, the neighbor relationship will be interrupted.

Possible Causes

Cause 1: The interface status changed.

Cause 2: An OSPF neighbor relationship was being established.

Procedure
  1. Run the display ospf interface command to check whether the interface status is Up.
  • If yes, go to step 3.
  • If no, go to step 2.
  1. Contact Huawei technical support engineers.
  2. End.

OSPF_1.3.6.1.2.1.14.16.2.17 ospfNssaTranslatorStatusChange

Description

The status of the NSSA translator changes. (RouterId=[RouterId], AreaId=[AreaId], NSSATranslatorState=[NSSATranslatorState])

The NSSA translator changed from one device to another. The possible cause is that the device status changed among Enabled, Elected, and Disabled.

Attributes

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.17

Trap severity

Warning

Parameters

Parameter

Description

RouterId

Indicates the router ID.

AreaId

Indicates the area ID.

NSSATranslatorState

Indicates the NSSA translator status.

  • 1: ENABLED
  • 2: ELECTED
  • 3: DISABLED
Impact on the System

ASE route flapping may occur because Type 5 LSA translated from Type 7 LSA is flushed due to ABR translator change or a new translator is translating Type 7 LSA to Type 5 LSA. Besides, the translator change caused not by manual operations is usually caused by topology change in the backbone or NSSA area.

Possible Causes

Cause 1: The translator-always of the nssa command was configured or deleted from an ABR in the NSSA area.

Cause 2: A new Router ID was configured on an ABR in the NSSA area and the router ID had taken effect.

Cause 3: A new entered or exited the NSSA.

Cause 4: The OSPF protocol was restarted or the active/ standby switchover was performed on a in the backbone area or the NSSA, causing topology flapping.

Cause 5: A parameter of a command was modified, causing topology change in the backbone or NSSA area. For example, if the parameter of no-summary and no-import-route of the nssa command is configured or deleted, the reestablishes a neighbor relationship with that in the backbone or NSSA area.

Cause 6: This switched between an ABR and a non-ABR.

Cause 7: Topology in the backbone or NSSA area changed. As a result, this could not route from the backbone or NSSA area to an ABR with a larger router ID or an ABR for which the translator-always option was configured.

Procedure
  1. If the nssa translator-always command in this is configured or deleted, run the display ospf brief command to check whether this should be a NSSA translator.
  • If the nssa translator-always command is configured, run the display ospf brief command to check whether the NSSA translator is in the Always state. If yes, go to step 8. If no, go to step 7.
  • If the nssa translator-always command is deleted, run the display ospf brief command to check the NSSA translator status. If the status is Disabled, go to step 2; If the status is Elected, go to step 8.
  1. The nssa translator-always command may be configured on an ABR in the NSSA area. Run the display ospf lsdb router command to check whether the Router-LSA of an ABR in the NSSA area has the Nt bit, or check whether the nssa translator-always is configured on another ABR.

    • If the Router-LSA of an ABR has the Nt.bit or the nssa translator-always command is configured on another ABR, go to step 8.
    • If the Router-LSA of an ABR does not have the Nt.bit or the nssa translator-always command is not configured on any ABR, go to step 3.

  2. If a new router ID is configured for this and has taken effect, check whether the NSSA translator state of the is correct after the topology in the area becomes stable.

    • If yes, go to step 8.
    • If no, go to step 4.

  3. Another ABR in the NSSA area may be configured with a new router ID. Check the configuration on other ABRs.

    • Check whether the Router ID of an ABR changed, and check whether a new router ID is greater than that of a local device after the topology in the area becomes stable.
      • If yes, go to step 8.
      • If no, go to step 5.
    • If all ABRs are correctly configured, go to step 5.

  4. If a new enters the NSSA area:

    • If the new is an ABR, check whether the router ID of the ABR is greater than that of the local device.
      • If yes, go to step 8.
      • If no, go to step 6.
    • If the new is not an ABR, go to step 6.

  5. Check whether the following trap message is generated for this or the neighbor :

    OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange

    OSPF_1.3.6.1.2.1.14.16.2.16 ospfIfStateChange

    • If the trap message exists, rectify the fault according to the related procedure.
    • If the trap message does not exist, go to step 7.

  6. Collect the trap, log, and configuration information. Then contact Huawei technical support engineers.
  7. End.

OSPF_1.3.6.1.2.1.14.16.2.19 ospfNbrRestartHelperStatusChange

Description

The neighbor exits from the restart helper state. (RouterId=[RouterId], NbrIpAddr=[NbrIpAddr], NbrAddressLessIndex=[NbrAddressLessIndex], NbrRtrId=[NbrRtrId], NbrRestartHelperStatus=[NbrRestartHelperStatus], NbrRestartHelperAge=[NbrRestartHelperAge], NbrRestartHelperExitReason=[NbrRestartHelperExitReason])

The GR helper status of the OSPF neighbor changed.

Attributes

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.19

Trap severity

Warning

Parameters

Parameter

Description

RouterId

Indicates the router ID.

NbrIpAddr

Indicates the IP address of the neighbor.

NbrAddressLessIndex

Indicates the index of the neighbor IP address.

NbrRtrId

Indicates the neighbor router ID.

NbrRestartHelperStatus

Indicates the new helper status.

  • 1: Normal Router, not-helping
  • 2: GR Router, not-helping
  • 3: Helper Router, helping

NbrRestartHelperAge

Indicates the remaining time for completing GR.

NbrRestartHelperExitReason

Indicates the reason of exiting the helper status.

  • 1: not attempted
  • 2: restart/helper in progress
  • 3: restart/helper completed successfully
  • 4: restart/helper exit because of timeout
  • 5: restart/helper exit because of topology changed
Impact on the System

This alarm indicates whether the neighbor device is in the Helper state. If GR fails to be enabled in the neighbor device, normal route forwarding will be affected.

Possible Causes

During GR, the GR helper status of the changed.

Procedure
  1. Perform the following operations as required:
  • If the trap is caused by a manual active/ standby switchover or OSPF process restart by GR, go to step 3.
  • If the trap is not caused by manual operations, go to step 2.
  1. Collect the trap, log, and configuration information. Then contact Huawei technical support engineers.
  2. End.

OSPF_1.3.6.1.2.1.14.16.2.20 ospfVirtNbrRestartHelperStatusChange

Description

OSPF/3/VNBRHELPERCHG:OID [oid]: The helper status of the virtual neighbor changes. (VirtNbrAreaId=[area-id], VirtNbrRtrId=[neighbor-router-id], ProcessId=[process-id], RouterId=[router-id], VirtNbrRestartHelperStatus=[gr-helper-state], VirtNbrRestartHelperAge=[gr-helper-value], VirtNbrRestartHelperExitReason=[quit-reason], InstanceName=[instance-name])

The helper status of the OSPF neighbor on the virtual link changed.

Attributes

Description

Trap OID

1.3.6.1.2.1.14.16.2.20

Trap severity

Minor

Parameters

Parameter

Description

oid

Indicates the ID of the MIB object.

VirtNbrAreaId

Indicates the ID of the area that the virtual link belongs to.

VirtNbrRtrId

Indicates the ID of a neighbor of the virtual link.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the local switch modules.

VirtNbrRestartHelperStatus

Indicates the new helper status.

  • 1: Normal Router, not-helping
  • 2: Helper Router, helping

VirtNbrRestartHelperAge

Indicates the period during which the switch modules is in the helper state.

VirtNbrRestartHelperExitReason

Indicates the reason why the switch modules leaves the helper status.

  • 1: not attempted
  • 2: restart/helper in progress
  • 3: restart/helper completed successfully
  • 4: restart/helper exit because of timeout
  • 5: restart/helper exit because of topology changed

InstanceName

Indicates the instance name.

Impact on the System

This alarm is generated when the neighbor on the virtual link leaves or enters the helper status. GR failure affects the normal forwarding of routes.

Possible Causes

During GR, the helper status of the neighbor on the virtual link changed.

Procedure
  1. Perform the following configurations as required:
  • If the active/standby switchover is performed manually or the OSPF process is restarted through GR, go to Step 3.
  • If this trap is generated without any manual operation, go to Step 2.
  1. Collect the trap information, log information, and configuration of the switch modules, and contact Huawei technical personnel.
  2. End.

OSPF_1.3.6.1.4.1.2011.5.25.155.31.3 hwOspfv2IntraAreaRouteridConflict

Description

Router IDs conflict in an intra area. (ProcessId=[ProcessId], AreaId=[AreaId], SelfIfnetIndex=[SelfIfnetIndex], NbrIpAddr=[NbrIpAddr], RouterId=[RouterId], NbrRtrId=[NbrRtrId])

A router ID conflict was detected in an OSPF area.

Attributes

Attributes

Description

Trap OID

1.3.6.1.4.1.2011.5.25.155.31.3

Trap severity

Warning

Parameters

Parameter

Description

ProcessId

Indicates the process ID.

AreaId

Indicates the area ID.

SelfIfnetIndex

Indicates the interface index.

NbrIpAddr

Indicates the IP address of a neighbor interface.

RouterId

Indicates the ID of the local device.

NbrRtrId

Indicates the neighbor router ID.

Impact on the System

If two devices are configured with the same ID, the device LSA will constantly be updated, which causes route flapping.

Possible Causes

At least two devices that were not directly connected in an area were configured with the same ID, which caused the device LSA to be constantly updated and route flapping.

Procedure
  1. Check whether the values of the RouterId and NbrRtrId are the same.
  • If yes, go to step 2.
  • If no, modify router ID to ensure that devices in the same area are not configured with the same ID.
  1. Collect trap, log, and configuration information, and contact Huawei technical support personnel.
  2. End.

OSPF_1.3.6.1.4.1.2011.5.25.155.31.4 hwOspfv2IntraAreaDRIpAddressConflict

Description

IP addresses of DRs in an intra area conflict. (ProcessId=[ProcessId], AreaId=[AreaId], SelfIfnetIndex=[SelfIfnetIndex], NbrIpAddr=[NbrIpAddr], RouterId=[RouterId], InterfaceIpAddress=[InterfaceIpAddress], InterfaceName=[InterfaceName])

A router ID conflict occurred in an OSPF area because the external routes were refreshed constantly.

Attributes

Attributes

Description

Trap OID

1.3.6.1.4.1.2011.5.25.155.31.4

Trap severity

Warning

Parameters

Parameter

Description

ProcessId

Indicates the process ID.

AreaId

Indicates the area ID.

SelfIfnetIndex

Indicates the interface index.

NbrIpAddr

Indicates the IP address of a neighbor interface.

RouterId

Indicates the ID of the local device.

InterfaceIpAddress

Indicates the interface IP address.

InterfaceName

Indicates the interface name.

Impact on the System

Two that are not directly connected in an area are configured with the same IP address and one of the devices works as a DR to advertise network LSA, which causes constant route flapping.

Possible Causes

Two that were not directly connected in an area were configured with the same IP address and one of the devices worked as a DR to advertise network LSA.

Procedure
  1. Check the IntierfaceIpAddress in the alarm. Then check whether an interface with the same IP address exists.
  • If an interface with the same IP address exists, go to Step 2.
  • If an interface with the same IP address does not exist, go to Step 3.
  1. Modify the IP address of the local interface and check whether the alarm is cleared.

    • If the alarm is cleared, go to Step 4.
    • If the alarm is not cleared, go to Step 3.

  2. Collect trap, log, and configuration information, and contact Huawei technical support personnel.
  3. End.
Translation
Download
Updated: 2018-08-16

Document ID: EDOC1000015902

Views: 195400

Downloads: 1569

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