BGP Path Attributes Overview (IX)

BGP path attributes are crucial elements that influence the decision-making process of BGP routers. When you have a BGP-speaking router, it's very common to receive thousands of routes from various peers and, quite often, the same route from multiple sources. So, how does a router decide which path to take to reach a particular destination? This is where BGP path attributes come into play.

Path attributes provide BGP routers with the information needed to choose the best path. They are the criteria based on which BGP makes its routing decisions. Think of them as the factors that influence a router's "opinion" on which route is preferable.

Additionally, these attributes can be manipulated to achieve certain goals. For instance, you might want to block routes originating from a specific AS or prefer routes that come from another AS.

BGP Path Attribute Categories

Here's a brief overview of the four main categories of BGP path attributes.

1. Well-known Mandatory - These attributes must be understood and appear in all BGP updates. Examples include AS Path, Next Hop, and Origin.
2. Well-known Discretionary - These attributes are recognized by all BGP implementations but don't need to be included in every update. Examples include Local Preference and Atomic Aggregate.
3. Optional Transitive - These attributes can be ignored if not understood, but should be passed on to other BGP peers. A BGP router not supporting this attribute can still receive routes with this attribute and advertise them to other peers. Examples include Aggregator and Community
4. Optional Non-Transitive - These attributes can be discarded if not understood and are not passed along to other peers. An example is the MED (Multi Exit Discriminator) attribute.

BGP Best Path Algorithm

When a BGP router receives the same route from multiple sources, it must decide which path to use based on a systematic approach known as the BGP Best Path Selection Algorithm. This process involves evaluating various attributes in a specific order to determine the most preferable route. Here’s a breakdown of the steps involved in the BGP best path selection algorithm.

1. Weight - The route with the highest weight attribute is preferred. It's important to note that weight is a Cisco proprietary attribute, so it may not be used by other vendors.
2. Local Preference - The route with the highest local preference is chosen next. The default value for local preference is 100.
3. Locally Originated - A route that was locally originated, either via the 'network' command or redistributed from an IGP, is preferred over routes received from external sources.
4. AS Path - The route with the shortest AS Path is preferred
5. Origin Code - Routes are preferred based on the origin code, with IGP (i) being most preferred, followed by EGP (e), and lastly Incomplete (?).
6. MED (Multi-Exit Discriminator) - The route with the lowest MED value is preferred. This attribute helps to decide between multiple exits to the same external AS.
7. eBGP over iBGP - Routes learned via eBGP are preferred over routes learned via iBGP.
8. Shortest IGP Metric to next-hop - The route with the lowest IGP metric to reach the next-hop is chosen.
9. Oldest Route - Among equally desirable paths, the oldest route (the one that has been on the table the longest) is preferred.
10. Router ID - If all else is equal, the route with the lowest router ID is preferred.
11. Neighbour IP Address - Finally, the route with the lowest neighbour address (based on IP) is preferred.

I'm going to be using the following diagram for the subsequent examples to demonstrate the BGP best path algorithm. The lab is based on Arista EOS images however, if you are using Cisco you should be able to follow along. The syntax and the outputs are almost identical between Cisco and Arisa.

Weight

The BGP Weight attribute is a Cisco proprietary (I can still use it with Arista) path attribute used to select the best path when multiple routes to the same destination are received on the same router. It's local to the router and isn't advertised to other routers. The higher the weight, the more preferred the route.

We can assign values starting from 0 to 65535. In Cisco, locally generated prefixes get the weight value of 32768 and every other prefix gets the default value of 0

In our network, R6 receives the route to 1.1.1.0/24 from both R3 and R5. By default, R6 prefers the route via R3 (indicated by *>) because it has a shorter AS path.

However, if we want R6 to prefer the route via R5, we can assign a higher weight to the route received from R5 on R6. This adjustment will override the AS path length consideration (remember, weight is at the top of the list for path selection), making R5 the preferred path to reach the 1.1.1.0/24 network.

To make the path via R5 preferable for R6, what we need to do is create a prefix-list on R6 that matches the specific route 1.1.1.0/24. Then, we'll create a route-map that references this prefix-list.

In the route-map, we'll specify the conditions. If a route matches the prefix we're interested in, the weight will be set to a value higher than the default (which is 0). Finally, this route-map will be applied to incoming BGP routes from R5. With a higher weight, the routes received from R5 will take precedence over the ones from R3, making R5 the preferred path.

#R6

ip prefix-list WEIGHT-1-1-1-0
   seq 10 permit 1.1.1.0/24 eq 24

route-map WEIGHT permit 10
   match ip address prefix-list WEIGHT-1-1-1-0
   set weight 10
!
route-map WEIGHT permit 15

router bgp 6000
   neighbor 12.12.36.1 remote-as 3000
   neighbor 12.12.56.1 remote-as 5000
   neighbor 12.12.56.1 route-map WEIGHT in
   network 6.6.6.0/24

clear ip bgp * soft

If you check the output again, you will see that now the preferred path is via R5 as shown below. You can also see the weight of 10 applied to the route 1.1.1.0/24

If you want to apply weight to all the routes that come from a specific neighbour, you can omit the match statement in the prefix list as shown below.

#R6

route-map WEIGHT permit 10
   set weight 10
!
router bgp 6000
   neighbor 12.12.36.1 remote-as 3000
   neighbor 12.12.56.1 remote-as 5000
   neighbor 12.12.56.1 route-map WEIGHT in
   network 6.6.6.0/24

As you can see here, the weight of 10 is applied to all the prefixes that are coming from neighbour R5.

Local Preference

Local preference is a second BGP path attribute that helps you dictate the preferred path for outgoing traffic within your AS.

When your router learns about multiple paths to a particular network, the local preference attribute is used to decide which path to favour. A higher local preference value is more preferred over a lower one. The default value is 100.

This attribute is only relevant within your own network (it's not advertised to external BGP peers), making it a preferred choice for controlling your outbound traffic flows. If you are wondering if this sounds similar to Weight, you are correct. However, weight is not sent across to other iBGP peers but local preference is.

In our scenario, within AS 1000, we have routers R1 and R2 that need to decide the best path to reach the network 6.6.6.0/24 at R6. While R1 receives the prefix directly from R3, R2 gets it via two different paths, one through R1 and the other through R4 and R5. R2 naturally prefers the shorter path through R1.

However, let's say our internal routing policy within AS 1000 wants to prefer traffic to flow through the bottom path via R4, R5, and then R6. To enforce this, we can use the BGP local preference attribute. Local preference is sent to all routers within the same AS and influences the outbound traffic path without needing individual configuration on each router (like weight)

Here's what we do - On R2, we configure BGP to assign a higher local preference to routes to 6.6.6.0/24 received from R4. Consequently, R2 will prefer the route through R4 over the one from R1 due to the higher local preference. Because local preference is propagated throughout the AS, R2 will advertise this (now best path) to R1, influencing R1 to also choose the route through R2, R4, R5, and R6 to reach the network 6.6.6.0/24.

#R2

ip prefix-list LOCAL_PREF
   seq 10 permit 6.6.6.0/24
!
route-map LOCAL_PREF permit 10
   match ip address prefix-list LOCAL_PREF
   set local-preference 110
!
route-map LOCAL_PREF permit 15
!
router bgp 1000
   neighbor 12.12.12.1 remote-as 1000
   neighbor 12.12.22.2 remote-as 4000
   neighbor 12.12.22.2 route-map LOCAL_PREF in
   network 2.2.2.0/24

Thus, by setting a higher local preference on R2 for the specific prefix coming from R4, we can steer traffic through our preferred path within AS 1000.

Originate (Locally Originated)

I'm not going to spend a lot of time here with examples because this is very straightforward.

In BGP, the term 'originate' refers to routes that are generated within a local router and then announced to other BGP peers. These locally originated routes could be the networks that are directly connected to the router or those redistributed from other routing protocols. BGP considers these locally sourced routes as the starting points for BGP path selection, and thus, they have a significant level of trust associated with them. This is because a route that a router originates will always be preferred over a route that is learned from another source.

In Cisco routers, locally originated routes in BGP have a next-hop attribute set to 0.0.0.0, which indicates that the route is originating from the local router. On the other hand, Arista routers denote locally originated routes in their BGP table with a hyphen (-). This distinction is a way to easily identify that the route is local to the router you are currently looking at, rather than learned from another BGP peer.

AS_Path

The AS Path is a well-known, mandatory BGP attribute that lists the autonomous systems a route has traversed. It's used by BGP to prevent routing loops and to select the best path to a destination based on the shortest AS path length.

In our diagram, R6 is receiving the route to 1.1.1.0/24 via two different paths, R1 > R3 > R6 and R2 > R4 > R5 > R6. Assuming all else is equal (same weight and local preference, and neither is a locally originated route of course), BGP's decision algorithm moves on to consider the AS Path. Since the path through R3 is shorter, R6 will prefer this route over the one that passes through R4 and R5. The shorter AS path length makes it the chosen path for R6 to reach the 1.1.1.0/24 network.

AS path manipulation is a technique commonly used to influence inbound traffic. For instance, if AS1000 wants to encourage all inbound traffic to prefer the path via R4, it can artificially lengthen the AS path for the route that passes through R3. This is done by prepending its own AS number multiple times to the AS path attribute. By doing so, to external ASs, this path will appear longer and less desirable. As a result, other autonomous systems will see the path to AS1000 through R3 as 3000 1000 1000 1000, effectively making the route through R4 the more attractive option due to its shorter apparent AS path.

Let's try that on shall we? As always, we need a route map and then apply it to the neighbour.

#R1

route-map AS_PATH permit 10
   set as-path prepend 1000 1000 1000
!
router bgp 1000
   neighbor 12.12.12.2 remote-as 1000
   neighbor 12.12.13.2 remote-as 3000
   neighbor 12.12.13.2 route-map AS_PATH out
   network 1.1.1.0/24

As you can see in the output, the previously preferred route now has additional AS path prepends, making it less preferable. By extending the AS path in this way, AS1000 has effectively influenced the route selection process of other ASs, guiding them on how to reach the networks within AS1000. This demonstrates how you can control the ingress traffic paths to your AS using AS path prepending.

Origin Code

Origin is a well-known mandatory BGP Path attribute that defines the Origin of routing information, aka, how a route became a BGP route.

There are three types of Origin Codes

1. i (IGP) - Has the highest priority and routes are added to the BGP routing table using the network command
2. e (EGP) - This is pretty rare, but it means the route came from EGP. You won't see this often.
3. ? (incomplete) - The routes that are redistributed from other routing protocols to BGP (Static, OSPF, EIGRP)

When I say IGP Origin code has the highest priority what I meant was that let’s say a router learns about the same route from two different places, and everything else about (Weight, Local Preference, AS_Path) these routes are the same.

What happens next? Your router will take a look at the origin code to break the tie. If one of the routes has an origin code of i, that route is the winner (assuming the other has ? for example, meaning the route became a BGP route via redistribution)

Here in our examples, you will see i next to each and every route because we've used the network command on each of them.

MED (Multi-Exit Discriminator)

The MED attribute provides a way to influence another autonomous system in the way to reach a certain route when there are multiple entry points for that AS.

In simple terms, MED is like a signpost you put on the routes you advertise to your neighbours, telling them which path is "cheaper" to get into your network. By setting the MED value, you can guide your neighbours on which road to take when they visit your AS. The lower the MED value, the more appealing the road.

Please note that there are other attributes such as weight, local preference, origin and AS path that are taken into account before you consider the MED attribute.

We will use a slightly modified diagram to demonstrate how MED works.

In this diagram, we're looking at a network with five routers, R1 through R5. R1, R2, and R3 are part of AS 100, while R4 is in AS 200, and R5 is in AS 300. R1 is advertising the prefix 9.9.9.0/24 to R2 and R3, its iBGP peers within AS 100. Both R2 and R3 then propagate this prefix to R4 through eBGP.

So, faced with two potential paths to 9.9.9.0/24, which will R4 choose? Jogging our memory back over the BGP path selection criteria, we've got weight, local preference, origin type, AS_Path length, and origin code which are the same by default. We haven't yet made any specific configurations for the MED attribute.

The tiebreaker here comes down to the 'Oldest Route' attribute. R4 learned about the route from R2 about 00:05:43 ago and from R3 00:05:42 ago. So, the route from R2 wins out.

This is why, in the absence of other differentiating factors, the route via R2 is the one that's selected in the output you'd see on R4.

To steer the inbound traffic to prefer the path through R3 when entering AS 100, we're going to use the MED attribute. MED is a great way to tell external AS's which path they use to reach your AS.

In our case, since we want R4 to favour the path through R3, we'll assign a higher MED value to the route advertised from R2 to R4. Remember, in BGP, a lower MED is more attractive, so by setting a higher MED on routes from R2, we're essentially making them less attractive.

To implement this, we'll set up a route-map on R2 that sets a higher MED for the prefixes it advertises to R4. This route-map is then applied to the neighbour configuration on R2 for R4. With this configuration in place, when R4 compares the MED for the route to 9.9.9.0/24 from R2 and R3, it will see the route from R3 as more appealing due to its lower MED, and thus, direct inbound traffic into AS 100 via R3.

#R2

route-map MED permit 10
   set metric 10

router bgp 100
   neighbor 12.12.12.1 remote-as 100
   neighbor 12.12.23.2 remote-as 100
   neighbor 12.12.24.2 remote-as 200
   neighbor 12.12.24.2 route-map MED out

Keep in mind that the MED value applies only to immediate neighbour autonomous systems. So, the MED value that R2 advertises to R4 is exclusively for R4's consideration. R4 won't pass on this MED value to R5; it will discard the MED value set by R2 before sending any updates to R5. The MED is not a transitive attribute in BGP; it doesn't continue down the BGP path beyond the first hop.

It's also crucial to understand that MED values are compared only when they come from the same AS. This means that if R4 receives the same prefix from a different AS with a different MED value, R4 won't directly compare the MED values from the two different ASs. Each MED is evaluated within the context of routes received from the same AS, rather than across multiple ASs.