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

S9300, S9300E, and S9300X V200R013C00

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

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.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.1 Minor environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

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.

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.

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

    • If so, collect the configuration of the remote switch, 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 rm interface or 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, and go to Step 3.

  3. Collect alarm information and configuration information, and then contact technical support personnel.
  4. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange

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 Alarm Severity Alarm Type

1.3.6.1.2.1.14.16.2.2

Major

environmentalAlarm (6)

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

ProcessId

Indicates the process ID.

RouterId

Indicates the router ID of the local switch.

NbrRtrId

Indicates the router ID of the neighbor.

NbrState

Indicates the status of the neighbor.
  • 1: Down
  • 2: Attempt
  • 3: Init
  • 4: 2Way
  • 5: ExStart
  • 6: Exchange
  • 7: Loading
  • 8: Full

IfName

Indicates the name of interface.

InstanceName

Indicates the instance name.

NbrChgReason

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

Impact on the System

When the status of the neighbor (not a neighbor of a virtual link) changes, this trap message will be sent. This trap message indicates the status of the neighbor changes. If the neighbor changes from a lower status to a higher status, this trap 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. The configured parameters (such as Hello timer, dead timer, interface authentication, and network type) 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 by using the slave switchover command.

4. An error packet was received.

5. The overflow function is configured and the process entered the Overflow state.

6. The ping operation failed, which indicated that an error occurred during the transmission of the packet.

Procedure

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

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

  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.

  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 trap 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 trap is cleared.
        • If so, go to Step 8.

        • If not , go to Step 7.

  6. 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 trap is cleared.
      • Y=>8.

      • N=>7.

      NOTE:

      To ensure high security, it is recommended that the simple, md5, hmac-md5, and null authentication modes be not used.

  7. Collect alarm information and configuration information, and then contact technical support personnel.
  8. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.3 ospfVirtNbrStateChange

Description

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.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.3 Minor environmentalAlarm (6)

Parameters

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.
  • 1: Down
  • 2: Attempt
  • 3: Init
  • 4: 2Way
  • 5: ExStart
  • 6: Exchange
  • 7: Loading
  • 8: Full

InstanceName

Indicates the instance name.

Impact on the System

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.

Possible Causes

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.

Procedure

  1. Run the display ospf interface and display ip interfacebrief commands to check whether the status of the interface used to establish the virtual link is normal.

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

  2. Run the display ospf peer command to check whether the OSPF neighbor relationship is normal.

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

  3. Run the display ospf routing router-id [ router-id ] command to check whether the switch object exists. router-id indicates the IP address of the neighbor on the virtual link.

    • If the route does not exist, go to Step 4.

    • If the route exists, go to Step 5.

  4. Configure the route to the neighbor of the virtual link. Then check whether the trap is cleared.

    • If so, go to Step 7.

    • If not, go to Step 5.

  5. Run the display ospf vlink and display current- configuration configuration ospf commands to check whether the configurations (including the Hello interval, Dead interval, and poll interval) on the two ends of the virtual link are consistent.

    • If the configurations are correct, check whether trap 1.3.6.1.2.1.14.16.2.14 exists.
      • 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.

  6. Collect alarm information and configuration information, and then contact technical support personnel.
  7. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.4 ospfIfConfigError

Description

OSPF/2/IFCFGERR:OID [oid]: A packet is received on the non-virtual interface from a router whose configuration conflicts with the local configuration. (IfIpAddress=[ip-address], AddressLessIf=[interface-index], ProcessId=[process-id], RouterId=[router-id], PacketSrc=[source-ip-address], ConfigErrorType=[error-type], PacketType=[packet-type], InstanceName=[instance-name])

The configurations of the OSPF interfaces that set up the neighbor relationship were inconsistent. The possible cause was that the values of the Hello timer, dead timer, poll timer were not consistent on the two interfaces or the two interfaces were not in the same area.

Attribute

Alarm ID Alarm Severity Alarm Type

1.3.6.1.2.1.14.16.2.4

Major

environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

IfIpAddress

Indicates the IP address of non-virtual-link interface.

AddressLessIf

Indicates the index of the interface.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the local switch.

PacketSrc

Indicates the source IP address of the packet.

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 an interface receives a packet indicating parameters are incorrectly configured.

Possible Causes

1. Parameters configured on the two interfaces were inconsistent.

2. The routing protocol on the link layer changed.

Procedure

  1. Run the display ospf interface interface-type interface-number command to check whether the configurations on the two interfaces are consistent.

    • If so, go to Step 3.

    • If not, go to Step 2.

  2. 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 commands to modify the configurations on the two interfaces to be consistent.
      • ospf timer hello interval
      • ospf timer dead interval
      • ospf timer poll interval
      Then, check whether the trap 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.

  3. Collect alarm information and configuration information, and then contact technical support personnel.
  4. End.

Related Information

None

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.

Attribute

Alarm ID Alarm Severity Alarm Type

1.3.6.1.2.1.14.16.2.5

Minor

processingErrorAlarm (4)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

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.

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.

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

  3. Collect alarm information and configuration information, and then contact technical support personnel.
  4. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.6 ospfIfAuthFailure

Description

OSPF/2/IFAUTFAIL:OID [oid]: A packet is received on a non-virtual interface from a router whose authentication key or authentication type conflicts with the local authentication key or authentication type. (IfIpAddress=[ip-address], AddressLessIf=[interface-index], ProcessId=[process-id], RouterId=[router-id], PacketSrc=[source-ip-address], ConfigErrorType=[error-type], PacketType=[packet-type], InstanceName=[instance-name])

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

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.6 Major environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

IfIpAddress

Indicates the IP address of the non-virtual-link interface.

AddressLessIf

Indicates the index of the interface.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the local switch.

PacketSrc

Indicates the source IP address of the packet.

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 an interface receives a packet indicating authentication parameters are incorrectly configured.

Possible Causes

The configuration of interface authentication was incorrect.

Procedure

  1. Run the display current-configuration configuration ospf command to check whether area authentication configurations on the two switch devices are consistent, and the display current- configuration interface interface-type interface-number command to check whether the interface authentication configurations on the two ends are consistent. The interface authentication takes precedence over the area authentication.

    • If so, go to Step 3.

    • If not, go to Step 2.

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

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

    Configure the interface authentication:
    • 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
    Configure the area authentication:
    • authentication-mode simple [ plain plain-text | [ cipher ] cipher-text ]
    • authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ]
    • authentication-mode keychain keychain-name
    Check whether the trap is cleared.
    • If so, go to Step 5.

    • If not, go to Step 4.

    NOTE:

    To ensure high security, it is recommended that the simple, md5, and hmac-md5 authentication modes be not used.

  4. Collect alarm information and configuration information, and then contact technical support personnel.
  5. End.

Related Information

None

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.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.7 Minor environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

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.

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.

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

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

    NOTE:

    To ensure high security, it is recommended that the simple, md5, hmac-md5, and null authentication modes be not used.

  4. Collect alarm information and configuration information, and then contact technical support personnel.
  5. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.8 ospfIfRxBadPacket

Description

OSPF/4/IFBADRX:OID [oid]: An OSPF packet that is received on a non-virtual interface cannot be parsed. (IfIpAddress=[ip-address], AddressLessIf=[interface-index], ProcessId=[process-id], RouterId=[router-id], PacketSrc=[source-ip-address], PacketType=[packet-type], InstanceName=[instance-name])

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

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.8 Warning environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

IfIpAddress

Indicates the IP address of the non-virtual-link interface.

AddressLessIf

Indicates the index of the interface.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the local switch.

PacketSrc

Indicates the source IP address of the packet.

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 when a common interface receives an incorrect packet and then discards this packet. This may cause the neighbor to be Down.

Possible Causes

An incorrect packet was received from the non virtual-link interface on the peer end.

Procedure

  1. Collect alarm information and configuration information, and then contact technical support personnel.
  2. End.

Related Information

None

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.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.9 Warning environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

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.

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. Collect alarm information and configuration information, and then contact technical support personnel.
  2. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.10 ospfTxRetransmit

Description

OSPF/4/IFRETX:OID [oid]: An OSPF packet is retransmitted on a non-virtual interface. (IfIpAddress=[ipaddr], AddressLessIf=[integer], NbrIfIpAddress=[ipaddr], NbrAddressLessIf=[ipaddr], LsdbAreaId=[ipaddr], LsdbType=[integer], LsdbLsid=[ipaddr], LsdbRouterId=[ipaddr], ProcessId=[process-id], RouterId=[ipaddr], IfNeighbor=[ipaddr], PacketType=[integer], InstanceName=[instance-name])

OSPF packets were retransmitted on non-virtual-link interfaces. The possible cause was that the physical link was unreachable.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.10 Warning environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

IfIpAddress

Indicates the IP address of the non-virtual-link interface.

AddressLessIf

Indicates the index of the interface.

NbrIfIpAddress

Indicates the IP address of a neighboring interface.

NbrAddressLessIf

Indicates the index of the neighboring interface.

LsdbAreaId

Indicates the area ID of the LSDB.

LsdbType

Indicates the LSA type.
  • 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 the LSDB.

LsdbRouterId

Indicates the router ID of the LSDB.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the local switch.

IfNeighbor

Indicates the router ID of a neighboring switch.

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 common 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 packet could not be pinged through.

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

3. Parameters configured on the two interfaces were inconsistent.

Procedure

  1. Obtain the IP address of the neighbor that retransmits the packets from the alarm message, and ping the IP address.

    • If the ping fails, go to Step 2.

    • If the ping succeeds, go to Step 3.

  2. Check whether the local switch and the neighbor have trap 1.3.6.1.2.1.14.16.2.9 and locate the fault according to the trap. Otherwise, go to Step 3.
  3. Collect alarm information and configuration information, and then contact technical support personnel.
  4. End.

Related Information

None

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.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.11 Minor environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

VirtIfAreaId

Indicates the area ID.

VirtIfNeighbor

Indicates the router ID of a neighboring switch.

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.

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. Run the display ospf vlink command to check the peer switch of the vlink. Then log in to this switch 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 1.3.6.1.2.1.14.16.2.1 and 1.3.6.1.2.1.14.16.2.3.

    • 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 that generates the alarm.
      • If the ping fails, go to Step 3.

      • If the ping succeeds, go to Step 2.

  2. Check whether the local switch and the neighbor have trap 1.3.6.1.2.1.14.16.2.9 and locate the fault according to the trap. Otherwise, go to Step 3.
  3. Collect alarm information and configuration information, and then contact technical support personnel.
  4. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.12 ospfOriginateLsa

Description

OSPF/4/OGNLSA:OID [oid]: An LSA is generated. (LsdbAreaId=[area-id], LsdbType=[lsa-type], LsdbLsid=[lsdb-ls-id], LsdbRouterId=[lsdb-router-id], ProcessId=[process-id], RouterId=[router-id], InstanceName=[instance-name])

A switch generated new LSAs. The possible cause was that the status of the interface changed, the status of the OSPF neighbor changed, or the role of the switch changed (for example, the switch imported routes).

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.12 Warning environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

LsdbAreaId

Indicates the area ID of a new LSA.

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.

InstanceName

Indicates the instance name.

Impact on the System

If the neighbor or interface status change trap is generated and no manual operations are performed within the period, services may be affected.

Possible Causes

1. The status of the interface changed.

2. The status of the neighbor changed.

3. The routes imported by OSPF changed.

Procedure

  1. Check the LSA type:

  2. Run the display ip routing-table lsdb-ls-id command to check whether the routing table changes.

    • If the routing table does not change, go to Step 3.

    • If the routing table changes, continue to check the cause of the route change or go to Step 3.

  3. Collect alarm information and configuration information, and then contact technical support personnel.
  4. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.13 ospfMaxAgeLsa

Description

OSPF/4/AGELSA:OID [oid]: An LSA is aged. (LsdbAreaId=[area-id], LsdbType=[lsa-type], LsdbLsid=[lsdb-ls-id], LsdbRouterId=[lsdb-router-id], ProcessId=[process-id], RouterId=[router-id], InstanceName=[instance-name])

LSAs in the LSDB of the switch reached the maximum aging time. The possible cause was that the routes imported by OSPF were deleted or the OSPF interface was Down.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.13 Warning environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

LsdbAreaId

Indicates the area ID of an aged LSA.

LsdbType

Indicates the type of an 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 link state 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.

InstanceName

Indicates the instance name.

If the instance name is null, the OSPF process is a public process.

Impact on the System

In the case of Type 1 and Type 2 LSAs, services may be affected, and thus you need to check the interface or neighbor status. In the case of Type 3, Type 5, and Type 7 LSAs, only the routes associated with lsdb-ls-id will be affected.

Possible Causes

1. The interface was Up or Down.

2. The status of the neighbor changed.

3. The routes imported by OSPF changed.

Procedure

  1. Check the LsdbRouterId of the LSA in the trap.

    • If the LSA is generated by the local switch, go to Step 2.

    • If the LSA is not generated by the local switch, go to Step 4.

  2. Check the LSA type:

    • In the case of Type 1 and Type 2 LSAs, check whether the following alarms exist:

      1.3.6.1.2.1.14.16.2.1

      1.3.6.1.2.1.14.16.2.2

      1.3.6.1.2.1.14.16.2.3

      1.3.6.1.2.1.14.16.2.16
      • If so, handle the alarms according to the handling procedures of these alarms.

      • If not, go to Step 3.

    • In the case of Type 3, Type 5, and Type 7 LSAs, run the display ip routing-table lsdb-ls-id command to check whether the route exists or switch flapping occurs.
      • Collect routing or flapping information, and go to Step 3.

  3. Collect alarm information and configuration information, and then contact technical support personnel.
  4. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.14 ospfLsdbOverflow

Description

OSPF/3/OVERFLOW:OID [oid]: The LSDB overflows. (ProcessId=[process-id], RouterId=[router-id], ExtLsdbLimit=[lsa-limit], InstanceName=[instance-name])

The Overflow feature restricts only the total number of Type 5 and Type 7 LSAs. The total number of type 5 LSAs and type 7 LSAs in the LSDB of the switch reached or exceeded the maximum value defined by ospfExtLsdbLimit. The possible cause was that the number of routes imported by OSPF exceeded the set threshold. This trap was generated when the number of OSPF external routes in the network reached or exceeded the configured overflow limit.

Attribute

Alarm ID Alarm Severity Alarm Type

1.3.6.1.2.1.14.16.2.14

Minor

environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the switch that generates the trap message.

ExtLsdbLimit

Indicates the maximum number of type 5 LSAs and type 7 LSAs.

InstanceName

Indicates the instance name.

Impact on the System

The number of type 5 and type 7 LSAs exceeds the limit allowed by overflow. The excessive type 5 and type 7 LSAs are discarded.

Possible Causes

Too many type 5 and type 7 LSAs existed in the LSDB.

Procedure

  1. Run the display ospf lsdb brief command to check whether the total number of type 5 LSAs and type 7 LSAs exceeds the overflow limit.

    • If so, go to Step 2.

    • If not, go to Step 3.

  2. Perform the following operations as required:

    • If it is allowed to adjust the maximum number of external LSAs in the OSPF LSDB, run the lsdb-overflow-limit command to reconfigure the maximum value. The set maximum value should be consistent on the entire network. Wait for a period of time and check whether the trap is cleared. If the trap is cleared, go to Step 4. If not, go to Step 3.

    • If it is not allowed to adjust the maximum number of external LSAs in the OSPF LSDB, go to Step 3.

  3. Collect alarm information and configuration information, and then contact technical support personnel.
  4. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.15 ospfLsdbApproachingOverflow

Description

OSPF/3/APPROFLOW:OID [oid]: The LSDB is approaching overflow. (ProcessId=[process-id], RouterId=[router-id], ExtLsdbLimit=[lsa-limit], InstanceName=[instance-name])

The Overflow feature restricts only the total number of Type 5 and Type 7 LSAs. The total number of type 5 and type 7 LSAs in the LSDB of the router exceeded 90% of the maximum value defined by ospfExtLsdbLimit. The possible cause was that the number of routes imported by OSPF reached or exceeded the configured threshold. This trap was generated when the number of OSPF external routes in the network reached or exceeded 90% of the configured overflow limit.

Attribute

Alarm ID Alarm Severity Alarm Type

1.3.6.1.2.1.14.16.2.15

Minor

environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the switch that generates the trap message.

ExtLsdbLimit

Indicates the maximum total number of type 5 and type 7 LSAs.

InstanceName

Indicates the instance name.

Impact on the System

The total number of type 5 and type 7 LSAs exceeds the limit allowed by overflow. The excessive type 5 and type 7 LSAs are discarded.

Possible Causes

Too many type 5 and type 7 LSAs existed in the LSDB.

Procedure

  1. Run the display ospf lsdb brief command to check whether the total number of type 5 and type 7 LSAs exceeds 90% of the overflow limit.

    • If so, go to Step 2.

    • If not, go to Step 3.

  2. Perform the following operations as required:

    • If it is allowed to adjust the maximum number of external LSAs in the OSPF LSDB, run the lsdb-overflow-limit command to reconfigure the maximum value. Wait for a certain period and check whether the alarm cleared. If so, go to Step 4. If not, go to Step 3.

    • If it is not allowed to adjust the maximum number of external LSAs in the OSPF LSDB, go to Step 3.

  3. Collect alarm information and configuration information, and then contact technical support personnel.
  4. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.16 ospfIfStateChange

Description

OSPF/2/IFCHG:OID [oid]: The status of the non-virtual interface changes. (IfIpAddress=[ipaddr], AddressLessIf=[integer], ProcessId=[integer], AreaId=[ipaddr], IfnetIndex=[integer], ProcessId=[integer], RouterId=[ipaddr], IfState=[integer], IfName=[octet], InstanceName=[octet], IfChgReason=[integer])

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

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.16 Major environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

IfIpAddress

Indicates the IP address of the non-virtual-link interface.

AddressLessIf

Indicates the index of the interface.

ProcessId

Indicates the process ID.

AreaId

Indicates the area ID.

IfnetIndex

Indicates the Ifnet index of the interface.

ProcessId

Indicates the process ID.

RouterId

Indicates the router ID of the local switch.

IfState

Indicates the status of the interface.
  • 1: Down
  • 2: Loopback
  • 3: Waiting
  • 4: Point-to-Point
  • 5: DR
  • 6: Backup
  • 7: DROther

IfName

Indicates the name of interface.

InstanceName

Indicates the instance name.

IfChgReason

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

Impact on the System

If the interface status becomes Down, services may be affected. If the interface status becomes DR, BDR, DRother, or P2P, services will not be affected.

Possible Causes

1. The status of the physical interface changed.

2. DR election occurred on the broadcast network.

Procedure

  1. Run the display ospf interface command to check whether the interface is Down.

    • If the interface is Down, go to Step 2.

    • If the interface is in another state, services are not affected. Then, go to Step 4.

  2. Run the display interface interface-type interface-number command to check whether the current interface is Up.

    • If so, go to Step 3.

    • If not, view the log file to check whether the shutdown command is run on the interface.
      • If the shutdown command is run on the interface, in the case of an incorrect operation, run the undo shutdown command on the interface; otherwise, go to Step 4.

      • If the shutdown command is not run on the interface, it indicates that the link is faulty. Thus, replace the link or go to Step 3.

  3. Collect alarm information and configuration information, and then contact technical support personnel.
  4. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.17 ospfNSSATranslatorStatusChange

Description

OSPF/2/NSSATRANCHG:OID [oid]: The status of the NSSA translator changes. (AreaId=[area-id], ProcessId=[process-id], RouterId=[router-id], NSSATranslatorState=[translator-state], InstanceName=[instance-name])

The translator role in the NSSA changed. A possible cause is that the status of the translator changed among Enabled, Elected, and Disabled.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.17 Major environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

AreaId

Indicates the area ID of the NSSA.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the switch that generates the trap.

NSSATranslatorState

Indicates the new status of the translator in the NSSA.
  • 1: ENABLED
  • 2: ELECTED
  • 3: DISABLED

InstanceName

Indicates the instance name.

Impact on the System

ASE routes may flap for a short period in the following situations. The role of the NSSA ABR changes; the Type 5 LSAs translated from Type 7 LSAs need to be flushed; or a new translator is translating Type 7 LSAs to Type 5 LSAs. Moreover, the translator role changes without manual configuration mostly because the topology in the backbone area or the NSSA changes.

Possible Causes

1. The parameter translator-always in the nssa command was manually configured or canceled on an ABR in the NSSA.

2. A new router ID was configured on an ABR in the NSSA and took effect.

3. A new switch joined the NSSA or a switch exited from the NSSA.

4. The OSPF protocol was restarted or the master/slave switchover was performed on a switch in the backbone area or the NSSA. This caused topology change in the NSSA.

5. The nssa command was manually configured or parameters in the nssa command were manually modified, which caused topology flapping in the backbone area or the NSSA. For example, configuring or canceling the parameter no-summary or no-import-route in the nssa command will lead to the reestablishment of the neighbor relationship between the local switch and a switch in the backbone area and between the local switch and a switch in the NSSA.

6. The role of the local switch changed to ABR or changed from ABR.

7. The topology of the backbone area or the NSSA changed. As a result, the local switch cannot reach another ABR with a greater router ID or with the parameter translator-always from the backbone area or the NSSA.

Procedure

  1. If the nssa translator-always command is configured or canceled manually on the local switch, run the display ospf brief command to check whether the translator role of the local switch in the NSSA is correct.

    • If the nssa translator-always command is configured, run the display ospf brief command to check whether the status of the NSSA translator is always. If so, go to Step 8. If not, go to Step 7.

    • If the configuration about nssa translator-always is canceled, run the display ospf brief command to check the status of the NSSA translator. If the status is disabled, go to Step 2. If the status is elected, go to Step 8.

  2. A possible cause is that the nssa translator-always command is configured on an ABR in the NSSA. You can run the display ospf lsdb router command to check whether the Router-LSA of some ABR in the NSSA contains the Nt bit. Alternatively, you can check whether the nssa translator-always is configured on the ABRs.

    • If the Router-LSA of some ABR contains the Nt bit or an ABR has been configured with the nssa translator-always command, go to Step 8.

    • If there is no ABR whose Router-LSA contains the Nt bit or no ABR is configured with the nssa translator-always command, go to Step 3.

  3. If a new router ID is configured on the local switch and already takes effect, check whether the translator role of the local switch in the NSSA is correct after the topology in the area becomes stable.

    • If so, go to Step 8.

    • If not, go to Step 4.

  4. A possible cause is that a new router ID is configured on an ABR in the NSSA. In this case, check the configurations of the other ABRs.

    • If the router ID of an ABR is changed, check whether the newly configured router ID is greater than the local router ID after the topology in the NSSA is stable.
      • If so, go to Step 8.

      • If not, go to Step 5.

    • If the router ID of an ABR remains unchanged, go to Step 5.

  5. If a new switch joins the NSSA, do as follows as required:

    • If the new joint switch is an ABR, check whether the router ID of the ABR is greater than the local router ID after the topology in the NSSA is stable.
      • If so, go to Step 8.

      • If not, go to Step 6.

    • If the new joint switch is not an ABR, go to Step 6.

  6. Check whether the local switch and the neighboring switch have traps 1.3.6.1.2.1.14.16.2.1, 1.3.6.1.2.1.14.16.2.2, 1.3.6.1.2.1.14.16.2.3, and 1.3.6.1.2.1.14.16.2.16.

    • If the preceding traps are generated, refer to the corresponding fault location processes.
    • If the preceding traps are not generated, go to Step 7.

  7. Collect alarm information and configuration information, and then contact technical support personnel.
  8. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.18 ospfRestartStatusChange

Description

OSPF/3/RESTARTCHG:OID [oid]: The GR status changes. (ProcessId=[process-id], RouterId=[router-id], RestartStatus=[gr-reason], RestartInterval=[gr-value], RestartExitReason=[quit-reason], InstanceName=[instance-name])

The GR status of the switch changed.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.18 Minor environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the switch that generates the trap message.

RestartStatus

Indicates the reason of entering GR.
  • 1: NOT RESTARTING
  • 2: PLANNED RESTART
  • 3: UNPLANNED RESTART

RestartInterval

Indicates the GR period.

RestartExitReason

Indicates the reason why the switch exits from GR.
  • 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 trap message is generated when a switch enters the GR state or leaves the GR state. GR failure affects the normal forwarding of routes.

Possible Causes

1. The switch exited from GR.

2. The switch entered GR.

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.

  2. Collect alarm information and configuration information, and then contact technical support personnel.
  3. End.

Related Information

None

OSPF_1.3.6.1.2.1.14.16.2.19 ospfNbrRestartHelperStatusChange

Description

OSPF/3/NBRHELPERCHG:OID [oid]: The helper status of the non-virtual neighbor changes. (NbrIpAddr=[ip-address], NbrAddressLessIndex=[interface-index], ProcessId=[process-id], RouterId=[router-id], NbrRtrId=[neighbor-router-id], NbrRestartHelperStatus=[gr-helper-state], NbrRestartHelperAge=[gr-helper-value], NbrRestartHelperExitReason=[quit-reason], InstanceName=[instance-name])

The GR helper status of the OSPF neighbor changed.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.19 Minor environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

NbrIpAddr

Indicates the IP address of a non-virtual-link interface.

NbrAddressLessIndex

Indicates the index of the interface.

ProcessId

Indicates the process ID.

RouterId

Indicates the ID of the local switch.

NbrRtrId

Indicates the ID of a neighboring switch.

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 of GR.

NbrRestartHelperExitReason

Indicates the reason why the switch 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 trap message is generated when a switch enters or leaves the helper status. GR failure affects the normal forwarding of routes.

Possible Causes

During GR, the GR helper status 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.

  2. Collect alarm information and configuration information, and then contact technical support personnel.
  3. End.

Related Information

None

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.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.2.1.14.16.2.20 Minor environmentalAlarm (6)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

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.

VirtNbrRestartHelperStatus

Indicates the new helper status.
  • 1: Normal Router, not-helping
  • 2: Helper Router, helping

VirtNbrRestartHelperAge

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

VirtNbrRestartHelperExitReason

Indicates the reason why the switch 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.

  2. Collect alarm information and configuration information, and then contact technical support personnel.
  3. End.

Related Information

None

OSPF_1.3.6.1.4.1.2011.5.25.155.31.3 hwOspfv2IntraAreaRouteridConflict

Description

OSPF/2/RTRID_CONFLCT:OID [oid] Router IDs conflict in an intra area. (ProcessId=[integer], AreaId=[ipaddr], SelfIfnetIndex=[integer], NbrIpAddr=[ipaddr], RouterId=[ipaddr], NbrRtrId=[ipaddr])

Router IDs conflict in an intra-area.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.155.31.3 Major communicationsAlarm(2)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

ProcessId

Process ID

AreaId

Area ID

SelfIfnetIndex

Index of an interface

NbrIpAddr

IP address of a neighbor

RouterId

Local router ID

NbrRtrId

Router ID of a neighbor

Impact on the System

If the same router ID is configured for any two routers, it will cause the router lSA to be refreshed frequently. As a result, route flapping will occur.

Possible Causes

The same router ID was configured for at least two indirectly connected switch devices within one area, causing the router lSA to be refreshed frequently and route flapping.

Procedure

  1. Check whether the router ID in the alarm is the same as that of a neighbor.

    • If they are the same, go to Step 2.
    • If they are different, go to Step 4.

  2. Run the display current-configuration command to check whether the current configuration contains the undo ospf router-id auto-recover disable command.

    • If the current configuration contains the undo ospf router-id auto-recover disable command, go to Step 4.
    • If the current configuration does not contain the undo ospf router-id auto-recover disable command, go to Step 3.

  3. Run the undo ospf router-id auto-recover disable command to enable the automatic recovery function, and select a new router ID for a switch. Then, check whether the alarm is cleared.

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

  4. Run the ospf router-id router-id command to configure a new router ID for a switch. Run the reset ospf command to restart the OSPF process. Then, check whether the alarm is cleared.

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

  5. Collect alarm information and configuration information, and then contact technical support personnel.
  6. End.

Related Information

None.

OSPF_1.3.6.1.4.1.2011.5.25.155.31.4 hwOspfv2IntraAreaDRIpAddressConflict

Description

OSPF/2/IPADDR_CONFLCT:OID [oid] IP addresses of DRs in an intra area conflict. (ProcessId=[integer], AreaId=[ipaddr], SelfIfnetIndex=[integer], NbrIpAddr=[ipaddr], RouterId=[ipaddr], IntierfaceIpAddress=[ipaddr], InterfaceName=[octet])

IP addresses of DRs in an intra area conflict.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.155.31.4 Major communicationsAlarm(2)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

ProcessId

Process ID

AreaId

Area ID

SelfIfnetIndex

Index of an interface

NbrIpAddr

IP address of a neighbor

RouterId

Local router ID

IntierfaceIpAddress

IP address of an interface

InterfaceName

Name of an interface

Impact on the System

The same IP address is configured for two indirectly connected switch devices in the same area. Of which, one is selected as a DR to advertise network LSAs. As a result, route flapping occurs frequently.

Possible Causes

The same IP address was configured for two indirectly connected switch devices in the same area. Of which, one was selected as a DR to advertise network LSAs.

Procedure

  1. Check whether the IP address displayed in this alarm conflicts with that of any interface in the same area.

    • If a conflict exists, go to Step 2.
    • If no conflict exists, go to Step 3.

  2. Change an IP address of a local interface to check whether the alarm is cleared.

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

  3. contact technical support personnel.
  4. End.

Related Information

None.

OSPF_1.3.6.1.4.1.2011.5.25.155.31.5 hwOspfv2IntraAreaRouterIdConflictRecovered

Description

OSPF/2/RTRID_CONFLCTRECOVER: OID [oid] Router IDs confliction is recovered. (ProcessId=[integer], AreaId=[ipaddr], OldRouterId=[ipaddr], NewRouterId=[ipaddr])

The system automatically changed the router ID after detecting a router ID conflict in an OSPF area.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.155.31.5 Major communicationsAlarm(2)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

ProcessId

Process ID

AreaId

Area ID

OldRouterId

Old router ID

NewRouterId

New router ID

Impact on the System

The alarm indicates that the router ID conflict has been resolved, and the system will not be affected.

Possible Causes

Two or more indirectly connected routers shared the same router ID within one OSPF area. This router ID conflict caused frequent router LSA refreshment and route flapping. When detecting this conflict, the system automatically changed a router ID to resolve the problem.

Procedure

  • This alarm message is informational only, and no action is required.

Related Information

None

OSPF_1.3.6.1.4.1.2011.5.25.155.31.6 hwOspfv2PeerFlappingSuppressStatusChange

Description

OSPF/2/SUPPRESSFLAPPING_PEER: OID [oid] The status of peer flapping suppress is changed.(ProcessId=[integer], ProcessId=[integer], AreaId=[ipaddr], SelfIfnetIndex=[integer], AreaId=[ipaddr], ifName=[octet], SuppressStatus=[integer], SuppressReason=[integer])

The status of OSPF neighbor relationship flapping suppression changed.

Attribute

Alarm ID Alarm Severity Alarm Type
1.3.6.1.4.1.2011.5.25.155.31.6 Major communicationsAlarm(2)

Parameters

Name Meaning

oid

Indicates the MIB object ID of the alarm.

ProcessId

Process ID

AreaId

Area ID

SelfIfnetIndex

Interface index

ifName

Interface name

SuppressStatus

Suppression status

SuppressReason

Cause of the suppression

Impact on the System

The interface may set the link cost to the maximum value or delay OSPF neighbor relationship reestablishment.

Possible Causes

OSPF neighbor relationship flapping suppression started on the local interface, or the interface exited from the suppression.

Procedure

  • Check whether frequent neighbor relationship flapping occurs.

Related Information

None

Translation
Download
Updated: 2019-04-09

Document ID: EDOC1100065855

Views: 3495

Downloads: 2

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