OSPF
- OSPF_1.3.6.1.2.1.14.16.2.1 ospfVirtIfStateChange
- OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange
- OSPF_1.3.6.1.2.1.14.16.2.3 ospfVirtNbrStateChange
- OSPF_1.3.6.1.2.1.14.16.2.4 ospfIfConfigError
- OSPF_1.3.6.1.2.1.14.16.2.5 ospfVirtIfConfigError
- OSPF_1.3.6.1.2.1.14.16.2.6 ospfIfAuthFailure
- OSPF_1.3.6.1.2.1.14.16.2.7 ospfVirtIfAuthFailure
- OSPF_1.3.6.1.2.1.14.16.2.8 ospfIfRxBadPacket
- OSPF_1.3.6.1.2.1.14.16.2.9 ospfVirtIfRxBadPacket
- OSPF_1.3.6.1.2.1.14.16.2.10 ospfTxRetransmit
- OSPF_1.3.6.1.2.1.14.16.2.11 ospfVirtIfTxRetransmit
- OSPF_1.3.6.1.2.1.14.16.2.12 ospfOriginateLsa
- OSPF_1.3.6.1.2.1.14.16.2.13 ospfMaxAgeLsa
- OSPF_1.3.6.1.2.1.14.16.2.14 ospfLsdbOverflow
- OSPF_1.3.6.1.2.1.14.16.2.15 ospfLsdbApproachingOverflow
- OSPF_1.3.6.1.2.1.14.16.2.16 ospfIfStateChange
- OSPF_1.3.6.1.2.1.14.16.2.17 ospfNSSATranslatorStatusChange
- OSPF_1.3.6.1.2.1.14.16.2.18 ospfRestartStatusChange
- OSPF_1.3.6.1.2.1.14.16.2.19 ospfNbrRestartHelperStatusChange
- OSPF_1.3.6.1.2.1.14.16.2.20 ospfVirtNbrRestartHelperStatusChange
- OSPF_1.3.6.1.4.1.2011.5.25.155.31.3 hwOspfv2IntraAreaRouteridConflict
- OSPF_1.3.6.1.4.1.2011.5.25.155.31.4 hwOspfv2IntraAreaDRIpAddressConflict
- OSPF_1.3.6.1.4.1.2011.5.25.155.31.5 hwOspfv2IntraAreaRouterIdConflictRecovered
- OSPF_1.3.6.1.4.1.2011.5.25.155.31.6 hwOspfv2PeerFlappingSuppressStatusChange
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.
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.
|
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
- 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.
- 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.
- If so, run the display rm interface or display ip interface command to check whether the local interface goes Down.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
|
IfName |
Indicates the name of interface. |
InstanceName |
Indicates the instance name. |
NbrChgReason |
Indicates the reason why the neighbor status changes:
|
Impact on the System
When the status of the neighbor (not a neighbor of a virtual link) changes, this 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).
On a non-broadcast multi-connection or broadcast network, if the neighbor relationship enters a lower level of state, only the DR generates an ospfNbrStateChange alarm. If the neighbor relationship status change results from an interface down event on the DR, the DR does not generate this alarm but generates an ospfIfStateChange alarm. When the neighbor relationship status becomes stable, the ospfNbrStateChange alarm is cleared only on the DR. If the interface that went down is a non-DR interface, the ospfNbrStateChange alarm may persist.
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.
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
- Run the display ospf peer command to check the neighbor status. If the neighbor is in the Full state, go to Step 7; otherwise, go to Step 2.
- Run the display ip interface interface-type interface-number command to check whether the interface of the neighbor is in the Down state.
If the physical interface is Up, go to Step 3.
- If the physical interface is Down, check whether the shutdown command is configured on the interface and the link.
- If this command is configured, run the undo shutdown command and then go to Step 3.
- If this command is not configured, go to Step 8.
- Check whether the packet is correctly forwarded and ping the IP address of the remote interface.
If the ping fails, go to Step 7.
If the ping succeeds, go to Step 4.
- Run the display ospf interface interface-type interface-number command to view the state field and check whether the interface where the OSPF neighbor resides is in the Down state.
If the interface is in the Down state, go to Step 7.
If the interface is in another state, go to Step 5.
- Run the display ospf interface interface-type interface-number command to check whether the configurations (including the hello interval, dead interval, poll interval, and OSPF network-type) on the two ends of the link are consistent and whether the interface on one end is not an OSPF interface.
If so, go to Step 6.
- If not, modify the configurations to make them consistent. Then check whether the 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 }
If so, go to Step 8.
If not, go to Step 7.
- Run the display current-configuration interface interface-type interface-number command to check whether the interface authentication configurations on the two ends are consistent.
If so, go to Step 7.
- If not, run the following commands to modify interface configurations on the two ends to be consistent.
- ospf authentication-mode { simple [ plain plain-text | [ cipher ] cipher-text ] | null }
- ospf authentication-mode { md5 | hmac-md5 | hmac-sha256 } [ key-id { plain plain-text | [ cipher ] cipher-text } ]
- ospf authentication-mode keychain keychain-name
Y=>8.
N=>7.
To ensure high security, it is recommended that the simple, md5, hmac-md5, and null authentication modes be not used.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
|
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
- Run the display ospf interface and display ip interface brief 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.
- 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.
- 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.
- 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.
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
|
PacketType |
Indicates the type of the packet.
|
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
- 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.
- 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
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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- 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.
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.
|
PacketType |
Indicates the type of the packet.
|
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
- 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.
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
|
PacketType |
Indicates the type of the packet.
|
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.
Procedure
- 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.
- 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.
- 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
- 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
If so, go to Step 5.
If not, go to Step 4.
To ensure high security, it is recommended that the simple, md5, and hmac-md5 authentication modes be not used.
- Collect alarm information and configuration information, and then contact technical support personnel.
- 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.
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.
|
PacketType |
Indicates the type of the packet.
|
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.
Procedure
- 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.
- 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.
- 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.
To ensure high security, it is recommended that the simple, md5, hmac-md5, and null authentication modes be not used.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
|
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.
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.
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.
|
InstanceName |
Indicates the instance name. |
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.
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.
|
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.
|
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
- 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.
- Check whether the local switch and the neighbor have trap and locate the fault according to the trap. Otherwise, go to Step 3.
- Collect alarm information and configuration information, and then contact technical support personnel.
- 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.
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.
|
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.
|
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
- 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.
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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).
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.
|
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
- 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.16If 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, go to Step 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
|
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
- 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.
- 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.16If 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
Procedure
- 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.
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
Procedure
- 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.
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
|
IfName |
Indicates the name of interface. |
InstanceName |
Indicates the instance name. |
IfChgReason |
Indicates the reason why the neighbor status changes:
|
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
- 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.
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
|
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
- 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.
- 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.
- 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.
- 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.
- 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.
- Check whether the local switch and the neighboring switch have traps , 1.3.6.1.2.1.14.16.2.2, , 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
|
RestartInterval |
Indicates the GR period. |
RestartExitReason |
Indicates the reason why the switch exits from GR.
|
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.
Procedure
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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.
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.
|
NbrRestartHelperAge |
Indicates the remaining time of GR. |
NbrRestartHelperExitReason |
Indicates the reason why the switch leaves the helper status.
|
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.
Procedure
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- 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.
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.
|
VirtNbrRestartHelperAge |
Indicates the period during which the switch is in the helper state. |
VirtNbrRestartHelperExitReason |
Indicates the reason why the switch leaves the helper status.
|
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.
Procedure
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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
- 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.
- 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.
- 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.
- 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.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
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
- 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.
- 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.
- contact technical support personnel.
- End.
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.
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.
- OSPF_1.3.6.1.2.1.14.16.2.1 ospfVirtIfStateChange
- OSPF_1.3.6.1.2.1.14.16.2.2 ospfNbrStateChange
- OSPF_1.3.6.1.2.1.14.16.2.3 ospfVirtNbrStateChange
- OSPF_1.3.6.1.2.1.14.16.2.4 ospfIfConfigError
- OSPF_1.3.6.1.2.1.14.16.2.5 ospfVirtIfConfigError
- OSPF_1.3.6.1.2.1.14.16.2.6 ospfIfAuthFailure
- OSPF_1.3.6.1.2.1.14.16.2.7 ospfVirtIfAuthFailure
- OSPF_1.3.6.1.2.1.14.16.2.8 ospfIfRxBadPacket
- OSPF_1.3.6.1.2.1.14.16.2.9 ospfVirtIfRxBadPacket
- OSPF_1.3.6.1.2.1.14.16.2.10 ospfTxRetransmit
- OSPF_1.3.6.1.2.1.14.16.2.11 ospfVirtIfTxRetransmit
- OSPF_1.3.6.1.2.1.14.16.2.12 ospfOriginateLsa
- OSPF_1.3.6.1.2.1.14.16.2.13 ospfMaxAgeLsa
- OSPF_1.3.6.1.2.1.14.16.2.14 ospfLsdbOverflow
- OSPF_1.3.6.1.2.1.14.16.2.15 ospfLsdbApproachingOverflow
- OSPF_1.3.6.1.2.1.14.16.2.16 ospfIfStateChange
- OSPF_1.3.6.1.2.1.14.16.2.17 ospfNSSATranslatorStatusChange
- OSPF_1.3.6.1.2.1.14.16.2.18 ospfRestartStatusChange
- OSPF_1.3.6.1.2.1.14.16.2.19 ospfNbrRestartHelperStatusChange
- OSPF_1.3.6.1.2.1.14.16.2.20 ospfVirtNbrRestartHelperStatusChange
- OSPF_1.3.6.1.4.1.2011.5.25.155.31.3 hwOspfv2IntraAreaRouteridConflict
- OSPF_1.3.6.1.4.1.2011.5.25.155.31.4 hwOspfv2IntraAreaDRIpAddressConflict
- OSPF_1.3.6.1.4.1.2011.5.25.155.31.5 hwOspfv2IntraAreaRouterIdConflictRecovered
- OSPF_1.3.6.1.4.1.2011.5.25.155.31.6 hwOspfv2PeerFlappingSuppressStatusChange