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

VERSION

OSPF has two versions: Version 1 (RFC 1131) and Version 2. I’m not sure if anyone has ever tried the version 1. It was published in the year 1989 and it was immediately replaced by version 2. I tried to check the RFC to know more about this but this is what I got:

I cannot differentiate the two versions because right now when we say OSPF (for IPv4), that means we are referring to version 2.

TYPE

There are 5 different OSPF packet types: Type 1 – Hello packet, Type 2- Database Descriptor packet, Type 3 – Link State Request packet, Type 4 – Link State Update packet, and Type 5 – Link State Acknowledgement packet. So if the field has a value of 3 that means it is a Link State Request packet type.

PACKET LENGTH

This is total OSPF packet length in bytes which also includes the OSPF packet header

ROUTER ID
This is the router ID of the source of the packet or the advertising router.

AREA ID
It is the area number to which the message belongs to and presented in dotted decimal.

CHECKSUM
This is the 16-bit standard IP checksum which includes calculation of the entire message except the authentication field.

AUTHENTICATION TYPE

There are 3 OSPF authentication type: 0 – no password, 1 – clear text, 3 – MD5 password. So when you use an MD5 password on the interface, this field should have a value of 3.

AUTHENTICATION

This is a 64-bit field used for data integrity.

LSA Type 1 or called Router LSA, as the name implies, represents the router. Each router within an OSPF area will flood LSA Type 1 and it stays within an area.

Using the “show ip ospf database” command, it shows the router ID of directly connected neighbor and other information about its neighbors of adjacent routers within the same area. Multiple areas can be seen in ABR OSPF database.

LSA Type 2 or Network LSA is the LSA generated by designated router (DR). It contains information about the DR and lists all routers it is adjacent to. If the Link ID in LSA Type 1 is the router ID, the Link ID in LSA Type 2 is the interface IP address of the designated router. And, like the LSA Type 1, it is flooded between neighbors in the same area. This type of LSA can be seen on NBMA and Broadcast networks where DR/BDR is elected.

LSA Type 3 is the ABR Summary LSA. This LSA is generated by the Area Border Routers (ABR) to advertise network from one area to another area. It contains information about inter-area routes. If you see O IA entries in the routing table, these are Type 3 LSAs.

Looking at the screenshot above, the O IA are Type 3 LSAs which are advertised by ABR. Aedes is connected to my Anopheles ABR which has a router ID of 192.168.2.1. Take a look at the screenshot below to further check if it is really the Anopheles ABR advertising the Type 3 LSA route 192.168.12.0.

You can check the advertising routers for all OSPF LSA types by utilizing the “show ip ospf database.” You can further add more parameters whether you want to check advertising router of the external, network, summary, router, and other LSA types.

LSA Type 4 is the ASBR Summary LSA. This LSA is generated by the ABR that contains routes to Autonomous System Border Routers (ASBR). It identifies the ASBR IP address and location. Once ABR received information about ASBR, it will advertise LSA Type 4 and inject the route to area 0. Please note that ASBR itself does not generate LSA Type 4 rather it will generate LSA Type 1 regarding its networks.

LSA Type 5 is the External LSA. This LSA is generated by ASBR. ASBR creates a type 5 LSA for a subnet that is injected into OSPF from an external source or via a redistribute command. As it propagates to the network, the advertising router ID, which is the ASBR router ID, is not changed so router uses Type 4 LSA to know how to reach that ASBR. In the routing table, Type 5 LSA are the O E1 and O E2 entries.

LSA Type 6 is called Multicast LSA which is not generally in used today since the introduction of OSPFv3. To tell you honestly, I don’t even know how it was used before.

LSA Type 7 is the Not-So-Stubby-Area (NSSA) External LSA. This LSA is generated by NSSA ASBR. In an NSSA area, external routes are carried as Type 7 LSA. LSA Type 5 is somehow same with LSA Type 7 as they carry external routes information. However, LSA Type 5 is not allowed on stub areas that is why LSA Type 7 is used as a ploy. LSA Type 7 stays within an NSSA area in order for other routers in other areas know about the external routes, the NSSA ABR will convert the Type 7 LSA to Type 5 LSA and flooded in the area 0 and to the other areas in OSPF domain. If there are one or two NSSA ABRs, the NSSA ABR who has the highest router ID will be the one to do the translation.

LSA Type 8 is the Link Local LSA for OSPFv3 while LSA Type 9 – 11 are Opaque LSAs. These are OSPF LSA extensions used for MPLS traffic engineering. I haven’t tried to lab these LSA types but I will somehow in the future.