BGP uses autonomous system (AS) numbers to distinguish routing boundaries between two different organizations. BGP is considered a path vector protocol because it chooses the shortest AS path as the best path by default. The difference between this and the IGP protocols is that BGP doesn’t take into account the bandwidths of the links involved in the AS path nor the number of hop counts. The logic of BGP is that it’s nearer when there are fewer AS involved to get into the destination route.

However, using the default shortest AS path attribute is not always the case in the real world. BGP is rich with features and attributes to set the best path. This is all the more the reason why administrators won’t stick to using just the AS path attribute. One common method is using communities to mark prefixes and apply policies for each. Since an AS is a group of devices being managed by an organization or group, each Internet service provider has its own policy on how to route the traffic. One group cannot simply dictate to the other on these routing policies. This also means that the Internet has a lot of asymmetric routes due to these different policies.

Here is a link to Cisco’s documentation on the BGP path selection process. It is a sequence of attributes that BGP uses to determine the best path. If there is a tie in the value of the attribute, BGP checks the next attribute listed until it finds the best path.

In this article we will create a lab on how to control BGP prefixes through the use of weight, local preference, and MED so we can understand better on how to apply these in real world situations. The downloadable start-up configurations contain a full working BGP topology. The diagram and the tasks that we will be doing in this lab are shown below:

1. Use weight so that R3 will take R2 to reach R6 prefixes.
2. Configure weight so that R3 will chose R1 to reach 66.66.66.66/32 and R3 will still take R3 to reach the rest of R6 prefixes without removing the previous configuration.
3. Configure R2 with local preference of 500 so that R1 will prefer R2 to reach all the prefixes of AS 456.
4. Configure R1 to set a local preference of 600 to 4.4.4.4/32 prefix and take the direct path to R4.
5. Configure R1 and R2 to influence AS456 to take the path using R2 to reach R3’s prefixes.

Task 1: Use weight so that R3 will take R2 to reach R6 prefixes.

Weight is a Cisco proprietary attribute of BGP that allows the router to choose the path to destination if the router has multiple links. The higher the weight, the more it is preferred. Weight is not a transitive attribute which means that it can’t influence the routing decision of the other routers. The other routers with no weight configured will use the other attributes for path selection process.

Let’s check R3 to determine which path it is using to reach R6 prefixes.

R3#sh ip bgp
BGP table version is 15, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*>i1.1.1.1/32 13.13.13.1 0 100 0 i
*>i2.2.2.2/32 23.23.23.2 0 100 0 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
*>i4.4.4.4/32 13.13.13.1 0 100 0 456 i
*>i5.5.5.5/32 23.23.23.2 0 100 0 456 i
* i6.6.6.6/32 23.23.23.2 0 100 0 456 i
*>i 13.13.13.1 0 100 0 456 i
*> 30.30.30.30/32 0.0.0.0 0 32768 i
*> 33.33.33.33/32 0.0.0.0 0 32768 i
* i60.60.60.60/32 23.23.23.2 0 100 0 456 i
*>i 13.13.13.1 0 100 0 456 i
* i66.66.66.66/32 23.23.23.2 0 100 0 456 i
*>i 13.13.13.1 0 100 0 456 i

We can see that it is using 13.13.13.1, which belongs to R1, to reach R6’s prefixes. The best path to a destination is always marked with “>“. Let’s configure R3’s BGP peering with R1 with a weight of 150 and peering with R2 with 200.

R3(config)#router bgp 123
R3(config-router)#neighbor 13.13.13.1 weight 150
R3(config-router)#neighbor 23.23.23.2 weight 200

R3#sh ip bgp
BGP table version is 25, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*>i1.1.1.1/32 13.13.13.1 0 100 150 i
*>i2.2.2.2/32 23.23.23.2 0 100 200 i
*> 3.3.3.3/32 0.0.0.0 0 32768 i
*>i4.4.4.4/32 13.13.13.1 0 100 150 456 i
*>i5.5.5.5/32 23.23.23.2 0 100 200 456 i
*>i6.6.6.6/32 23.23.23.2 0 100 200 456 i
* i 13.13.13.1 0 100 150 456 i
*> 30.30.30.30/32 0.0.0.0 0 32768 i
*> 33.33.33.33/32 0.0.0.0 0 32768 i
*>i60.60.60.60/32 23.23.23.2 0 100 200 456 i
* i 13.13.13.1 0 100 150 456 i
*>i66.66.66.66/32 23.23.23.2 0 100 200 456 i
* i 13.13.13.1 0 100 150 456 i

Before we configured the weight, the show command indicated a weight of 0 for prefixes that are not locally originated. In the most recent show command above, we can see the values marked as 150 and 200 depending on the next-hop the route was received from. The path to R2 is now preferred and has been marked with “>.” The “neighbor x.x.x.x weight” command will apply the weight value to all prefixes received from the neighbor.

Task 2: Configure weight so that R3 will chose R1 to reach 66.66.66.66/32 and R3 will still take R3 to reach the rest of R6 prefixes without removing the previous configuration.

We will now make it more interesting. Without removing the previous commands, we will make R3 reach 66.66.66.66/32 through R1 and retain the other two prefixes to take R2. We will do this by using access-list and route-map. The access-list will classify what prefix we want to manipulate and the route-map will tell what actions we want to do with that prefix.

R3(config)#access-list 1 permit host 66.66.66.66
R3(config)#route-map PREFER_R1 permit 10
R3(config-route-map)#match ip address 1
R3(config-route-map)#set weight 300
R3(config-route-map)#route-map PREFER_R1 permit 20
R3(config-route-map)#router bgp 123
R3(config-router)#neigh 13.13.13.1 route-map PREFER_R1 in

R3#show ip bgp regexp _456
BGP table version is 26, local router ID is 3.3.3.3
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*>i4.4.4.4/32 13.13.13.1 0 100 150 456 i
*>i5.5.5.5/32 23.23.23.2 0 100 200 456 i
*>i6.6.6.6/32 23.23.23.2 0 100 200 456 i
* i 13.13.13.1 0 100 150 456 i
*>i60.60.60.60/32 23.23.23.2 0 100 200 456 i
* i 13.13.13.1 0 100 150 456 i
* i66.66.66.66/32 23.23.23.2 0 100 200 456 i
*>i 13.13.13.1 0 100 300 456 i

The route-map was then applied to the neighbor in the inward direction. The reason we are using “in” in the route-map is because we are receiving the prefix from the neighbor and then setting the weight to 300. The “show ip bgp” command now shows that 66.66.66.66/32 now takes R1.

Task 3: Configure R2 with local preference of 500 so that R1 will prefer R2 to reach all the prefixes of AS 456.

The local preference attribute is used to influence other routers in the same autonomous system on how to reach prefixes outside of the AS. This is a non-transitive attribute, but you may consider it transitive when taking the perspective inside the AS. The higher the local preference, the more preferred.

First let’s check the preferred path for R1 to reach AS456. It should be going through R4.

R1#sh ip bgp
BGP table version is 18, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*> 1.1.1.1/32 0.0.0.0 0 32768 i
*>i2.2.2.2/32 23.23.23.2 0 100 0 i
*>i3.3.3.3/32 13.13.13.3 0 100 0 i
* i4.4.4.4/32 23.23.23.2 0 100 0 456 i
*> 14.14.14.4 0 0 456 i
*> 5.5.5.5/32 14.14.14.4 0 456 i
* i 23.23.23.2 0 100 0 456 i
* i6.6.6.6/32 23.23.23.2 0 100 0 456 i
*> 14.14.14.4 0 456 i
*>i30.30.30.30/32 13.13.13.3 0 100 0 i
*>i33.33.33.33/32 13.13.13.3 0 100 0 i
* i60.60.60.60/32 23.23.23.2 0 100 0 456 i
*> 14.14.14.4 0 456 i
*> 66.66.66.66/32 14.14.14.4 0 456 i

Let’s configure R2 and set its local preference to 500.

R2(config)#router bgp 123
R2(config-router)#bgp default local-preference 500

Now let’s verify that R1 is really taking R2 to reach R6 prefixes.

R1#sh ip bgp regexp _456
BGP table version is 23, local router ID is 1.1.1.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
*>i4.4.4.4/32 23.23.23.2 0 500 0 456 i
* 14.14.14.4 0 0 456 i
* 5.5.5.5/32 14.14.14.4 0 456 i
*>i 23.23.23.2 0 500 0 456 i
*>i6.6.6.6/32 23.23.23.2 0 500 0 456 i
* 14.14.14.4 0 456 i
*>i60.60.60.60/32 23.23.23.2 0 500 0 456 i
* 14.14.14.4 0 456 i
*> 66.66.66.66/32 14.14.14.4 0 456 i

R1#traceroute 4.4.4.4 source 1.1.1.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 13.13.13.3 36 msec 28 msec 16 msec
2 23.23.23.2 48 msec 36 msec 40 msec
3 25.25.25.5 72 msec 68 msec 60 msec
4 56.56.56.6 60 msec 64 msec 68 msec
5 46.46.46.4 68 msec 60 msec 64 msec

The traceroute indicates that R1 is now taking the path to R2 to reach R4 Loopback0. Even though R4 is directly connected to R1, due to local preference influence, we have diverted it to R2. One thing is strange though: Notice that 66.66.66.66/32 was not marked with local preference of 500. Do you know the reason? This is because R3 removed the value and made sure R4 is the best path to 66.66.66.66/32 because, for R1 to reach 66.66.66.66/32, it needs to go through R3 but R3’s path to 66.66.66.66/32 is through R1. This will create a routing loop if R3 still announces the path to R2 as the best path for R1 to reach 66.66.66.66/32.

Task 4: Configure R1 to set a local preference of 600 to 4.4.4.4/32 prefix and take the direct path to R4.

The routing situation in R1 is now very inefficient. To reach 4.4.4.4/32, it needs a longer path through R2. The most efficient path is to use R4, since 4.4.4.4/32 is directly connected to R4. Similar to weight, we can use a route-map to make it possible.

R1(config)#access-list 1 permit host 4.4.4.4
R1(config)#route-map PREFER_R4 permit 10
R1(config-route-map)#match ip address 1
R1(config-route-map)#set local-preference 600
R1(config-route-map)#route-map PREFER_R4 permit 20

R1(config)#router bgp 123
R1(config-router)#neigh 14.14.14.4 route-map PREFER_R4 in
R1#clear ip bgp * soft

Let's verify if it's now taking the direct path.
R1#sh ip bgp 4.4.4.4
BGP routing table entry for 4.4.4.4/32, version 24
Paths: (2 available, best #2, table Default-IP-Routing-Table)
Flag: 0x940
Advertised to update-groups:
1 2
456
23.23.23.2 (metric 2) from 13.13.13.3 (3.3.3.3)
Origin IGP, metric 0, localpref 500, valid, internal
Originator: 2.2.2.2, Cluster list: 3.3.3.3
456
14.14.14.4 from 14.14.14.4 (4.4.4.4)
Origin IGP, metric 0, localpref 600, valid, external, best

R1#traceroute 4.4.4.4 source 1.1.1.1

Type escape sequence to abort.
Tracing the route to 4.4.4.4

1 14.14.14.4 20 msec 24 msec 16 msec

Task 5: Configure R1 and R2 to influence AS456 to take the path using R2 to reach R3’s prefixes.

MED (multi-exit Discriminator) is a BGP attribute that is used to influence the other AS on how to reach the prefixes inside your own AS. The lower the MED, the higher the preference. Note that if the neighbor PE routers are configured with local preference, then using MED is futile, as local preference is prioritized in the BGP path selection process over MED. MED is not widely used in the real world, but this can be helpful in situations where the neighbor AS routers can’t be configured due to some process restrictions, such as when no change request has been raised. MED is also called “metric,” as you can see in output of the BGP show commands.

Let’s check R6’s path to reach R3’s prefixes.

R6#sh ip bgp regexp _123
BGP table version is 16, local router ID is 6.6.6.6
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
r RIB-failure, S Stale
Origin codes: i - IGP, e - EGP, ? - incomplete

Network Next Hop Metric LocPrf Weight Path
* i1.1.1.1/32 56.56.56.5 0 100 0 123 i
*>i 46.46.46.4 0 100 0 123 i
*>i2.2.2.2/32 46.46.46.4 0 100 0 123 i
* i 56.56.56.5 0 100 0 123 i
* i3.3.3.3/32 56.56.56.5 0 100 0 123 i
*>i 46.46.46.4 0 100 0 123 i
* i30.30.30.30/32 56.56.56.5 0 100 0 123 i
*>i 46.46.46.4 0 100 0 123 i
* i33.33.33.33/32 56.56.56.5 0 100 0 123 i
*>i 46.46.46.4 0 100 0 123 i

It’s clearly taking the path through R4. Let’s configure R1 and R2 to change the path. We will configure R2’s MED lower than R1.

R2(config)#access-list 10 permit host 3.3.3.3
R2(config)#access-list 10 permit host 33.33.33.33
R2(config)#access-list 10 permit host 30.30.30.30
R2(config)#route-map SET_MED permit 10
R2(config-route-map)#match ip address 10
R2(config-route-map)#set metric 30
R2(config-route-map)#route-map SET_MED permit 20
R2(config-route-map)#router bgp 123
R2(config-router)#neigh 25.25.25.5 route-map SET_MED out

R1(config)#access-list 10 permit 3.3.3.3
R1(config)#access-list 10 permit 33.33.33.33
R1(config)#access-list 10 permit 30.30.30.30
R1(config)#route-map SET_MED permit 10
R1(config-route-map)#match ip address 10
R1(config-route-map)#set metric 50
R1(config-route-map)#route-map SET_MED permit 20
R1(config-route-map)#router bgp 123
R1(config-router)#neigh 14.14.14.4 route-map SET_MED out

Let’s verify that R6 is now taking R5 to reach R3’s prefixes.

R6#sh ip bgp | beg Network
Network Next Hop Metric LocPrf Weight Path
* i1.1.1.1/32 56.56.56.5 0 100 0 123 i
*>i 46.46.46.4 0 100 0 123 i
*>i2.2.2.2/32 46.46.46.4 0 100 0 123 i
* i 56.56.56.5 0 100 0 123 i
*>i3.3.3.3/32 56.56.56.5 30 100 0 123 i
*>i4.4.4.4/32 46.46.46.4 0 100 0 i
*>i5.5.5.5/32 56.56.56.5 0 100 0 i
*> 6.6.6.6/32 0.0.0.0 0 32768 i
*>i30.30.30.30/32 56.56.56.5 30 100 0 123 i
*>i33.33.33.33/32 56.56.56.5 30 100 0 123 i
*> 60.60.60.60/32 0.0.0.0 0 32768 i
*> 66.66.66.66/32 0.0.0.0 0 32768 i

We can see R5 advertised a MED value of 30 to R6 and, in turn, R6 chose R5 as the best path to R3 because local preference in this case is set to the default value of 100 for all prefixes.

References

http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13753-25.html
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/13759-37.html
http://www.cisco.com/c/en/us/support/docs/ip/border-gateway-protocol-bgp/26634-bgp-toc.html