Let’s take this scenario.

Colletidae, a blellum lady living in the outskirt of Edinburgh, told her neighbor Apidae that Dasypoda is having an illegal affair with somebody else. Colletidae told Apidae that she can spread that in town. And, because Colletidae wants so much attention, she told her to tell everybody that she is the one who told her about it. Colletidae knows that everybody will believe Apidae as she is known to be an honest quine. Apidae cannot believe it and she told Andrena, sister of Andrenidae, about this.

“Don’t be such a wee clipe!”, said Andrena. “Are you the one spreading that rumor?”

“No, it’s not me. It’s Colletidae who told me about that.” Apidae replied.

When Andrena told her sister about this rumor,

“Who told you that?” Andrenidae asked

“Colletidae knows everything about Dasypoda’s affair,” Andrena whispered.

“Who is Colletidae?” Andrenidae asked.

Andrenidae, who is one of Dasypoda’s best friend, knows that it was her sister who told her about the affair rumor. What she didn’t know is that it was Apidae who told her sister about this and that Apidae knows where Colletidae lives.

This is true with partial mesh topology in iBGP. There is no route back to Colletidae.

With the use of next-hop-self command, it would force the iBGP speakers to advertise the route with the next hop address of its own.

Let’s do a simple lab about this scenario.

Let’s see what will happen after Dasypoda advertised its loopback address.

Enter configuration commands, one per line. End with CNTL/Z.
Dasypoda(config)#router bgp 600
Dasypoda(config-router)#network 6.6.6.0 mask 255.255.255.0
Dasypoda(config-router)#end

After Dasypoda advertised its loopback address, Colletidae learned it and install it in its routing table:

Local Preference is used to influence outbound traffic. The higher value is preferred over the lower one.

Let’s take an example.

Looking at my diagram, to route traffic to Dasypoda, if we have all BGP attribute set as default, what path will Apidae take? Is it going to be Colletidae (10.0.30.3)->Dasypoda (10.0.60.6) or  Andrenidae (10.0.70.4)-> Mellitinae (10.0.40.5) -> Dasypoda (10.0.50.6)? If we didn’t set the Local Preference, it will surely go to Collitidae (10.0.30.3)->Dasypoda (10.0.60.6) path.

Let us check the routing table to know why it prefers the Colletidae (10.0.30.3)->Dasypoda (10.0.60.6) path:

As you can see, the valid best path to 6.6.6.0/24 is through 10.0.30.3.

The question is why? Since Local Preference is not configured, BGP checks the next path selection attribute which is the AS Path. The shortest is more preferred. However, we do not want the Colletidae (10.0.30.3)->Dasypoda (10.0.60.6) path. We want the packet to take the Andrenidae (10.0.70.4)-> Mellitinae (10.0.40.5) -> Dasypoda (10.0.50.6) path. So how are we going to do it? Let us configure the Local Preference.

Apidae(config)#route-map PRIMARY-PATH permit 10
 Apidae(config-route-map)#set local
 Apidae(config-route-map)#set local-preference ?
 <0-4294967295> Preference value


Apidae(config-route-map)#set local-preference 250
 Apidae(config-route-map)#exit
 Apidae(config)#router bgp 65500
 Apidae(config-router)#neigh 10.0.70.4 route-map PRIMARY-PATH ?
 in Apply map to incoming routes
 out Apply map to outbound routes

Apidae(config-router)#neigh 10.0.70.4 route-map PRIMARY-PATH in
 Apidae(config-router)#end

Now that the LOCAL PREFERENCE is changed to prefer the route to neighbor Andrenidae, the path Andrenidae (10.0.70.4)-> Mellitinae (10.0.40.5) -> Dasypoda (10.0.50.6)  is now considered as the best valid path in the BGP table.

There is another way of manipulating the Local Preference and it is through bgp default local-preference command. Keep in mind that it is just changing the default value of Local Preference from 100 to the value you entered.

Before we end this discussion, what can you notice about this ping result?

We have configured the Local Preference and it works as it prefers the Andrenidae (10.0.70.4)-> Mellitinae (10.0.40.5) -> Dasypoda (10.0.50.6). But what happened to the return traffic? We will see why on our next topic – BGP Multi-Exit Discriminator (MED).

BGP has many attributes in choosing the best path. It is like an ice cream. It has many flavors. I bought Gianduia flavor from Gelato Messina while I was preparing this topic. I think I need loads of sugar to feed my brain as this BGP topic is robust and every attribute can be well-explained if we are going to lab it.

BGP’s attributes are mainly for path manipulation and these can influence either outbound or inbound traffic. It has a systematic process that it uses to choose the best path in the network.

The first thing that BGP checks is whether the WEIGHT is configured or not. WEIGHT is Cisco Proprietary so it is obvious that it prioritizes Cisco devices which has BGP WEIGHT configured. In short, if you are using Cisco devices, WEIGHT is the first thing it checks before it goes on with the series of standard BGP attributes. Keep in mind that WEIGHT is local to the router and doesn’t pass to other routers. The higher the value is more preferred.

Next in line is the LOCAL PREFERENCE. This attribute influences the outbound routing. The higher value is preferred. Unlike WEIGHT, which has a default value of 0, LOCAL PREFERENCE has a default value of 100.

If LOCAL PREFERENCE is not configured, BGP looks for locally originated routes. As the name suggests, it is a route originated by the local router via network statement, redistribution, or aggregate statement. If you do “show ip bgp” routes with weight set to “32768” is considered as local routes. When weight is configured check for routes with next hop of “0.0.0.0.” You can also use “route-map localonly” command to get locally originated routes. It is also local to the router an not pass to other peers.

The most commonly used BGP attribute is the AS PATH. Unlike, LOCAL PREFERENCE, AS Path is a Well-Known Mandatory attribute and this attribute influences inbound routing. It should be present in every update and should be recognized by all BGP speakers. When a router running BGP session sends an update to its peer, it appends its own AS number. The shorter the AS path length is more preferred. To manipulate the incoming traffic to our preferred route, we can use the “as-path prepend” command.

Like, AS PATH, ORIGIN is also a Well-Known Mandatory attribute. In this attribute, the lowest is preferred route. IGP is lower than Exterior Gateway Protocol (EGP), and EGP is lower than INCOMPLETE. If you do “show ip bgp” you will see ORIGIN codes at the far right portion: i – IGP, e – EGP, and ? – incomplete. You will no longer see “e” in the “show ip bgp” output as it is already obsolete. The question mark “?” indicates redistribution and “i” means the network command is used to advertise the route.

Multi-exit Discriminator (MED) is an optional non-transitive BGP attribute. It is usually not used as the first five attributes are often utilized before this one. MED can influence routers in the same AS (iBGP) but not on different AS (eBGP). When a router learns a route from a peer, the MED’s value is kept and retain to its iBGP peers, but the value will be peeled off once it passed to eBGP peers. You can use the “set metric” command under the BGP router process if you are using a route-map or use the “default-metric” command. Take note that the lowest MED value is preferred over the higher MED value.

If MED is not configured, it checks whether the route is learned via iBGP or eBGP. Routes learned via eBGP is more preferred than routes learned via iBGP. If both routes are learned via eBGP then it chooses the lowest IGP value (administrative distance) to the next hop.

BGP Multipath is not considered as a tie-breaker but a determination if it can allow multiple installation of path in the routing table. The WEIGHT, LOCAL PREFERENCE, AS PATH, ORIGIN, MED value, same neighbor type (eBGP / iBGP) and IGP metric should match with the best path for it to be considered as an additional path to the destination. Be aware that if multipath is not enabled the default value is 1 which means it goes back to the BGP’s golden rule that it only chooses one best path to the destination.

The next step that BGP considers is the oldest route received. The oldest route in the routing table is preferred over the new ones. This step can be skipped if router ID is used for tie breaker and that the “bgp bestpath compare-routerid” command is used. If the command is used, the lowest router ID will be selected as the best path. If there is no manually configured router ID, the highest loopback IP is chosen and if still there is none, then the highest configured physical IP address. By the way, before you considered the highest physical IP address, it is necessary to check the route with minimum cluster list length configured. This is present in a route reflector environment. There’s more about this when we get to the route reflector topic.

Before we end this topic, let me remind you that before it goes to these 13 procedures, the first thing that BGP check is whether the next hop is reachable or not. What’s the use of all of these if the route is not reachable anyway?

• AS Path, BGP, BGP attributes, BGP multipath, BGP path selection, Border Gateway Protocol, eBGP, EGP, iBGP, IGP, Local Preference, MED, Multiexit Discriminator, Origin, route reflector, router ID, Weight
•  5 Comments

• « BGP Path Attributes Types
• iBGP: BGP Next-Hop-Self Command »

5 comments on “BGP Path Attributes: The BGP Path Selection Process”

1. Pingback: BGP Path Attributes Types – Sassenach Learns
2. Pingback: iBGP: BGP Next-Hop-Self Command – Sassenach Learns
3. Pingback: BGP Local Preference Attribute: The Higher The Better – Sassenach Learns
4. Pingback: The Internet Protocol: Border Gateway Protocol (BGP) Overview – Sassenach Learns
5. Pingback: BGP Route Reflectors (RR) – The iBGP Reflection Mechanism – Sassenach Learns

Leave a Reply

Your email address will not be published. Required fields are marked *

Comment

Name *

Email *

Website Search

CATEGORIES

• Cisco
• Routing
• Switching

RECENT POSTS

• Hot Standby Router Protocol (HSRP) Overview: You’ve Got A Friend
• Port-Channel in NX-OS: Let’s Bundle Up!
• VLAN Trunking Protocol (VTP) in Nexus NX-OS – Slight Difference with IOS
• BGP Route Reflectors (RR) – The iBGP Reflection Mechanism
• The EIGRP Packet Header

As of now, the 2 bytes AS that we used to know are already depleted so that’s why IETF introduced 4 bytes (0-4294967295) AS. In the router implementation, an ASdot notation or ASplain format will be used to identify a 32-bit AS number. The ASplain format is just writing the whole 0-4294967295 numbers. The problem with this is that it is prone to typo errors. The ASdot format will use this number: <upper 16 bits>.<lower 16 bits>. The first set of 65,536 numbers will be written as 0.0 to 0.65535 and the second set from 1.0 through to 1.65535, and so on.

AS 23456 will play a major part as it is reserved as interface between 16-bit and 32-bit AS. The 32-bit AS numbers will appear as AS 23456 in the new BGP attribute AS4 Path (AS Path on 16-bit). The 32-bit AS number is backward compatible with the 16-bit so one thing that is required is making sure the router supports 32-bit AS under the BGP command process.

If you are having a problem converting the ASplain format to ASdot format, you may try this conversion tool provided by APNIC: 32-Bit Conversion Tool. This tool converts Autonomous System numbers from dot notation to decimal or from decimal to dot notation.

For example: 100500 ASplain is equivalent to 1.34964 ASdot notation.

Below is the IANA assignment for the 32-bit notation:

BGP attributes are classified into 4 types:

1. Well-known Mandatory
2. Well-known Discretionary
3. Optional Transitive
4. Optional Non-Transitive

Well-known Mandatory attributes, as the name suggests, it is a must in every BGP update to have it included. It should exist in every BGP update and must be recognized by all BGP speakers. Well-known mandatory attributes are AS Path, Next Hop address, and Origin.

Well-known Discretionary must be recognized by all BGP speakers but not necessarily included in every BGP update. It includes Local Preference and Atomic Aggregate.

Optional Transitive and Optional Non-Transitive are attributes that don’t need to be understood and supported by all BGP speakers. The main difference between these two is that if it is set as transitive, it means it has to advertise to all peers and if is set as non-transitive then it can be ignored and not passed to other peers. Optional Transitive attributes are Aggregator and Community. Optional Non-Transitive attributes are Originator ID and Cluster List.

BGP path attributes types don’t seem to be of importance for now. However, as we go further our BGP studies, we will realize the essence of it.