BGP Attributes and BGP Path Selection

In this blog I will briefly review the BGP path selection algorithm used when deciding which BGP routes to install in the routing table. Though before doing so, I ought to review first the BGP attributes.


Firstly, we classify BGP attributes based on whether or not they should be supported within a specific vendor BGP implementation.

  1. Well-Known BGP attributes are supported in all BGP implementation regardless the vendor. Depending on whether or not these are sent with BGP Updates, we further classify them into:
    1. Mandatory attributes – these must be present in every single update where NLRIs are included;
    2. Discretionary attributes however, may or may not be present in the BGP updates
  2. Optional attributes do not have to be supported across all BGP implementations; some vendors may implement them, others, may not. When advertised, what happens to the attribute will depend on whether the attribute is –
    1. Transitive – in which case the value is preserved and the attribute is passed on to the next BGP neighbour;
    2. Non-Transitive – the attribute is removed from the BGP update before passing it on 


Now, let’s see how Path Selection is done as well as, what BGP attributes are used in the process:

  1. NEXT HOP – At first, the router will check whether the next-hop is reachable, either via IGP, or by means of static routes. Should the next-hop not be reachable, the route will not be considered any further. The NEXT-HOP is a well-known mandatory BGP attribute.
  2. WEIGHT / Non-Transitive – This is a Cisco proprietary, optional, non-transitive, locally-significant attribute. Upon a BGP update, the receiving router will set this attribute to 0 (zero); it will however set the weight to 32768 for all locally originated routes. In regards to path selection, the highest value will always be preferred.
  3. LOCAL PREFERENCE / Discretionary – it is included in BGP updates between iBGP peers only, hence, for routing purposes, it is only significant within the local AS. Over a eBGP session, this attribute will be reset to the default value of 100 and the highest value, will always be preferred. This attribute is used in outgoing routing policies – used to influence preference for outgoing traffic, but it’s only significant to the local router.
  4. Locally ORiginated – these are routes which show in the BGP table with the next-hop value set to (the local router!). All routes originated using the “network” , “redistribute” or “aggregate-address” commands will show as locally originated routes and they will always have a higher preference over the routes learnt from remote BGP peers.
  5. AS Path / Mandatoryrepresents an array of different Autonomous Systems identifying the BGP update path taken thus far. Apart from very specific/special cases, the AS_PATH attribute will not be updated over iBGP sessions; it is however included in every BGP update and it must be accepted accordingly. The AS_PATH is also the main BGP mechanism for loop avoidance – upon receiving a BGP update, if the receiving AS finds itself in the AS_PATH, it discards the update. This attribute is also used in inbound and outbound routing policies – e.g. prepending AS numbers to the AS_PATH we can make a route more preferred for a specific prefix.
  6. ORigin Code / Mandatorythis indicates where the route originally originated from; not necessarily where is advertised from – a very important distinction! This attribute could, in theory, have three values: “i” (internal),e” (EGP) and “?” (unknown). Though in practice, we will not see EGP as origin as this is a protocol no longer in use. Redistributed routes will always show as “unknown” whereas routes originated via the network command, will show as “internal” routes
  7. Multi Exit Discriminator (MED)/ Non-transitive – this attribute translates to the BGP route metric – the lowest value, will always be preferred. By default, MED is always set to zero, unless the route is known via redistribution from IGP – in this case, the IGP metric will be carried into MED. The MED is normally manually set on routes advertised out to eBGP peers in an attempt to influence preference of incoming traffic – of course, this assumes that the attribute is implemented at the remote end
  8. External Paths over Internal Paths – routes learnt from eBGP neighbours will always be preferred over those learnt from iBGP peers; to reinforce this rule, by default, eBGP administrative distance is set to 20, unlike iBGP’s, which is set to 200.
  9. Router ID (RID) – at last, the router with the lower Router ID will be considered as the next-hop to reach the destination network.

I am sure you’ve noticed the highlighted, blue letters… These, will help us never again forget the BGP Path Selection algorithm, by simply trying to remember the following mnemonic:


We Love Oranges AS Oranges Mean Pure Refreshment

Now, every time you will be enjoying a nice orange juice, BGP will also come to your mind!


Thank you,

Rafael A. Couto Cabral • LinkedIn Profile
Cisco​ | F5 | VMware Certified • PRINCE2 Practitioner

Originally posted 2019-07-27 00:39:23.

Related Post

Leave a Reply