Overview
BGP route selection on Huawei devices follows 11 ordered rules. This article analyzes and demonstrates each rule through experiments.
Huawei BGP: The 11 Route Selection Rules
- Prefer the route with the highest preferred-value (pref val).
- Prefer the route with the highest local-preference (local_pref).
- Prefer in order: manually aggregated routes, automatically aggregated routes, routes introduced by the network command, routes introduced by import-route, and routes learned from peers.
- Prefer the route with the shortest AS_PATH.
- Prefer origin type in order: IGP, EGP, incomplete.
- For routes from the same AS, prefer the route with the lowest MED.
- Prefer in order: EBGP routes, IBGP routes, local cross routes, remote cross routes.
- Prefer the route whose BGP next-hop has the smallest IGP metric.
- Prefer the route with the shortest cluster_list.
- Prefer the route announced by the router with the smallest router ID. If originator_ID is present, compare originator_ID instead of router ID and prefer the smallest originator_ID.
- Prefer the route learned from the peer with the smallest IP address.
Experiment Topology
The topology used for examples is shown below. The topology contains four routers: R1, R2, R3, and R4. R1, R2, and R3 are in AS 123; R4 is in AS 4.
R4 advertises route 4.4.4.4 into BGP. R1 learns two BGP routes for 4.4.4.4 with next-hops via R2 and R3. According to rule 10, the route announced by the router with the smaller router ID is preferred, so R2 was preferred in the initial state.
Rule 1: preferred-value
preferred-value controls how traffic leaves the local device. preferred-value is a Huawei private BGP attribute analogous to weight. It only affects local device route selection and is not a standard RFC attribute, so it takes effect only locally and is not applied in BGP outbound policies.
Experiment objective: Use preferred-value to make R1 prefer R3 when sending traffic to R4 (control how traffic leaves the device).
Configuration and verification:
# Configure route-policy route-policy p_v permit node 10 apply preferred-value 1 ## In BGP view apply the policy; this means when receiving a route from R3, call route-policy p_v and set preferred-value to 1 bgp 123 peer 3.3.3.3 route-policy p_v import # Use the display command to view BGP routes; observe that the 4.4.4.4 route next-hop changed to R3 and PrefVal is 1, indicating the change succeeded and affected route selection. [R1-bgp]display bgp routing-table BGP Local router ID is 1.1.1.1 Status codes: * - valid, > - best, d - damped, h - history, i - internal, s - suppressed, S - Stale Origin : i - IGP, e - EGP, ? - incomplete Total Number of Routes: 2 Network NextHop MED LocPrf PrefVal Path/Ogn *>i 4.4.4.4/32 3.3.3.3 0 100 1 4i * i 2.2.2.2 0 100 0 4i
Rule 2: local-preference
local-preference indicates the local preference of a BGP route and is used to determine the best route to leave the local AS. Default value is 100; higher is preferred. local-preference is propagated only between IBGP neighbors. It can be applied on either inbound or outbound directions for IBGP neighbors, and only inbound for EBGP neighbors.
Experiment objective: Modify local-preference so that AS 123 prefers to exit to AS 4 via R3.
Configuration and verification:
# Method 1: Modify local-preference on R3 for routes learned from EBGP so that IBGP peers see the modified attribute. route-policy l_p permit node 10 apply local-preference 101 ## On R3 call the policy in BGP view bgp 123 peer 10.1.34.4 route-policy l_p import # After configuration, check R1 routing table and observe that R1 prefers R3 to reach R4, with LocPrf=101 display bgp routing-table BGP Local router ID is 1.1.1.1 ... *>i 4.4.4.4/32 3.3.3.3 0 101 0 4i ...
# R2 initial routing table shows only one route because IBGP does not re-advertise routes learned from IBGP to other IBGP peers. # Make R1 a route reflector so R2 can learn R3's advertised route: bgp 123 peer 2.2.2.2 reflect-client peer 3.3.3.3 reflect-client # After configuring route reflection, R2 sees two routes and prefers R3 for 4.4.4.4 via LocPrf=101. display bgp routing-table BGP Local router ID is 2.2.2.2 ... *>i 4.4.4.4/32 3.3.3.3 0 101 0 4i ...
# Method 2: Set local-preference on the IBGP neighbor's outbound policy on R3. bgp 123 peer 1.1.1.1 route-policy l_p export # After configuration, R1's BGP table shows LocPrf=101 for the route via R3. display bgp routing-table ... *>i 4.4.4.4/32 3.3.3.3 0 101 0 4i ...
# Method 3: Apply local-preference in the inbound policy on the IBGP neighbor on R1 for routes received from R3. route-policy l_p permit node 10 apply local-preference 101 bgp 123 peer 3.3.3.3 route-policy l_p import # After configuration, the result is the same: R1 prefers the route via R3 with LocPrf=101.
Rule 3: route source preference (aggregation, network, import)
For routes generated locally, Huawei BGP prefers, in order: manual aggregate routes, automatic aggregate routes, routes introduced by the network command, routes introduced by import-route, and routes learned from peers. In other words, if multiple local mechanisms generate the same route, the router chooses according to this order.
Experiment objective: On R3, R4 advertises 4.4.4.0/24 to R3. R3 then creates 4.4.4.0/24 via import-route, via network, and via manual aggregation. Observe which route R3 selects.
# Initially R3 has learned 4.4.4.0/24 from R4 [R3]display bgp routing-table BGP Local router ID is 3.3.3.3 ... *> 4.4.4.0/24 10.1.34.4 0 0 4? ... # R3 imports the static route into BGP ip route-static 4.4.4.0 255.255.255.0 NULL0 bgp 123 import-route static [R3-bgp]display bgp routing-table ... *> 4.4.4.0/24 0.0.0.0 0 0 ? ... 10.1.34.4 0 4? # R3 now prefers the import-route entry. # Next, advertise the prefix via network command bgp 123 network 4.4.4.0 255.255.255.0 [R3]display bgp routing-table ... *> 4.4.4.0/24 0.0.0.0 0 0 i ... 0.0.0.0 0 ? ... 10.1.34.4 0 4? # Now the network-sourced route is preferred. # Finally, create a manual aggregate bgp 123 aggregate 4.4.4.0 255.255.255.0 [R3-bgp]display bgp routing-table ... *> 4.4.4.0/24 127.0.0.1 0 0 i ... 0.0.0.0 0 i ... 10.1.34.4 0 4? # The manual aggregate (next-hop 127.0.0.1) is preferred according to the rule order.
Rule 4: Shortest AS_PATH
Prefer the route with the shortest AS_PATH. AS_PATH length indicates how many ASes a route has traversed; shorter AS_PATH is considered better. AS_PATH is a private BGP attribute used for selection and loop prevention.
Experiment objective: Modify AS_PATH length on R2 and R3 to influence R1's selection.
# View R1's BGP routing table before modification display bgp routing-table ... *>i 4.4.4.0/24 2.2.2.2 0 100 0 4? *>i 4.4.4.4/32 2.2.2.2 0 100 0 4i ... # On R2 define a policy to prepend AS-path segments route-policy as permit node 10 apply as-path 100 200 300 additive # Apply the policy when accepting EBGP routes bgp 123 peer 10.1.24.4 route-policy as import # After configuration, R1 prefers the path via R3 because AS_PATH lengths differ. display bgp routing-table ... *>i 4.4.4.0/24 3.3.3.3 0 100 0 4? *>i 4.4.4.4/32 3.3.3.3 0 100 0 4i # R2's BGP table shows the modified AS_PATH for the route it received. [R2-bgp]display bgp routing-table ... *> 4.4.4.0/24 10.1.24.4 0 100 100 200 300 4? ...
Rule 5: origin attribute (IGP > EGP > incomplete)
origin indicates how a route became a BGP route. Routes added by network are marked IGP, import-route entries are marked incomplete (displayed as '?'), and EGP is legacy. The selection order is IGP > EGP > incomplete. In practice this means routes injected by network are preferred over imported routes.
Experiment objective: Modify the origin attribute to influence R1's selection and verify I > E > ?.
# View R1's BGP routing table initially; both learned routes have origin IGP display bgp routing-table ... *>i 4.4.4.4/32 2.2.2.2 0 100 0 4i * i 3.3.3.3 0 100 0 4i # Change origin to EGP on R2 using a route-policy route-policy ogn permit node 10 apply origin egp 10 # Apply the policy when importing from the EBGP neighbor bgp 123 peer 10.1.24.4 route-policy ogn import # Check R2's BGP table; route now shows origin e [R2-bgp]display bgp routing-table ... *> 4.4.4.4/32 10.1.24.4 0 100 0 4e ... # R2 still prefers the IGP route learned from R3 over its own EGP-marked route, demonstrating I > E. # Change R3's outbound advertisement to mark origin as incomplete route-policy origin permit node 10 apply origin incomplete # Apply on R3 outbound towards R1 # Check R3's BGP table [R3-bgp]display bgp routing-table ... *> 4.4.4.4/32 10.1.34.4 0 4i * i 2.2.2.2 0 100 0 4e # On R1 the route with origin E is preferred over the route marked incomplete, confirming I > E > ?.
Rule 6: MED for routes from the same AS
For routes from the same AS, prefer the one with the lowest MED. local-preference controls how traffic leaves the AS, while MED influences how traffic returns into the AS. MED is only carried between two ASes and is not propagated beyond the immediate neighbor AS.
MED propagation rules summary:
- Routes learned from EBGP keep MED when announced to local IBGP neighbors.
- Routes learned from EBGP do not carry MED when announced to other EBGP neighbors.
- Routes learned from IBGP do not carry MED when announced to EBGP neighbors.
MED purpose: Convey the internal IGP cost of the announced route within the source AS so the neighbor AS can prefer a path back into that AS.
Experiment objective: Ensure that R4 prefers to reach R1 via R3 by setting different IGP costs so MED causes R4 to select the path via R3.
# Check R4 default selection display bgp routing-table ... *> 4.4.4.4/32 0.0.0.0 0 i * 10.10.10.10/32 10.1.24.2 0 123i * 10.1.34.3 0 123i # Configure route-policy on R2 to set IGP cost information in exported routes route-policy med permit node 10 apply cost-type internal # Example: set ISIS cost on the interface toward R4 to 50 (illustrative) # interface GigabitEthernet0/0/0 isis cost 50 # Apply the policy on R2 for export to R4 bgp 123 peer 10.1.24.4 route-policy med export # Similarly configure R3's route-policy and export to R4 route-policy med permit node 10 apply cost-type internal bgp 123 peer 10.1.34.4 route-policy med export # After configuration, R4 prefers R3 as next-hop to reach R1 due to MED differences display bgp routing-table ... *> 10.10.10.10/32 10.1.34.3 0 123i *> 10.1.24.2 50 123i # The routing table shows R4 selected R3 as the preferred next-hop to reach R1.
Rule 7: EBGP > IBGP > local cross > remote cross
Routes learned from EBGP neighbors are preferred over routes learned from IBGP neighbors.
Experiment objective: On R3 there are two paths to 4.4.4.4: one learned via EBGP from R4, and one reflected from R1 (IBGP). Observe which path is preferred.
# View R3's BGP routing table [R3-bgp]display bgp routing-table ... *> 4.4.4.4/32 10.1.34.4 0 4i * i 2.2.2.2 0 100 0 4i *> 10.10.10.10/32 1.1.1.1 0 100 0 i # Detailed inspection shows why the IBGP path is not preferred: "not preferred for peer type" indicates the EBGP path is preferred over the IBGP reflected path. [R3-bgp]display bgp routing-table 4.4.4.4 BGP local router ID : 10.1.13.3 ... From: 10.1.34.4 (10.1.24.4) ... AS-path 4, origin igp, MED 0, pref-val 0, valid, external, best, select ... From: 1.1.1.1 (10.1.12.1) ... AS-path 4, origin igp, MED 0, localpref 100, pref-val 0, valid, internal, pre 255, IGP cost 20, not preferred for peer type ...
Rule 8: BGP next-hop IGP metric
If preceding criteria do not resolve a tie, prefer the route whose BGP next-hop has the smallest IGP metric from the local router. This compares the IGP cost to reach each next-hop.
Experiment objective: Change the IGP cost so R1 prefers R3 as next-hop to reach R4.
# View R1's BGP table before modification; R2 is the preferred next-hop display bgp routing-table ... *>i 4.4.4.4/32 2.2.2.2 0 100 0 4i * i 3.3.3.3 0 100 0 4i # Change IGP cost on the interface between R1 and R2 to increase cost, e.g. set ISIS cost 20 # interface GigabitEthernet0/0/0 isis cost 20 # After increasing cost, R1 prefers R3 as next-hop [R1]display bgp routing-table ... *>i 4.4.4.4/32 3.3.3.3 0 100 0 4i
Load Balancing when earlier rules tie
If the first eight rules cannot determine a best path, BGP load balancing can be enabled to install multiple next-hops into the IP routing table.
Notes:
- By default, AS_PATH must be identical for the AS_PATH-based rule in this scenario. If AS_PATH lengths are the same but the paths belong to different ASes, load-balancing will not occur unless AS_PATH checks are ignored. Use load-balancing as-path-ignore in BGP configuration to ignore AS_PATH checks.
Experiment objective: Enable BGP load balancing on R1 so R1 distributes traffic to R4 across multiple next-hops.
# Check R1's IP routing table for 4.4.4.4 before enabling load balancing; only one route is installed [R1-bgp]display ip routing-table 4.4.4.4 Route Flags: R - relay, D - download to fib ... 4.4.4.4/32 IBGP 255 0 RD 2.2.2.2 GigabitEthernet0/0/0 # Enable load balancing in BGP on R1 bgp 123 maximum load-balancing 8 # After enabling, two next-hops are installed in the IP routing table [R1-bgp]display ip routing-table 4.4.4.4 ... 4.4.4.4/32 IBGP 255 0 RD 2.2.2.2 GigabitEthernet0/0/0 ... 4.4.4.4/32 IBGP 255 0 RD 3.3.3.3 GigabitEthernet0/0/1 # Note: In the BGP routing table one path is still marked as best; multiple next-hops are installed at the IP routing table level. [R1-bgp]display bgp routing-table ... *>i 4.4.4.4/32 2.2.2.2 0 100 0 4i * i 3.3.3.3 0 100 0 4i
Rule 9: Shortest cluster_list
Prefer the route with the shortest cluster_list. In route reflector (RR) topologies, a cluster_list attribute is appended each time a route is reflected, similar to AS_PATH. The route with the shorter cluster_list is preferred.
Experiment setup: A hierarchical RR topology is used to demonstrate cluster_list effects. R3 receives a route from R4 and advertises it to R5. R5 is the top-level RR; R1 and R2 are clients of R5. R1 also acts as an RR for R2.
Experiment objective: Verify rule 9 using the RR hierarchy.
# Configure R5 as an RR with peers bgp 123 peer 1.1.1.1 as-number 123 peer 1.1.1.1 connect-interface LoopBack0 peer 2.2.2.2 as-number 123 peer 2.2.2.2 connect-interface LoopBack0 peer 3.3.3.3 as-number 123 peer 3.3.3.3 connect-interface LoopBack0 ipv4-family unicast undo synchronization peer 1.1.1.1 enable peer 1.1.1.1 reflect-client peer 2.2.2.2 enable peer 2.2.2.2 reflect-client peer 3.3.3.3 enable # Configure R1 and R2 similarly as RR clients and reflectors as needed. # After configuration, R2 shows two routes via the same next-hop but with different cluster lists. display bgp routing-table ... *>i 4.4.4.4/32 3.3.3.3 0 100 0 4i ... # Detailed inspection shows different Cluster list values and that one path is not preferred due to "not preferred for Cluster List". display bgp routing-table 4.4.4.4 ... From: 5.5.5.5 ... Cluster list: 5.5.5.5 ... From: 1.1.1.1 ... Cluster list: 10.1.12.1, 5.5.5.5 ... not preferred for Cluster List
Rule 10: smallest router ID or originator_ID
Prefer the route announced by the router with the smallest router ID. If originator_ID is present (from route reflection), compare originator_ID instead of router ID and prefer the smallest originator_ID.
Experiment objective: Demonstrate selection based on originator_ID when route reflector originator attributes are present.
# Configure R6 to peer with R1 and R5 and enable them bgp 123 peer 1.1.1.1 as-number 123 peer 1.1.1.1 connect-interface LoopBack0 peer 5.5.5.5 as-number 123 peer 5.5.5.5 connect-interface LoopBack0 ipv4-family unicast undo synchronization peer 1.1.1.1 enable peer 5.5.5.5 enable # On R6 view BGP table; two paths have Originator attributes. With originator present, originator_ID is compared instead of router ID. [R6-bgp]display bgp routing-table ... *>i 4.4.4.4/32 2.2.2.2 0 100 0 4i * i 3.3.3.3 0 100 0 4i [R6-bgp]display bgp routing-table 4.4.4.4 ... From: 1.1.1.1 ... Originator: 10.1.12.2 Cluster list: 10.1.12.1 ... From: 5.5.5.5 ... Originator: 10.1.13.3 Cluster list: 5.5.5.5 ... not preferred for router ID # Both routes carry originator_ID and are compared by originator_ID values rather than router ID.
Rule 11: smallest peer IP address
The final tie-breaker is the IP address of the peer: prefer the route learned from the peer with the smallest IP address. This is used when all earlier criteria (including originator_ID when present) cannot distinguish between routes.
Experiment objective: Create a scenario where rule 11 is needed and observe selection based on peer IP address.
# Configure R3 to peer with R1 and R5 and enable next-hop-local where needed. bgp 123 peer 1.1.1.1 as-number 123 peer 1.1.1.1 connect-interface LoopBack0 peer 5.5.5.5 as-number 123 peer 5.5.5.5 connect-interface LoopBack0 peer 10.1.34.4 as-number 4 ipv4-family unicast undo synchronization peer 1.1.1.1 enable peer 1.1.1.1 next-hop-local peer 5.5.5.5 enable peer 5.5.5.5 next-hop-local peer 10.1.34.4 enable # Configure R5 to peer with R2 and R3 and act as route reflector for them bgp 123 peer 2.2.2.2 as-number 123 peer 2.2.2.2 connect-interface LoopBack0 peer 3.3.3.3 as-number 123 peer 3.3.3.3 connect-interface LoopBack0 ipv4-family unicast undo synchronization peer 2.2.2.2 enable peer 2.2.2.2 reflect-client peer 3.3.3.3 enable peer 3.3.3.3 reflect-client # Configure R1 similarly to R5 # On R2's BGP table two routes to 4.4.4.4 exist; detailed inspection shows the non-preferred path is flagged "not preferred for peer address". [R2-bgp]display bgp routing-table ... *>i 4.4.4.4/32 3.3.3.3 0 100 0 4i ... From: 1.1.1.1 ... Cluster list: 10.1.12.1 ... From: 5.5.5.5 ... Cluster list: 5.5.5.5 ... not preferred for peer address # Because all prior attributes are equal and originator is equal, the peer IP address is used as the final tie-breaker.
