OECG – Chapter 13


This next section goes into detail describing how you can influence each of the decision steps BGP follows to choose a best route.

NEXT_HOP Reachable

  • Generally, you don’t use a routing policy to impact the next hop. The next hop is what it is, and in the context of a BGP routing decision, that next hop is reachable or it isn’t.
  • Tweakable with the “neighbor <id> next-hop-self” command – this is the default for eBGP peers.
  • Tweakable with the “neighbor <id> next-hop-unchanged” command – the default for iBGP peers.
  • For iBGP peers, understand that “next-hop-self” is only effective on border routers (a router with an eBGP peer).  While you can set “next-hop-self” on a iBGP-only router, the next-hop attribute will not be impacted for advertised routes.

Administrative Weight

  • Remember that this is a Cisco proprietary feature. The weight of a BGP route is not something that will be passed to other routers, as there is no place in a BGP update message for this.  Weight is locally significant only!
  • Larger values are preferred.
  • Tweakable with the “neighbor route-map in” or the “neighbor weight” command (with the route-map winning if you’re using both and they both match an NLRI).
  • Locally generated routes have a default weight of 32768.

Highest Local Preference (LOCAL_PREF)

  • The local preference PA holds a numeric value between 0 and 2 to the 32 – 1 (4,294,967,295).
  • This preference is “local” in the context of an ASN. If you have more than one way out of an ASN, you can express a preference local to that ASN for a particular NLRI. That way, as the eBGP router sees an update from a neighbor he’s supposed be the preferred exit for, he’ll populate the LOCAL_PREF PA with a high number before sending the update to iBGP peers.
  • Tweakable with the “bgp default local-preference <number>” command.
  • Tweakable with the “neighbor route-map” command, where you’re using “in” to tag updates coming from a specific neighbor. In the route-map, you would match an address via an ACL, and then “set local-preference <number>”.

ORIGIN PA: Choose Between Locally Injected Routes

  • The book makes the point that this particular step is rarely going to be different from what happens in the “Administrative Weight” decision. Locally injected routes always get a weight of 32,768, and so are preferred over other injection methods.
  • In other circumstances, you may end up with the route injected locally via multiple methods. In that case, this step will prefer “i” routes (injected via an IGP) over “e” (injected via EGP) over “?”

Shortest AS_PATH

  • The smallest number of ASNs in the AS_PATH PA will win.
  • Tweakable: if the AS_SET is populated, it will count as a single ASN, no matter how many ASNs may be listed (remember that they are not sequential in this field, but rather just a generic list used by aggregate routes).
  • Not tweakable, but important to know: confederations are not regarded.
  • Tweakable: the aggregate-address has a bearing on things. If the subnets within the aggregate have different AS_PATHs, then the summary route only has the local AS in AS_SEQ. If the subnets within the aggregate have identical AS_PATHs, then AS_SEQ will contain the AS_SEQ from those subnets. AS_SET may or may not be populated, depending in part on whether or not the as-set command option is used.
  • Tweakable: the “neighbor remove-private-as” command will strip off private ASNs (64512 – 65535) from BGP updates coming from the neighbor in the private ASN.
  • Tweakable: the “neighbor local-as {no-prepend}” command will allow a router to send an update with an ASN other than his own. If you use the no-prepend, then no ASN is stuck on the front of the existing path before sending the BGP update off to neighbors.
  • Tweakable: sort of the opposite of the entry above, you can prepend ASNs to make a particular update appear to have a longer ASN path using “neighbor route-map” with a “set as-path prepend” command.
  • Tweakable: you can tell the router to not take AS_PATH into consideration by using the “bgp bestpath as-path ignore” command.


  • “i” is preferred over “e” is preferred over “?”. Some notes on this follow.
  • EGP should never be seen today. You couldn’t turn EGP on in an IOS router even if you wanted to…the support isn’t there. So, taking EGP (“e”) ORIGINs out of your mind simplifies things a bit.
  • Tweakable: you can artificially manipulate the origin code using a “set origin” command in a route-map.

Smallest Multi-Exit Discriminator (MED)

  • Conceptually, MED functions like a metric, where a smaller number is preferred. All other things thus far being equal, a route with the smallest MED will be preferred. In a scenario where you are dual-homed to a single ISP, the ISP might advertise some NLRIs to you with a smaller MED, so that you prefer one connection over the other for those NLRIs.
  • Tweakable: via “neighbor route-map out” you can “set metric” to manipulate the MED.
  • Tweakable: the default router behavior is to ignore MED when the 2 identical NLRIs were learned from different ASNs. This is because 2 ISPs aren’t likely to be setting MEDs in such a way that they’d make sense to your edge router(s). But you can still include the comparison if you want, using the “bgp always-compare-med” command.
  • Tweakable: MED-based decisions may be impacted by the order of the BGP entries in the table. You can overcome this comparison logic shortcoming by using the “bgp deterministic-med” command.
  • Remember that MED is advertised from one ASN to another, but the MED is not carried beyond the ASN it was advertised to. So it will live from 1 eBGP update through iBGP updates within an ASN. But the ASN that received it will not forward it on to any other ASNs.

Prefer eBGP over iBGP

  • There’s nothing to tweak here, but if the BGP decision process has made it this far, an eBGP route will be chosen over an iBGP route for an NLRI.

Smallest IGP Metric to the NEXT_HOP

  • Just like it says, if the BGP decision process makes it here, the router will compare the IGP (OSPF, EIGRP, etc.) metric to the next hop advertise, and pick the lower one.

The Lowest RID of Advertising Router

  • Compare the lowest RID of the eBGP routers, assuming eBGP routes were learned.
  • Compare the lowest RID of the iBGP routers, assuming iBGP routes were learned.
  • If there’s already a “best” route, but the router learned a new route and the comparison gets to this step, don’t replace the already known eBGP route with the new route even if the RID is lower. The idea of this exception is to prevent route flaps. (In the case of iBGP, RID will still take precedence.)
  • Tweakable: you can override the above default known eBGP route-replacement behavior with the “bgp bestpath compare-routerid”.

Lowest Neighbor ID

  • If the above doesn’t return a “best”, then you would determine based on the local router’s neighbor-id. Lowest one wins.

BGP “maximum-paths”

  • A BGP router will consider adding multiple eBGP paths in the following circumstances:
    • BGP must have gotten to the “lowest RID” or “lowest neighbor ID” decision steps.
    • “maximum-paths” must be greater than 1.
    • Adjacent ASNs must be the same to be considered as candidates for a given NLRI.
    • If there are more possible routes than allowed “maximum-paths”, then the lowest RID/lowest neighbor ID steps will determine who’s to win.
  • A BGP router will consider adding multiple iBGP paths in the following circumstances:
    • Same as above – lowest RID/neighbor ID must have been reached in the decision process.
    • “maximum paths ibgp” must be greater than 1.
    • Only iBGP routers with different NEXT_HOPs are candidates.
    • Same as above, if there are more possible routes than allowed “maximum-paths”, then the lowest RID/lowest neighbor ID steps will determine who’s to win.

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.