USD ($)
United States Dollar
India Rupee

BGP Best Path Selection Criteria

Created by Deepak Sharma in Articles 10 May 2024

BGP is the exterior gateway protocol (EGP), at the core of its routing process, BGP uses best path selection criteria to identify it's best route to forward traffic. If you are unsure about what is BGP and how does it work then first review these concepts and come back to this blog. 

While traditional interior gateway protocols (IGPs) like EIGRP and OSPF use shortest path selection procedure to determine best routing path.

BGP prefixes cannot have a classic (additive) metric associated with them, as BGP in most cases is a multi-hop peering. That's the reason BGP uses this complicated procedure for selecting best path instead of the shortest path. 

Properties to Consider Before BGP Path Selection Attributes

The purpose of the BGP path selection algorithm procedure is to select optimal paths based on administrative preferences while maintaining the following properties:

1. BGP Routing Loop Detection: 

The BGP best path selection should form a loop-free topology. It implements this by filtering prefixes with the AS number matching the local AS in the AS_PATH attributes.

2. BGP Deterministic Path Selection:

All BGP routers under the same conditions (such as all IBGP speakers configured similarly) must select the same best paths.

3. BGP Routing Table Stability:

The best path selection in BGP should not result in constant oscillating route insertion and removals.

4. Information Flooding Minimization:

A BGP speaker only sends the best paths to its neighbors when bgp states are established. This significantly reduces the amount of update flooding, saving bandwidth and CPU cycles. 

Before we start with BGP path selection criteria process, recall that every BGP prefix has a set of attributes associated with it. The procedure uses those attributes when looking for optimal paths. 

Prefix Exclusion Criteria for Best Path Selection in BGP

Some of the attributes have more influence on the result than others, as we’ll see later. Before the procedure runs, the BGP best path selection process excludes some prefixes based on the following criteria:

1. No valid next-hop

This is the most common cause for the prefix being ignored by the selection process. BGP prefixes carry their next-hop as a separate attribute (NEXT_HOP attribute). If the next-hop address is NOT reachable via IGP, the prefix is marked as invalid and is not considered.

This usually happens with eBGP-learned prefixes when you forget to enter the command next-hop-self or advertise the link subnet into IGP/BGP.

2. BGP Synchronization

When it enables and the prefix is not in the IGP table. The best path selection in BGP process will ignore this prefix. This is a legacy restriction, but you may occasionally run into it.

3. AS_PATH Loop

Prefixes from the neighbor that has the local AS number in the AS_PATH attribute are dropped. This is the well-known BGP loop detection mechanism.

All eligible paths are then sorted, and prefixes for the same destination (subnet/mask) are grouped together (the actual implementation may differ, though, as a result of various optimizations). 

BGP Best Path Selection Criteria

For every group, BGP must elect the best path. Here is a short outline of the steps performed by the BGP path selection attributes. Every step is tried if the previous one cannot reveal the best path:

1# Invalid Path

Ignore invalid paths (no valid next-hop, not synchronized, looped).

2# Weight

Prefer path with the highest locally assigned BGP weight attribute value.

3# Local Preference

Prefer path with the highest Local Preference attribute value.

4# Locally Originated

Prefer locally originated prefixes (originated via the network, aggregate-address, or redistribution commands).

5# AS Path

Prefer path with the shortest AS_PATH attribute length.

6# Origin code

Prefer path with the lowest Origin Type (value for the Origin code), where IGP < EGP < Incomplete.

7# MED

Prefer path with the lowest BGP MED attribute value (provided that the first AS in the list is the same).

8# eBGP vs iBGP

Prefer external BGP paths over internal BGP paths.

9# IGP Metric

Prefer path with the smallest IGP metric to reach the NEXT_HOP IP address.

10# Router ID

Prefer path originated from the router with the lowest BGP Router ID

BGP Path Selection Using Weight Attribute

Let's understand BGP weight attribute with this scenario task in which using the most influential attribute i.e. weight configure R7 which achieve the following

● Traffic from AS 300 going to prefixes originated in AS 54 exits toward R3

● Traffic from AS 300 going to prefixes originated in AS 254 exits toward R6 

Before everything else, BGP prefers paths with the highest weight value. Weight is Cisco-specific and is not transported along with BGP prefixes/updates.

This attribute is configured locally on the router, using the command neighbor weight 1-65535 .

As mentioned, higher-weight values are preferred and the default weight is zero for learned prefixes. Thus, among two equal prefixes with different weights, the one with the highest weight is preferred.

This attribute is commonly used in scenarios where the local router has multiple uplinks and you want to prefer one uplink over another. In addition to the neighbor command, the weight attribute could be set using inbound route-map associated with the neighbor, for example:

route-map SET_WEIGHT

math ip address ACCCESS_LIST

set weight 100


router bgp 100

neighbor route-map SET_WEIGHT in

This method could be used to change specific prefix preference without affecting any other subnets learned from the same peer.

Remember that BGP weight attribute manipulations only affect the way that the traffic leaves the local router.

Notice that IOS routers assign the weight value of 32768 to all locally advertised prefixes—prefixes advertised using the network or aggregate-address commands or via route redistribution. This feature ensures that all locally originated prefixes are always preferred over the same prefixes learned from the peers. 

The solution for this task uses AS-PATH access-lists to match all prefixes from AS 54 and 254. The regular expressions to match all networks originated from AS 54 and 254, respectively, are 54$ and 254$ . R7 peers with R6 and R3, and we manipulate weight values as follows:

For prefixes originated from AS 254 and received from R6, we set the weight value to 1000. This makes R7 prefer paths to AS 254 via R6, as opposed to R3. 

For prefixes originate from AS 54 and received from R3, we set the weight value to 1000 as well. As a result, R7 prefers paths to AS 54 via R3, where it should prefer paths via R9 by default. Always remember to create a “permit” entry at the end of your route-maps, or you may unintentionally filter non-matching networks.


no ip as-path access-list 1

no ip as-path access-list 2

ip as-path access-list 1 permit _54$

ip as-path access-list 2 permit _254$


route-map FROM_R6 permit 10

match as-path 2

set weight 1000


route-map FROM_R6 permit 100


route-map FROM_R3 permit 10

match as-path 1

set weight 1000


route-map FROM_R3 permit 100


router bgp 300

neighbor route-map FROM_R6 in

neighbor route-map FROM_R3 in

BGP Weight Attribute - Verification

Before you start any verification, use the command clear ip bgp * soft to force R7 to refresh the information learned from its peers. By default, when you apply any new policy it does not take effect unless the new updates are received/sent.

Because BGP does not use periodic updates, you may need to force an update manually. The command performs a “soft-reset”; it does not tear down BGP sessions but simply sends out BGP updates and requests route-refresh from the peers.

Compared to clear ip bgp * , it causes much less load on the router’s CPU and does not disrupt traffic routing:

R7#clear ip bgp * soft

Now let’s look through the BGP table in R7. Notice the use of regex-based filter _54$ to select only the prefixes originated in AS 54. Look at the prefixes received from R3, they are selected as “best” and marked with the “>” sign, and the weight assigned is 1000. The “losing” prefixes have the weight value of 0 (the default):

R7#show ip bgp regexp _54$

BGP table version is 36, local router ID is

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

   Network                          Next Hop                          Metric      LocPrf      Weight      Path

*                                                                         0      100 200 54 i

*                                                                                                      0     54 i

*>                                                                                             1000     200 54 i

*                                                                           0    100 200 54 i

*                                                                                                        0   54 i

*>                                                                                              1000   200 54 i

*                                                                                       0  100 200 54 i

*>                                                                                               1000   200 54 i

*                                                                    0                                  0   54 i

----------------------------output snipped------------------------------

Repeat the same check with the prefixes originated in AS 254. Notice that now R6 is selected as the upstream peer to route to these subnets:

R7#show ip bgp regexp 254$

BGP table version is 36, local router ID is

Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,

r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,

x best-external, a additional-path, c RIB-compressed,

Origin codes: i - IGP, e - EGP, ? - incomplete

RPKI validation codes: V valid, I invalid, N Not found

Network                          Next Hop                          Metric      LocPrf      Weight      Path

*>                                                           1000         100 200 254 ?

*                                                                                               0         200 254 ?

*>                                                                  1000         100 200 254 ?

*                                                                                                0        200 254 ?

*>                                                                 1000       100 200 254 ?

----------------------------output snipped------------------------------

Deepak Sharma

He is a senior solution network architect and currently working with one of the largest financial company. He has an impressive academic and training background. He has completed his B.Tech and MBA, which makes him both technically and managerial proficient. He has also completed more than 450 online and offline training courses, both in India and ...

More... | Author`s Bog | Book a Meeting

Comments (0)

Deepak Sharma

Deepak Sharma

Senior Instructor (Part Time) at UniNets Instructor role
★★★★★ 4.95
Faithful User
Expert Vendor
Golden Classes
King Seller
Fantastic Support
Loyal Writer

Upcoming batches

+91 84484 40748

Enquire Now

Share to your friends


Share this post with others

Contact learning advisor

New Cisco ACI Training Live Batch Starts June 15th!
New Cisco ACI Training Live Batch Starts June 15th!
Advance your career? Don't miss out on our Cisco Application Centric Infrastructure (ACI) training ...
Enroll Now