BGP Attributes and Path Selection

This topic is to discuss the following lesson:

Hi René,
good lesson i read in detail
I am not a BGP expert as i am studying now (only) for CCNP
I read other sources for description of attributes (i dont know if i may give this source name)
This (well known) source give 2 more attributes

  • the first one between 8 (Shortest IGP path to BGP next hop) and 9 (Oldest Path) he call “Multipath”: determines wether or not multiple paths need to be injected into the routing table, and continues if the best path is not yet selected.
  • the second between 10 (router-id) and 11(neighbor IP address) he call “Minimum Cluster List Length”: a tie breaker used in a route reflector BGP configuration that prefers the route with the minimum cluster list length
    Do you think you should add these attributes in your list ?
    Thank you
    Best regards

Hello Dominique

Looking at Cisco’s official BGP documentation whose link is below, it does indeed include these two attributes that you mention. I’ll let Rene take a look and see if those should be added as well.

Thanks for pointing that out!

Laz

thanks very much Laz

1 Like

Hi Dominique,

The link @lagapides added is the most complete list of BGP attributes and the path selection:

I didn’t include multipath because by default, it’s not enabled in BGP. Internal and external BGP only install a single best path (unless you enable multipath). If you do use multipath, it’s good to know how BGP deals with it.

The minimum cluster list length is a similar example. It only applies when you use BGP route reflectors. There are also some exceptions when you use BGP confederations.

I’ll add a note in the lesson that explains these possible extra steps. I don’t want to confuse people new to BGP too much with the terminology that is a bit more advanced level :grin:

Rene

Hi Rene
I configure IBGP and EBGP to practice the path selection, I got a problem


Here in network to 8.8.8.8 the best path is through 192.168.111.3 (EBGP neighboor) even I changed Weight to 400 in IBGP neighboor (192.168.12.2) the path still is over EBGP. I wanted to influence that best path to 8.8.8.8 was 192.168.12.2 and not 192.168.111.3, I don´t know whatI am doing wrong. I am using GNS3 and GNS3 VM

Hello Carlo

When configuring attributes such as weight (or any attributes in BGP), you must keep in mind that they affect the choice of route based on the same routing protocol. A router will consider iBGP and eBGP as two separate routing protocols. For example, if you have two routes to 8.8.8.8 via iBGP, then the weight can be used to force the router to route via one path and not the other. If you have one route via iBGP and the other via eBGP, the weight will not affect the choice. It’s like trying to make the router choose a path via iBGP and not via EIGRP by using the weight attribute. It won’t work.

What the router does use, before any of these attributes, is the Administrative Distance. Since it views eBGP and iBGP as two different routing protocols, the router will always choose to use eBGP over iBGP because it’s AD is 20 as opposed to 200.

I hope this has been helpful!

Laz

1 Like

I just finished reading articles on : AS Path, MED, Weight, Local preference, Origin. I found there big room for clarification.

  1. It would be helpful to explain how attributes can be used in typical BGP architectures : https://networklessons.com/bgp/singledual-homed-and-multi-homed-designs. Then ; routers should be named ISP1, ISP2, Enterprise, PE, CE, etc.

  2. Most of the articles start with a schema explaining the attribute. But ; configuration is based on a second schema, which is completely different. It’s confusing !

Hello Maodo,

I’ll add this to my list to update. I agree it’s better to use a single topology (if possible) to explain + configure something.

This is something I’ll have to think about. There are so many possible options/possibilities/designs.

Rene

Hi Guys,

Am I correct in saying that the Originate attribute is also referenced in the Origin Code attribute?

Why reference the same thing twice?

Thanks,

Gareth.

Hello Gareth

The Originate attribute compares prefixes based on if they have originated on the local router. Specifically, if a route is learned via a network or aggregate BGP subcommand on the local router, or through redistribution from an IGP again on the local router, then it is preferred over prefixes learned from other BGP routers.

The Origin type attribute has to do with if the path was learned via IGP, EGP, or if it has been redistributed into BGP (incomplete). This is more thoroughly described in the following lesson.

Now these two might seem similar, but remember, that the Originate attribute is looked at first. If that attribute is the same between two candidate routes, then we go on to the next attribute in the list. It is possible for two prefixes to be “tied” when the originate attribute is examined, but that tie can be broken at the origin type attribute.

I hope this has been helpful!

Laz

Thanks Laz,

So during path selection the Originate attribute favours a route if the next hop is 0.0.0.0 while the Origin attribute compares IGP, EGP and Incomplete in the event of a tie break?

Is Originate considered a BGP path attribute? I cant seem to find it in the RFC 1771?

Hello Gareth,

This is correct, router is going to prefer locally originated route. Locally originated route has next hop of 0.0.0.0, because you originated it locally, for example using network command. It is not contained within BGP Update, but local BGP process is going to use it in path decision.

Origin code can contain values from 0 to 2, lower is prefered:

  • 0 = IGP, shows as “i”, you gonna see it for example when you use network command to advertise the route.
  • 1 = EGP, shows as “e”, this refers to EGP old routing protocol, you cannot see it anymore, RFC904.
  • 2 = Incomplete, shows as “?” and means this prefix was redistributed into BGP.

Origin code is contained within BGP update.
In case where Origin code is not a tie breaker you simply continue to next attribute, which is MED, if MED is not a tiebreaker you continue to iBGP vs eBGP and so on…

Thanks Michal - so if Originate isn’t listed in the RFC as an attribute - is it safe to assume that it isn’t an attribute?

“Originate” is not an attribute itself, but it is tied to next_hop and next_hop is well-known mandatory attribute. Well-known means it has to be recognized by all BGP speaking routers and mandatory means it needs to be included in every BGP Update.

Hi Community,

I’ve a doubt regarding the “weight” and “originate” attributes, If every locally originated prefix gets a weight of 32768, the weight will always be the first attribute to be evaluated, so what exactly is the use of “originate”.

Thanks!!

Hello Shashidhar

The default behaviour of BGP on Cisco devices is to assign a weight of 32768 to locally generated prefixes. As you suggest, this will cause any locally generated prefixes to automatically be preferred using the weight attribute. This means that the originate attribute for such situations would never be evaluated, and one can argue, that it may not even be needed.

First of all, this behaviour speeds up the BGP process. If the tie breaker between two prefixes is the originate attribute, you will not need to evaluate the weight, local preference, and the originate attributes to determine this. The router will determine this simply by looking at the weight attribute, making two additional evaluations unnecessary. In such a situation, you are correct that the originate attribute will never be used.

However, keep in mind that this is simply the default behaviour. You are able to change this if you like, and have the originate attribute make the decision. Note also that that the weight attribute is a Cisco proprietary attribute and has been added to locally adjust BGP routing in a simple way. The official definition of BGP does not include this, and thus for non-Cisco devices, the originate attribute will always be used.

I hope this has been helpful!

Laz

Hi Laz,

Yeah, that makes sense.
Thanks for the quick reply.

1 Like