When a BGP speaker holds several paths to the same prefix, in what order does it compare them to select one best path?
answer
- eligibility before comparison
- preference, then path, then origin
- MED only within one neighbouring AS
- eBGP over iBGP, then interior cost
- identifiers break the last tie
basics
~20 sUnusable paths go first (unresolvable NEXT_HOP, own AS in AS_PATH). Then: highest LOCAL_PREF, shortest AS_PATH, lowest ORIGIN, lowest MED from one neighbouring AS, eBGP over iBGP, lowest IGP cost to NEXT_HOP, lowest BGP Identifier, lowest peer address.
solid answer
~40 sRFC 4271 §9.1 first drops ineligible paths: one whose `NEXT_HOP` cannot be resolved MUST be excluded, and one whose `AS_PATH` contains the local AS should be. Among the rest the highest degree of preference wins (`LOCAL_PREF` for iBGP-learned routes). Ties then fall, in this order, to: shortest `AS_PATH`; lowest `ORIGIN` (IGP < EGP < INCOMPLETE); lowest `MULTI_EXIT_DISC`, compared only between routes from the same neighbouring AS; eBGP over iBGP; lowest interior cost to the `NEXT_HOP`; lowest BGP Identifier; lowest peer address. Many implementations add steps the RFC does not define — a router-local WEIGHT before `LOCAL_PREF`, a preference for locally originated routes before `AS_PATH` — and RFC 4456 adjusts the last steps for route reflection.
code
pseudocode · 14 linescandidates = paths to prefix P
drop p where not resolvable(p.NEXT_HOP)
drop p where localAS in p.AS_PATH
keep max(p.preference) # LOCAL_PREF inside the AS
keep min(len(p.AS_PATH)) # AS_SET counts as 1
keep min(p.ORIGIN) # IGP 0 < EGP 1 < INCOMPLETE 2
for m, n in candidates: # MED, same neighbouring AS only
if neighborAS(m) == neighborAS(n) and MED(n) < MED(m):
drop m
if any(p.learnedVia == EBGP): drop iBGP-learned paths
keep min(igpCost(p.NEXT_HOP))
keep min(p.bgpIdentifier)
keep min(p.peerAddress)
return the single remaining pathgo deeper
Recall the backbone of the list: LOCAL_PREF, AS_PATH length, ORIGIN, MED, eBGP over iBGP, IGP cost, identifiers, and that higher preference but lower everything else wins.
Explain the eligibility checks before the list, why MED compares only within one neighbouring AS, and which steps are RFC 4271's versus an implementation's such as WEIGHT.
Demonstrate operational consequences: an IGP cost change rerunning BGP selection, inconsistent per-router knobs creating loops, and route reflection's ORIGINATOR_ID and CLUSTER_LIST amendments.
Discuss why the order is a design choice — policy before topology, determinism versus stability in oldest-path tie-breaks — and how an organisation keeps decisions consistent across vendors.
## Step zero: which paths are even eligible A BGP speaker keeps every path its peers advertised in its **Adj-RIBs-In** and runs the **Decision Process** (RFC 4271 §9.1) to put one best path per prefix into the **Loc-RIB**. Before any attribute is compared, two checks remove paths from the contest: - **Unresolvable `NEXT_HOP`.** If the address in `NEXT_HOP` cannot be resolved through the routing table, the path MUST be excluded (§9.1.2). It is kept in the Adj-RIB-In in case it becomes resolvable later, but it cannot win. - **AS loop.** If the local AS number already appears in `AS_PATH`, the path should be excluded. A path that fails either check does not "lose on cost" — it never enters the comparison at all. ## The standard order RFC 4271 splits selection into a **degree of preference** (Phase 1, §9.1.1) and **tie-breaking** (§9.1.2.2), whose criteria MUST be applied in the order given: | Step | Compare | Prefer | Note | |---|---|---|---| | 1 | degree of preference | highest | `LOCAL_PREF` for iBGP-learned routes; computed by policy for eBGP-learned ones | | a | `AS_PATH` length | shortest | an `AS_SET` counts as one | | b | `ORIGIN` | lowest | IGP 0, EGP 1, INCOMPLETE 2 | | c | `MULTI_EXIT_DISC` | lowest | only among routes from the same neighbouring AS; a missing MED counts as 0 | | d | session type | eBGP | if any candidate is eBGP-learned, iBGP-learned ones are removed | | e | interior cost to `NEXT_HOP` | lowest | the "closest exit" step | | f | BGP Identifier of the advertiser | lowest | | | g | peer address | lowest | | The process stops as soon as one path remains, so later steps are reached only when every earlier one tied. ## Steps implementations add The RFC says its procedure is conceptual and implementations may differ as long as the externally visible behaviour matches. In practice several implementation steps appear in interview answers, and each must be labelled as an implementation's, not the RFC's: - **WEIGHT** — a value local to one router, checked before `LOCAL_PREF`. It is not a path attribute, is never sent to any peer, and appears nowhere in RFC 4271. - **Locally originated** — a preference for paths the router itself injected, placed before `AS_PATH` length. - **Oldest eBGP path** — some implementations prefer the longest-established eBGP path before comparing identifiers, trading determinism for stability. ## Route reflection's amendments RFC 4456 §9 modifies the tie-breakers when routes are reflected: a route's `ORIGINATOR_ID` SHOULD be treated as the BGP Identifier in step f, and between steps f and g a speaker SHOULD prefer the route with the shorter `CLUSTER_LIST`. How reflection itself works belongs with iBGP propagation; only its effect on the order belongs here. ## A short trace A router in AS 64500 holds three paths to `192.0.2.0/24`, all with resolvable next hops: | Path | Preference | `AS_PATH` length | `ORIGIN` | Learned via | |---|---|---|---|---| | P | 100 | 2 | IGP | eBGP | | Q | 100 | 2 | INCOMPLETE | iBGP | | R | 90 | 1 | IGP | eBGP | R leaves at the first comparison despite the shortest path, because its preference is lower. P and Q tie on preference and length; `ORIGIN` then removes Q (INCOMPLETE is 2, IGP is 0). P wins, and the session-type step is never needed. ## Why the order matters operationally 1. **Every router in an AS must decide consistently.** RFC 4271 warns that conflicting decisions inside one AS can cause forwarding loops; the tie-breakers assume every speaker can compute the interior cost to each `NEXT_HOP` and runs the same algorithm. 2. **Reruns are triggered by the IGP too.** If the immediate next hop or the interior cost to a `NEXT_HOP` changes, Phase 2 MUST be performed again, so an IGP event can move BGP traffic. 3. **Policy beats topology.** Because preference is first, a single `LOCAL_PREF` decision overrides every topological signal below it. ## Common mistakes - Putting MED before `AS_PATH` length, or comparing MED across different neighbouring ASes. - Calling WEIGHT a BGP attribute. - Choosing the **highest** BGP Identifier at the end (it is the lowest). - Treating an unresolvable `NEXT_HOP` as merely expensive rather than ineligible.
- Why must every BGP router in one AS run the same decision order?RFC 4271 warns that conflicting route selection inside an AS can cause forwarding loops: if router A forwards toward B's exit while B prefers A's exit, packets bounce between them. The tie-breakers assume every speaker can compute the interior cost to each `NEXT_HOP` and follows the same algorithm, which is why router-local knobs such as WEIGHT need care.
- How does route reflection change the last BGP tie-breakers?RFC 4456 §9: when a route carries `ORIGINATOR_ID`, that value SHOULD stand in for the advertiser's BGP Identifier in the identifier step, and between that step and the lowest-peer-address step a speaker SHOULD prefer the shorter `CLUSTER_LIST`, counting an absent list as length zero.
- What does 'lowest ORIGIN' mean in practice?`ORIGIN` records how the originating AS learned the prefix: IGP (0) for reachability interior to it, EGP (1) for the historic Exterior Gateway Protocol, INCOMPLETE (2) for anything else, typically redistribution. Lower wins, so among otherwise equal paths one originated as IGP beats one marked INCOMPLETE.
saying these in an interview costs you the question
- MED is compared before AS_PATH length in BGP's decision.
- WEIGHT is a BGP path attribute defined in RFC 4271.
- eBGP over iBGP is checked before LOCAL_PREF.
- The highest BGP Identifier wins the final tie.
- A path with an unresolvable NEXT_HOP just loses on IGP cost.
- The lowest LOCAL_PREF is the preferred one.