BGP Attributes and Path Selection

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.

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


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!


Hi Laz,

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

1 Like

Hello Rene, Laz-

Can you also add Accumulated Interior Gateway Protocol (AIGP) ? I found this one in ENCOR 350-401 cisco press book in BGP best path overview and difficult to understand.

Thank you.

1 Like

Hello Rupak.

For sure. Once it’s live, I’ll leave a comment here.


1 Like

Hi Rene,

In case of a router receives a route with a local preference of 150 and receives the same route from a external peer. How will this router compare these routes by using the Local Preference? I have checked a BGP table and the Local Preference field of external routes (eBGP) are in blank.


Hello Leandro

Although it is true that local preference is only shared among iBGP routers, any route that is received via eBGP will have a default local preference value of 100. The fact that the attribute is not shared between eBGP routers doesn’t mean that it doesn’t actually exist as an attribute from such routes.

I hope this has been helpful!


Did you tried to clear the bgp process after changing the weight?
Most probably you were checking the routing table before the new BGP updates.

Please try "clear ip bgp xxxxx (as number) "
and check again.

Thank you so much, Lazaros!

It helped a lot!

1 Like

Iagapides, please allow me to disagree with this. What you are saying it is most likely applying to other vendors like aruba for example. Cisco routers are not considering iBGP and eBGP as different routing protocols, you can easily understand this just by checking attribute number 7 from the path selection algorithm where it is stated that eBGP routes are preferred over iBGP routes. If eBGP and iBGP would be considered as different routing protocols we would not have this attribute in the path selection algorithm or at least we would have it as number 1 attribute in order to be a “tie breaker”. If you have a different opinion in this I would be more than happy to discuss this with you.