Skip to content
Log in Sign up My account

1.11.c Path Attributes and Best Path

Blueprint 1.11: Troubleshoot BGP (Interior and External)

  • 1.11.c Path preference (attributes and best-path)

The question is always the same: given two or more paths in show ip bgp, which one wins and why, and why did the one you wanted lose? To answer it you need the attributes, their defaults and scope, and the exact order of the comparison.

Path attributes

Attribute Category Default Better is Travels Typical use
Weight Cisco only, not a real attribute 0 for learned paths, 32768 for locally originated Higher Never leaves the router Override on one router
LOCAL_PREF Well-known discretionary 100 Higher Inside the AS only (iBGP) Choose the exit point for the whole AS
AS_PATH Well-known mandatory Each eBGP hop prepends its AS Shorter Everywhere Loop prevention; prepending influences inbound traffic
ORIGIN Well-known mandatory i for network/aggregate, ? for redistribute IGP i < EGP e < incomplete ? Everywhere Rarely manipulated
MULTI_EXIT_DISC (MED) Optional non-transitive 0, and a missing MED counts as 0 Lower To the neighboring AS, which does not pass it on Tell a neighbor AS which of your links to use
NEXT_HOP Well-known mandatory See next hop rules Must be reachable Everywhere Not compared, but must resolve
COMMUNITY Optional transitive None; IOS sends only with send-community Not compared Where sent Tagging for policy
ORIGINATOR_ID, CLUSTER_LIST Optional non-transitive Added by a route reflector Shorter cluster list wins a late tie Inside the AS Route reflector loop prevention

Well-known attributes must be understood by every BGP implementation; mandatory ones must be in every update. Optional transitive attributes are passed on even by routers that do not understand them; optional non-transitive ones are dropped if not understood.

graph LR
  subgraph AS65010["AS 65010"]
    R2["R2<br/>weight: this router only"] -- "iBGP: LOCAL_PREF shared" --- R1["R1"]
  end
  R2 -- "eBGP: MED sent to AS 65001 only" --- ISP["AS 65001"]
  ISP -- "AS_PATH and ORIGIN go everywhere" --- NET["Rest of the Internet"]

The best-path algorithm on IOS

Paths are compared two at a time. The first step that produces a difference decides; later steps are never reached.

Step Prefer Notes
0 Paths with a reachable next hop (and, if synchronization is on, synchronized) Everything else is not a candidate at all
1 Highest weight Local to the router
2 Highest local preference Default 100, change with bgp default local-preference
3 Locally originated (network, redistribute, aggregate) Local paths beat learned ones
4 Lowest AIGP metric, if AIGP is in use Normally not configured; skip it in exam answers unless shown
5 Shortest AS_PATH An AS_SET counts as one; bgp bestpath as-path ignore skips the step
6 Lowest origin i beats e beats ?
7 Lowest MED Only between paths from the same neighboring AS, unless bgp always-compare-med
8 eBGP over iBGP
9 Lowest IGP metric to the next hop The (metric N) value in show ip bgp <prefix>
10 Multipath If maximum-paths allows it, equal paths are installed together; the algorithm still picks one best for advertising
11 Oldest path, when both are eBGP Stability: avoids flapping. Skipped with bgp bestpath compare-routerid
12 Lowest router ID of the advertising router For a reflected path, the ORIGINATOR_ID is used instead
13 Shortest cluster list Reflected paths only
14 Lowest neighbor address The final tie breaker

A common memory aid is N WLLA OMNI: Next hop, Weight, Local preference, Locally originated, AS path, Origin, MED, Neighbor type (eBGP over iBGP), IGP metric. After that come the tie breakers: oldest eBGP, router ID, cluster list, neighbor address. The diagram library has the same list as a flowchart: N16.

Exam trap

Higher is better for weight and local preference. Lower is better for AS path length, origin, MED, IGP metric, router ID and neighbor address. Questions love to show a path with a MED of 0 and another with a MED of 50, and then make local preference or AS path decide first.

MED details that cause wrong answers

  • MED is compared only when both paths come from the same neighboring AS (the first AS in the AS path). Paths from AS 65001 and AS 65002 skip step 7 entirely.
  • A missing MED is treated as 0, which is the best possible value. bgp bestpath med missing-as-worst treats it as the worst value instead.
  • bgp always-compare-med compares MED across different neighbor ASes. Configure it on every router in the AS or none, or routers can disagree and loop traffic.
  • bgp deterministic-med groups paths by neighbor AS before comparing, so the result does not depend on the order paths arrived. Recommended when MED is used.
  • MED is sent to an eBGP neighbor and is passed to that AS's iBGP peers, but that AS does not pass it on to a third AS.

Weight and local preference scope

Weight is the only knob that affects just one router. Local preference affects every router in the AS, because it is carried in iBGP updates. That is the whole difference in exam terms:

Requirement Use
"R3 only must prefer the path through R5" Weight on R3
"All routers in the AS must leave through ISP-A" Local preference on the router that peers with ISP-A, inbound
"ISP-A must send traffic for our prefix over link 1, not link 2" (two links to the same ISP) MED, outbound to ISP-A
"The rest of the Internet must prefer ISP-A for our prefix" AS-path prepend outbound to ISP-B

Reading the BGP table

R1# show ip bgp
BGP table version is 9, local router ID is 10.255.255.1
Status codes: s suppressed, d damped, h history, * valid, > best, i - internal,
              r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter,
              x best-external, a additional-path, c RIB-compressed,
Origin codes: i - IGP, e - EGP, ? - incomplete

     Network          Next Hop            Metric LocPrf Weight Path
 *>  192.0.2.0        0.0.0.0                  0         32768 i
 *>i 198.51.100.0     10.255.255.2             0    100      0 65001 i
 * i 203.0.113.0      10.255.255.3             0    100      0 65002 i
 *>i                  10.255.255.2             0    100      0 65001 i
Column or code Meaning
* Valid: the path passed the next-hop check
> Best path, the one installed and advertised
i after the status Learned from an iBGP peer
r RIB-failure: best in BGP but not installed, normally because a lower-AD route exists
m Multipath: installed alongside the best path
Metric MED
LocPrf Local preference. Often blank for eBGP-learned and locally originated paths, which still use the default of 100 in the comparison
Weight 32768 for locally originated, 0 by default otherwise
Path AS path, nearest AS first, then the origin code

The detailed view tells you which path won. It does not tell you which step decided, so you work that out by comparing attributes in algorithm order.

R1# show ip bgp 203.0.113.0
BGP routing table entry for 203.0.113.0/24, version 7
Paths: (2 available, best #2, table default)
  Advertised to update-groups:
     1
  Refresh Epoch 1
  65002, (Received from a RR-client)
    10.255.255.3 (metric 2) from 10.255.255.3 (10.255.255.3)
      Origin IGP, metric 0, localpref 100, valid, internal
  Refresh Epoch 1
  65001, (Received from a RR-client)
    10.255.255.2 (metric 2) from 10.255.255.2 (10.255.255.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best

Walk it: weight 0 for both, local preference 100 for both, neither is local, AS path length 1 for both, origin IGP for both, MED is not compared (65002 and 65001 are different neighbor ASes), both iBGP, IGP metric 2 for both, not eBGP so the oldest-path rule does not apply, router ID 10.255.255.2 is lower than 10.255.255.3. Step 12 decides.

RIB-failure

A path can be best in BGP and still not be used for forwarding. If the routing table already has the same prefix from a source with a lower administrative distance (a static route at 1, OSPF at 110, versus iBGP at 200), the BGP route is flagged r and is not installed.

R3# show ip bgp rib-failure
  Network            Next Hop                      RIB-failure   RIB-NH Matches
198.51.100.0/24    10.255.255.2        Higher admin distance              n/a

By default IOS still advertises a RIB-failure route to its peers, so the router can attract traffic it then forwards using the other route. bgp suppress-inactive stops advertising such routes.

Exam trap

An r code is not a BGP fault. The BGP part is working; something else has a better administrative distance. The fix is to remove or change the other route (or its distance), not to change BGP attributes, which only decide between BGP paths.

Multipath

By default BGP installs one path. maximum-paths 2 (eBGP) or maximum-paths ibgp 2 lets the router install several, but only if they tie on every step up to and including the IGP metric: same weight, local preference, AS path length and content, origin, MED and IGP metric, and the same neighbor type. Paths that tie except for the AS path content (different neighboring AS) are not used together unless you configure bgp bestpath as-path multipath-relax. Multipath paths show the m code.

Diagnostic workflow for "traffic takes the wrong exit"

graph TB
  S["Wrong exit for prefix P"] --> A["show ip route P<br/>Is it BGP? Which next hop?"]
  A -->|"not BGP, or r code"| B["Other source wins on AD<br/>remove or fix it"]
  A -->|"BGP"| C["show ip bgp P<br/>list every path"]
  C --> D["Compare in order:<br/>weight, local pref, local, AS path,<br/>origin, MED, eBGP, IGP metric"]
  D --> E["First difference found"]
  E --> F["Where was that attribute set?<br/>route-map, neighbor weight, default"]
  1. Confirm the forwarding decision with show ip route and, if needed, traceroute.
  2. List every path with show ip bgp <prefix>. If the path you want is missing, it is a filtering or advertising problem, not a best-path problem.
  3. Walk the attributes in order. Note the first one that differs.
  4. Find where that value came from: show run | section router bgp for neighbor weight, show route-map for set clauses and their match counters, show ip bgp neighbors <ip> | include route map for what is attached.

Exam trap

A weight set with neighbor x weight on one router beats a local preference policy that the rest of the AS follows. If one router ignores the company exit policy and the rest obey it, look for weight on that router first.

Lab: walk the algorithm and fix ticket 7

Topology: the module topology with the baseline from the Sessions lab.

In the baseline, R1 sees two paths to 203.0.113.0/24 and chooses the one from R2 at step 12 (router ID). Each step below changes one input so that a different step decides. Undo each change before the next one.

  1. IGP metric (step 9). On R1, interface GigabitEthernet0/0 then ip ospf cost 10. Now show ip bgp 203.0.113.0 shows 10.255.255.2 (metric 11) and the R3 path is best. Undo with no ip ospf cost.
  2. MED is skipped between different ASes (step 7). On R4 create route-map SET-MED permit 10 with set metric 50, attach it with neighbor 10.2.4.1 route-map SET-MED out and run clear ip bgp 10.2.4.1 soft out. On R1 the R2 path now shows metric 50, but it is still best: 65001 and 65002 are different neighbor ASes, so MED is not compared, and router ID still decides.
  3. always-compare-med. On R1 add bgp always-compare-med. The R3 path (MED 0) now wins at step 7. Remove the command and the route-map on R4 afterwards. In production you would configure this on every router in the AS or none.
  4. Weight (step 1). On R1, neighbor 10.255.255.3 weight 100 and clear ip bgp 10.255.255.3 soft in. The R3 path wins with Weight 100. Check R3 and R2: their own decisions do not change, because weight never leaves R1. Remove it.
  5. Local preference (step 2). You will set it with a route-map on the Policies page.
Fault injection, ticket 7 
! R3
ip route 198.51.100.0 255.255.255.0 Null0

Ticket 7

"Users behind R3 cannot reach 198.51.100.0/24. Head office users can. R3's BGP table looks correct."

Ticket 7: root cause and fix

On R3, show ip bgp shows the prefix with an r code:

R3# show ip bgp | include 198.51
 r>i 198.51.100.0     10.255.255.2             0    100      0 65001 i
R3# show ip route 198.51.100.0
Routing entry for 198.51.100.0/24
  Known via "static", distance 1, metric 0 (connected)
  ...
  * directly connected, via Null0

BGP is fine: the path is valid and best. The static route to Null0, left over from a test, has distance 1 and beats iBGP at 200, so R3 drops the traffic. show ip bgp rib-failure confirms "Higher admin distance". Fix: no ip route 198.51.100.0 255.255.255.0 Null0. The r disappears and show ip route 198.51.100.0 shows Known via "bgp 65010", distance 200.

Quick check

Two eBGP paths to the same prefix tie through the IGP metric step. One was received 2 hours ago from router ID 10.9.9.9; the other 5 minutes ago from router ID 10.1.1.1. Which wins on default IOS?

The older path (2 hours, from 10.9.9.9). For two eBGP paths IOS prefers the oldest before comparing router IDs, unless bgp bestpath compare-routerid is configured.

Path A: weight 0, local preference 150, AS path 65001 65002 65003. Path B: weight 0, local preference 100, AS path 65004. Which wins?

Path A. Local preference (step 2) is compared before AS path length (step 5), and 150 beats 100.

A prefix shows *>i in BGP, but show ip route lists it as an OSPF route. Why, and should you change BGP?

OSPF (AD 110) beats iBGP (AD 200), so the BGP route is not installed; it would also show an r code. Do not change BGP attributes: they only rank BGP paths against each other. Fix the OSPF side or the administrative distance if the OSPF route is wrong.

References

  • "BGP Best Path Selection Algorithm", Cisco tech note (search on cisco.com for "BGP best path selection algorithm")
  • IP Routing: BGP Configuration Guide, Cisco IOS XE: "BGP Path Selection" and multipath chapters (search on cisco.com)
  • RFC 4271 (BGP-4, attributes and decision process), RFC 4451 (MED considerations), at rfc-editor.org
  • Cisco Live On-Demand Library: search "BGP path selection"