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: 1: ipv4 2: ipv6 25: vpls 196: l2vpn
Safi	Indicates the sub-address family: 1: unicast 2: multicast 4: mpls 5: mvpn 65: vpls 66: mdt 70: evpn 128: vpn 245: tunnel-encap-ext
PeerType	Indicates the address type of the peer: 1: ipv4 2: ipv6
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 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.

Related Information

BGP_1.3.6.1.4.1.2011.5.25.177.1.3.2 hwBgpPeerRouteNumThresholdClear