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!


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:


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

Here in network to the best path is through (EBGP neighboor) even I changed Weight to 400 in IBGP neighboor ( the path still is over EBGP. I wanted to influence that best path to was and not, 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 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!


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 : 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.


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?



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!


Thanks Laz,

So during path selection the Originate attribute favours a route if the next hop is 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, 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.