BGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed
Description
BGP/2/ROUTETHRESHOLDEXCEED:OID [oid] The number of routes received from the BGP peer exceeded the alarm threshold. (InstanceId=[gauge], Afi=[integer], Safi=[integer], PeerType=[integer], PeerRemoteAddr=[binary], MaxRouteNum=[gauge], AlarmThreshold=[gauge])
The number of routes received from the peer configured with the route limit exceeded the alarm threshold (MaxRouteNum x AlarmThreshold).
Attribute
| Alarm ID | Alarm Severity | Alarm Type |
|---|---|---|
| 1.3.6.1.4.1.2011.5.25.177.1.3.1 | Major | qualityOfServiceAlarm(3) |
Parameters
| Name | Meaning |
|---|---|
oid |
Indicates the MIB object ID of the alarm. |
InstanceId |
Indicates the index of the instance to which the peer belongs. |
Afi |
Indicates the address family:
|
Safi |
Indicates the sub-address family:
|
PeerType |
Indicates the address type of the peer:
|
PeerRemoteAddr |
Indicates the address of the peer. |
MaxRouteNum |
Indicates the maximum number of routes that can be received from the peer. |
AlarmThreshold |
Indicates the alarm threshold (expressed in percentage) for the route limit on the peer. |
Impact on the System
If the peer is configured with the peer route-limit command in which the alarm threshold is set to 100% and the keyword alert-only is not specified, the peer session will be interrupted, and all the received routes will be deleted.
If the peer is configured with other parameters, no services will be affected.
Possible Causes
The number of routes received from the peer configured with the route limit exceeded the alarm threshold.
Procedure
- Run the display bgp peer ipv4-address verbose command to view the Received
total routes field and check whether the number of routes currently
received from the peer exceeds the upper limit, which equals the maximum
number of allowed routes multiplied by the alarm threshold (expressed
in percentage).
If so, go to Step 2.
If not, go to Step 10.
- Check whether excessive routes are required to meet the
requirements of actual applications.
If so, go to Step 8.
If not, go to Step 3.
- View the user log to check whether the local inbound policy
is changed. For example, configuring the peer route-policy, peer ip-prefix, or peer filter-policy command causes excessive and unnecessary routes to be
received.
If so, go to Step 4.
If not, go to Step 5.
- Update the local inbound policy. For example, configure the peer route-policy, peer ip-prefix, or peer filter-policy command to deny unnecessary routes. Then, go to Step 9.
- Contact the maintenance personnel of the remote device
to check whether the routes advertised to the local device are necessary
routes.
If so, go to Step 6.
If not, go to Step 7.
- Advise the maintenance personnel of the remote device to summarize routes so that the number of routes to be advertised can be reduced. Then, go to Step 9.
- Advise the maintenance personnel of the remote device to change the policy for importing or advertising routes so that the unnecessary routes can be withdrawn. Then, go to Step 9.
- Increase the maximum number of routes that can be received from the peer. Then, go to Step 9.
- Check whether the trap BGP_1.3.6.1.4.1.2011.5.25.177.1.3.2 hwBgpPeerRouteNumThresholdClear appears.
If so, go to Step 11.
If not, go to Step 10.
- Collect alarm information and configuration information, and then contact technical support personnel.
- End.
Previous
