1.Common Causes
This troubleshooting case describes how to clear the fault that traffic to be transmitted through BGP public network routes is interrupted when the BGP peer relationship is normal.
This fault is commonly caused by one of the following:
l Routes are inactive because the next hops are unreachable.
l Routes fail to be advertised or received because routing policies are incorrectly configured.
l The received routes are dropped because there is an upper limit on the number of routes on the device.
2.Troubleshooting Flowchart
BGP public network traffic is interrupted after the BGP protocol is configured.
Figure 1-1 shows the troubleshooting flowchart.
Figure 1-1 Troubleshooting flowchart for interruption of BGP public network traffic
3.Troubleshooting Procedure
Context
Saving the results of each troubleshooting step is recommended. If you are unable to correct the fault, you will have a record of your actions to provide technical support personnel.
Procedure
Step 1 Verify that the next hops for the routes are reachable.
Run the display bgp routing-table network { mask | mask-length } command on the device that sends routes (that is, the local device) to check whether the target route is active and whether it has been sent to the peer. network specifies the prefix of the target route.
Assume that the target route is a route to 13.0.0.0/8. The following command output shows that this route is valid and has been selected and sent to the peer at 3.3.3.3; the original next hop and iterated next hop of this route are 1.1.1.1 and 172.1.1.1 respectively.
<Huawei> display bgp routing-table 13.0.0.0 8
BGP local router ID : 23.1.1.2
Local AS number : 100
Paths: 1 available, 1 best, 1 select
BGP routing table entry information of 13.0.0.0/8:
From: 1.1.1.1 (121.1.1.1)
Route Duration: 4d21h29m39s
Relay IP Nexthop: 172.1.1.1
Relay IP Out-Interface: GigabitEthernet1/0/0
Original nexthop: 1.1.1.1
Qos information : 0x0
AS-path Nil, origin incomplete, localpref 100, pref-val 0, valid,
internal, best, select, active, pre 255
Aggregator: AS 100, Aggregator ID 121.1.1.1
Advertised to such 1 peers:
3.3.3.3
l If the target route is inactive, check whether there is a route to the original next hop in the IP routing table. If there is no route to the original next hop, the BGP route is not advertised because the next hop of the BGP route is unreachable. Then, find out why there is no route to the original next hop (this fault is generally associated with IGP or static routes).
l If the target route is active and has been selected but there is no information indicating that this route has been sent to the peer, go to Step 2 to check the outbound policy applied to the local device.
Run the display bgp routing-table network { mask | mask-length } command on the peer to check whether it has received the target route.
l If the peer has received the target route, perform Step 1 again to check whether the next hop of the route is reachable and whether this route has been selected.
l If the peer has not received the target route, go to Step 2 to check the inbound policy applied to the peer.
Step 2 Check that routing policies are configured correctly.
Run the display current-configuration configuration bgp command on the local device and the peer to check whether inbound and outbound policies are configured.
<Huawei> display current-configuration
configuration bgp
#
bgp 100
peer 1.1.1.1 as-number 100
#
ipv4-family unicast
undo synchronization
filter-policy ip-prefix aaa import
filter-policy ip-prefix aaa export
peer 1.1.1.1 enable
peer 1.1.1.1 filter-policy acl-name acl-name import
peer 1.1.1.1 filter-policy acl-name acl-name export
peer 1.1.1.1 as-path-filter 1 import
peer 1.1.1.1 as-path-filter 1 export
peer 1.1.1.1 ip-prefix prefix-name import
peer 1.1.1.1 ip-prefix prefix-name export
peer 1.1.1.1 route-policy policy-name import
peer 1.1.1.1 route-policy policy-name export
#
ipv4-family vpnv4
policy vpn-target
peer 1.1.1.1 enable
#
return
l If inbound and outbound policies are configured on the two devices, check whether the target route is filtered by these policies. For detailed configurations of a routing policy, see the Huawei AR100&AR120&AR150&AR160&AR200&AR1200&AR2200&AR3200&AR3600 Series Enterprise Routers Configuration Guide - IP Routing.
l If inbound and outbound policies are not configured on the two devices, go to Step 3.
Step 3 Check that the number of routes is lower than the upper limit.
Run the display current-configuration configuration bgp | include peer destination-address command or the display current-configuration configuration bgp | include peer group-name command on the peer to check whether an upper limit on the number of routes to be received is configured on the peer.
For example, if the upper limit is set to 5, subsequent routes are dropped and a log is recorded after the peer receives five routes from the local device at 1.1.1.1.
<Huawei> display current-configuration
configuration bgp | include peer 1.1.1.1
peer 1.1.1.1 as-number 100
peer 1.1.1.1 route-limit 5 alert-only
peer 1.1.1.1 enable
If the peer is added to a peer group, there may be no configurations of the upper limit in the command output.
<Huawei> display current-configuration
configuration bgp | include peer 1.1.1.1
peer 1.1.1.1 as-number 100
peer 1.1.1.1 group IBGP
peer 1.1.1.1 enable
peer 1.1.1.1 group IBGP
In this case, run the display current-configuration configuration bgp | include peer group-name command to check the configuration of this peer group.
<Huawei> display current-configuration
configuration bgp | include peer IBGP
peer IBGP route-limit 5 alert-only
peer IBGP enable
If the log BGP/3/ROUTPRIX_EXCEED is generated when traffic is interrupted, the target route is dropped because the upper limit is exceeded. In this case, increase the upper limit.
Changing the upper limit on the number of routes to be received from a peer interrupts the BGP peer relationship. Therefore, reducing the number of sent routes by configuring route summarization on the local device is recommended.
Step 4 Please contact technical support personnel and provide them with the following information.
l Results of the preceding troubleshooting procedure.
l Configuration files, log files, and alarm files of the devices.
----End
4.Relevant Alarms and Logs
Relevant Alarms
BGP_1.3.6.1.4.1.2011.5.25.177.1.3.1 hwBgpPeerRouteNumThresholdExceed
Relevant Logs
BGP/3/ROUTPRIX_EXCEED
