OECG – Chapter 13


The next section covers various BGP path attributes (PAs), including their types and the more common PAs you’re likely to run into. Then the BGP routing decision process is outlined.

PAs are generally described in 2 ways – “well known” or “optional”.

  • Well known PAs are expected to be understood by any device running BGP. Well-known PAs can be classified as either mandatory (required in every BGP update) or discretionary (not required). Discretionary PA isn’t about the ability of a particular router to comprehend the PA, but rather notes that not all routers will populate the discretionary PAs unless they have a reason to do so.
  • Optional PAs are not necessarily supported by all BGP implementations. Optional PAs are classified as either transitive or nontransitive, indicating what the router is to do with the PA if it does not understand it. The router will forward optional transitive PAs in his BGP updates. The router will NOT forward optional nontransitive PAs.

There are a number of common PAs worth reviewing:

  • AS_PATH – well-known mandatory. ASNs that the NLRI has traversed.
  • NEXT_HOP – well-known mandatory. The IP address where traffic for this NLRI should be forwarded.
  • AGGREGATOR – optional transitive. Contains the ASN and RID of the router that made the summary route.
  • ATOMIC_AGGREGATE – well-known discretionary. If the NLRI is a summary, tag this PA.  It implies that some AS path information is hidden, if component routes that are a part of an aggregate route have varying AS paths.  Using “as-set” on an aggregate address removes this attribute, leaving the summary NLRI instead with all participating AS numbers inside of curly brackets – { }.  This is sometimes necessary as a loop-prevention mechanism.
  • ORIGIN – well-known mandatory. Tells how the route was injected into BGP…either “i” for IGP, “e” for EGP or ? for incomplete information.
  • ORIGINATOR_ID – optional nontransitive. Route reflectors use this PA to track the RID of the iBGP neighbor that injected the prefix into the AS
  • CLUSTER_LIST – optional nontransitive. Route reflectors use this PA to list the cluster IDs, which is a loop-prevention mechanism.

The BGP decision process is a complicated process that’s not readily intuitive. The decision being made by BGP is what NLRI will be considered “best” when considering multiple routes to reach a specific NLRI. To determine this, BGP doesn’t use a metric, as such. It rather follows a decision tree as follows:

  1. Highest administrative weight. This is a Cisco proprietary feature. You can assign the administrative weight to an NLRI locally on a router. This value is not communicated to another router. The higher the value, the better the route.
  2. Highest LOCAL_PREF PA. LOCAL_PREF is an optional, nontransitive PA that can be set within an AS, and used inside of the AS. This guides all routers in an AS to an identical egress router within the AS for a specific NLRI. The higher, the better.
  3. Locally injected routes – BGP will choose a locally injected route over others. If there are multiple locally injected routes, ORIGIN “i” routes are better than “e” routes which are better than “?” routes.
  4. Shortest AS_PATH length – the shorter the length, the better. Confederation information is ignored (AS_CONFED_SET and AS_CONFED_SEQ). AS_SET values are treated as 1 ASN, even if several ASNs are found in the AS_SET. In AS_SEQUENCE, each ASN counts as 1.
  5. ORIGIN PA – IGP routes are preferred over EGP routes which are preferred over incomplete labeled routes.
  6. Smallest Multi-Exit Discriminator (MED) PA – the smaller, the better. Often used so that an ISP with 2 links to the same customer can prefer one connection over the other for certain NLRIs.
  7. Neighbor type – eBGP routes are preferred over iBGP routes. (Confederation eBGP are considered as iBGP in this context.)
  8. IGP metric to reach the NEXT_HOP – the lower the IGP metric to reach the next hop, the better the route.
  9. Is the NEXT_HOP reachable? The book puts this on first as step “0”, and then really hedges on whether or not this is an actual step. The bottom line is that an NLRI that comes in without a reachable NEXT_HOP should be rejected. Of course, that’s true whether there are other potential routes to that NLRI or not.

The steps above are trying to find The One Route. They aren’t trying to put multiple routes for the same NLRI in the routing table. Rather, it’s a quest for The One Route. Understand that each step is considered in order, by itself. If step 1 doesn’t result in a best route, the router will move on to step 2. Also consider that the BGP decision process doesn’t eliminate candidate route to “thin the herd” while working through the routing process. If there’s 4 candidate routes for an NLRI, and step 1 doesn’t come up with “best”, all 4 candidate routes will then be considered by step 2, even if step 1 may have eliminated 2 out of 4 in its own context.

So let’s say we still don’t have a winner after the 9 steps above. Then what?

  1. Smallest advertising eBGP RID (or iBGP RID, if the candidate routes are all iBGP learned).
  2. Smallest neighbor ID. If the step above doesn’t come up with a best, that implies that the router had multiple connections to the same advertising router, and thus sees the same BGP RID in the updates. Therefore, the router will determine a best be using the smallest neighbor IP.

So what about this “maximum-paths” ability that BGP has? Well, BGP will only consider putting multiple routes into the routing table if he makes it all the way through the first 9 steps without a “best”. Even if multiple routes to hit the routing table, BGP will still only consider one route to be “best” and will only send that “best” in his updates to neighbors.

About the author

Ethan Banks

Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.


Most people know me because I write & podcast about IT on the Packet Pushers network. I also co-authored "Computer Networks Problems & Solutions" with Russ White.

Find out more on my about page.

Subscribe via Email

Receive complete, ad-free posts in your inbox as I publish them here.