BGP Attributes and Path Selection

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.

Thanks,

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!

Laz

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.

BR
Hektor

Hello Hektor

Yes I stand corrected in my post. What I was referring to has to do with what route is actually installed in the routing table. The routing table sees eBGP and iBGP as two different routing protocols, and will always install eBGP-learned routes over iBGP-learned routes due to the fact that eBGP has an AD of 20 and iBGP an AD of 200.

However, when going through the attributes to determine the best path as shown in the BGP table, then yes, eBGP or iBGP are indeed 7th on the list of attributes. So the best path will first be determined using the attributes, and then will be given an AD based on whether it turns out that it’s an iBGP or eBGP learned route. And will then be compared with other routing sources to see if it will be installed in the routing table.

The problem in Carlos’ post may indeed be that the BGP process had to be cleared for the change to take effect.

Thanks for pointing that out!

Laz

Rene ,

Can please elaborate more on the following Path Selection Attribute

“Shortest IGP path to BGP next hop”

what IGP has to do with BGP Next-Hop Selection Process .

Hello Surendra

Unlike an IGP, BGP peers don’t have to be directly connected to each other in order to create a peering. They can be several hops away from each other. This is the case for iBGP by default. For eBGP, this can be configured, as you can see in the following lesson:


Within a BGP AS, all of the iBGP routers must be able to reach each other. This means that in order for BGP to function, you must have configured routing within the AS that allows the BGP routers to communicate with each other successfully. This routing can be achieved either via static routing, or via an IGP such as OSPF or EIGRP.

This is one of the confusing things about BGP. Why employ an IGP since you’re already using BGP? Well, you must view BGP as the protocol that primarily routes traffic from AS to AS, while IGP routes traffic within an AS. iBGP will share BGP routes between BGP peers within an AS, but the purpose of this is to inform BGP routers on the edge of the AS (those routers that create eBGP peerings with other AS’es) of the internal networks.

So to get to your question, the “shortest IGP path to BGP next hop” is one of the attributes used as a tie breaker. If you have two or more paths to a particular destination in the BGP table, and all previous attributes for these paths are equal, then the next thing that will be examined is the IGP cost (OSPF or EIGRP for example) to the next hop BGP router of each path.

I hope this has been helpful!

Laz

yes this is helpful
by the way what’s the rationale in having ORIGINATE attribute ?

Hello Surendra

The ORIGINATE attribute is one which prefers paths that were locally originated, that is, they have been learned either via the network or aggregate BGP commands in the local router itself, or through the redistribution of an IGP. Such paths are preferred over those that are learned via BGP from another neighbor.

Remember that BGP learns about paths to particular destinations via these specific sources (network, aggregate, or redistribution), and these sources exist on some router. It only makes sense then to consider routes sourced in such a way by the local router itself as more trustworthy than those learned from other BGP routers. Does that make sense?

I hope this has been helpful!

Laz

I need more clarification -

  • there are LOCAL routes - present in the same AS as the BGP Router
    and
  • Then there are remote Routes which are imported from other AS’es

Now , What role does the Network , Aggregate and Redistribute commands play when dealing with these two different types of Routes ???

Hello Surendra

This is going to be a bit of a long post, but I think it’s necessary to be as clear as possible, so bear with me… :sweat:

Let’s look at a single AS. Within the AS there is either static routing or an IGP that distributes routes among the routers within. The network has converged and all devices within the AS are able to reach all destinations within the AS. BGP plays no part in this.

Now imagine that around this AS, we have several other AS’es. Each AS is isolated from all the others and no static or IGP routing is learned from one AS to another. There must be a way to allow this to happen. This is where BGP comes in.

Within each AS you enable BGP on the routers. Routers within the AS peer with each other in a full mesh, and they don’t need to be directly connected (iBGP). Routers on the edge of the AS peer with routers on the edge of other AS’es and they need to be directly connected by default (eBGP).

Now with all of this configured, BGP will not yet share any routes! You must “inject” the routes into the BGP table. Once there they can be shared among BGP routers.

Routes will get into the BGP table in one of two ways. Either by being learned via BGP (from other BGP routers, either within the AS or from other AS’es) or by being manually added by using the network, aggregate, or redistribute commands.

When using the network command, you are essentially telling BGP “add this route” manually. The aggregate command works similarly. When using the redistribute command, you are telling BGP “add these routes leaned via another routing protocol” In all cases, there are conditions as to if it will actually be added to the BGP table or not, the primary one being that the specific destination should already be in the routing table.You can find out more about that in these lessons:


So you see, these commands actually add already learned (by the local router) destinations to the BGP table to be shared with other BGP routers, either iBGP or eBGP peers.

So to answer your question, the network aggregate and redistribute commands don’t have to do with routes learned from other BGP peers, either local or remote (iBGP or eBGP) but have to do with the action that actually adds prefixes to the BGP realm for sharing via BGP.

I hope this has been helpful!

Laz

Above statement needs little clarification . iBGP is able to add the IGP (OSPF/EIGRP ) routes within the AS routers to the AS border BGP Router Table for distribution to other AS’s. if iBGP is dynamically doing this without manual intervention why do we need to manually intervene and execute network , aggregate and redistribute commands ?

Hello Surendra

Like I said in my previous post, you can configure BGP on all routers in an AS, have peerings take place, and have them connect to other AS’es as well, but if there is nothing to advertise, no prefixes or routes will actually be exchanged.

Yes, iBGP is able to distribute these routes to other BGP routers and other AS’es, but how did those routes get there in the first place? How does BGP initially gain knowledge of particular routes? Only via the network, aggregate, or redistribute commands. IGPs will not automatically populate the BGP table just because they are there.

I hope this has been helpful!

Laz

Hi Guys,

Hope you are well? Just a quick one…

A router receives two advertisements, say one for 10.0.0.0/22 and one more specific for 10.0.0.0/24.

Would the less specific prefix of 10.0.0.0/22 ever be chosen as BGP best path if it had more favourable BGP attributes? Say a shorter AS_PATH?

Thanks,

Gareth.

Hello Gareth

No it would never be chosen. Remember that the attributes are used as “tie-breakers” for the choice of path for a particular prefix. The 10.0.0.0/22 and 10.0.0.0/24 destinations are considered to be different prefixes so the BGP attributes would never be used to distinguish between the two.

I hope this has been helpful!

Laz

Thanks Laz. Makes total sense.

Hello Rene and Team
Currently i have been reading BGP attributes notes but am little bit confused to these attributes ** local preference** and AS prepend the way are applied to inbound and outbound direction using route map
When you create a route map you actually apply your match weather to inbound direction or out-bond direction!! i don’t get a clear picture as to why for LOCA_PREF route map is applied in-bond and AS_PREPAND is applied outbound,

Hello Emanuel

Just a clarification. Local preference is a BGP attribute, but AS prepend is not an attribute itself, but it is a method used to manipulate the AS path length, which is an attribute.

Local preference is applied within an autonomous system and is used to choose the outbound eBGP path to a particular prefix. Local preference changes can be applied using route maps in an inbound or outbound direction, between BGP neighbours. Remember, the direction has to do with the BGP updates and not the traffic itself! For example, if you apply the following route map:

R3(config)#router bgp 2
R3(config-router)#neighbor 192.168.13.1 route-map LOCALPREF in

the changes made to the local preference attribute by the LOCALPREF route-map will be applied to all prefixes in BGP updates sent from this neighbour inbound to the local router.

You can find out more detailed information about the local preference attribute and how to manipulate it in the BGP Local Preference lesson.

The AS Path Length attribute on the other hand has to do with the length of the AS to a particular prefix. You can manipulate this attribute to adjust BGP path selection by using AS prepending. Like local preference, the AS Path Length can be adjusted by applying a route map to a neighbour. The same concept applies: the direction of application has to do with the direction of the BGP update and not the direction of the actual user traffic.

So, for example, if we have the following configuration:

R1(config)#router bgp 1
R1(config-router)#neighbor 192.168.12.2 route-map PREPEND out

then the changes made to the AS path that are configured in the PREPEND route map will be applied to all of the prefixes found within the BGP update that is being sent outbound to the specific BGP neighbour. In other words, this particular neighbour will receive a BGP update with prefixes that have an adjusted AS path, as per the PREPEND route map.

For more information about AS prepending, take a look at the BGP AS Path Prepending lesson.

I hope this has been helpful!

Laz

Within your BGP statement you have different neighbor routers; however, you want a particular network to go to a certain neighbor. Can prefix list help? Or does anyone know another simpler way?