skip to content

A dual-homed enterprise's BGP border router learns 203.0.113.0/24 over eBGP with AS_PATH 64501 64510 64511 and over iBGP with AS_PATH 64502 64511; which path wins, and why?

level: seniorimportance: should knowfreq 25%

answer

  1. eligibility before attributes
  2. is the iBGP next hop reachable?
  3. length comes before eBGP versus iBGP
  4. MED needs one neighbouring AS

basics

~20 s

If both NEXT_HOPs resolve and LOCAL_PREF is equal, the iBGP path wins on the shorter AS_PATH, two ASes against three, before eBGP-over-iBGP is reached. An unresolvable iBGP NEXT_HOP or a higher LOCAL_PREF on the eBGP path reverses that.

solid answer

~40 s

Walk RFC 4271 in order. First eligibility: the iBGP path's `NEXT_HOP` is, by default, provider B's address, because iBGP leaves it unchanged; if that address is not reachable inside the AS, the path is excluded and the eBGP path wins by default. If both resolve, compare degree of preference: equal `LOCAL_PREF` passes on. Then `AS_PATH` length: the iBGP path has two ASes, the eBGP path three, so the **iBGP path wins** and traffic crosses to the other border router. The eBGP-over-iBGP rule never runs, because it sits four steps later. A higher `LOCAL_PREF` on provider A's routes would win before length; a router-local weight would change only this router's choice.

go deeper

for a junior

Recall that a shorter AS_PATH beats eBGP-over-iBGP because path length is compared much earlier in BGP's decision.

for a middle

Walk the steps aloud in order — eligibility, LOCAL_PREF, AS_PATH, ORIGIN, MED, eBGP over iBGP — and say why MED is skipped between different neighbouring ASes.

for a senior

Diagnose the real-world twist: an iBGP path silently excluded because its provider next hop is not in the IGP, and the difference between router-local and AS-wide preference.

for a principal

Use the walk to argue a multihoming policy: decide primary and backup with LOCAL_PREF across the AS, and accept that per-prefix shortest-path exits change as the internet changes.

## The setup Enterprise AS 64500 is dual-homed: - **R1** has an eBGP session to provider A (AS 64501). - **R2** has an eBGP session to provider B (AS 64502). - R1 and R2 are iBGP peers and run an IGP for the enterprise's internal links. For `203.0.113.0/24`, R1 holds two paths: | | Path X (eBGP, from A) | Path Y (iBGP, from R2) | |---|---|---| | `AS_PATH` | 64501 64510 64511 (3 ASes) | 64502 64511 (2 ASes) | | `ORIGIN` | IGP | IGP | | `MULTI_EXIT_DISC` | none | none | | Degree of preference | 100, from R1's policy | `LOCAL_PREF 100`, set by R2's policy | | `NEXT_HOP` | provider A's address on R1's link | provider B's address on R2's link, unless R2 rewrote it | ## Walking RFC 4271 in order 1. **Eligibility.** RFC 4271 §9.1.2 excludes a path whose `NEXT_HOP` cannot be resolved. iBGP does not change `NEXT_HOP`, so Y carries provider B's address. If R2 neither rewrites the next hop to its own address nor carries the B link's subnet in the IGP, R1 has no matching route and Y is **out**: X wins by default, whatever its length. (Note that a covering route, such as a default route, would count as a match under the RFC's resolvability rule; whether an implementation lets a default route resolve a `NEXT_HOP` is its own choice.) 2. **Degree of preference.** Both 100: tie. 3. **`AS_PATH` length.** Y has 2, X has 3. **Y wins.** The walk ends here. 4. The later steps — `ORIGIN`, MED, eBGP over iBGP, interior cost, identifiers — are never reached. So with a resolvable next hop and equal preference, R1 forwards toward R2 and out through provider B. R2, meanwhile, keeps its own eBGP path through provider B: R1 advertises only its best path, and because that best path was learned over iBGP it is not passed back over iBGP. The two routers agree on provider B, and no loop forms. ## What overturns the result - **An unreachable iBGP next hop** (step 1): the shorter path is not "worse", it is ineligible. - **Unequal `LOCAL_PREF`**: if the enterprise sets 200 on routes from provider A, X wins at step 2 on every router, because iBGP carries that preference everywhere. - **A router-local weight** (an implementation feature, not an RFC 4271 attribute): set on R1 it makes only R1 prefer X. Other routers still decide by attributes, so internal traffic may head to R2 anyway. - **A locally originated preference** (also an implementation step) does not apply here; neither path was originated by R1. ## Variant: equal path lengths Suppose provider A's path were `64501 64511`, two ASes like Y. 1. `ORIGIN`: both IGP, tie. 2. MED: X's neighbouring AS is 64501, Y's is 64502. RFC 4271 compares MED only between routes from the **same** neighbouring AS, so nothing is removed. 3. **eBGP over iBGP**: X is eBGP-learned, so Y is removed. **R1 picks X**; by the same step R2 picks its own eBGP path. Each border router now exits through its own provider. A router deeper in the enterprise, holding both paths over iBGP, goes one step further: **lowest interior cost to the `NEXT_HOP`** — it hands the traffic to the nearest exit. RFC 4451 calls this closest-exit behaviour **hot potato routing**. ## Diagnosing it on a live network When traffic leaves by the "wrong" provider, check in the same order the router decides: - **Is the expected path present at all?** If it is not in the Adj-RIB-In, the problem is the session or the neighbour's announcement, not selection. - **Is it eligible?** An iBGP path whose `NEXT_HOP` is a provider's link address needs that subnet in the IGP, or a border router that rewrites the next hop to itself. - **Do the preferences differ?** A forgotten `LOCAL_PREF` on one border router decides everything below it. - **Which step finally separated the paths?** Read the attributes side by side and find the first one that differs. - **Is an implementation-only step involved?** A router-local weight or a locally originated route can win before the standard steps. ## What an interviewer listens for - Eligibility is checked **before** any attribute. - `AS_PATH` length precedes eBGP over iBGP by four steps. - MED is skipped between different neighbouring ASes. - Router-local knobs change one router; `LOCAL_PREF` changes the AS.

  • In this dual-homed BGP setup, if both AS_PATHs had two ASes, which path would each border router choose?
    `ORIGIN` ties, and MED is not compared because the neighbouring ASes differ (64501 against 64502). The eBGP-over-iBGP step then makes R1 keep its own eBGP path and R2 keep its own, so each exits through its own provider. Routers deeper inside, holding both paths over iBGP, choose the lowest interior cost to the `NEXT_HOP` — the nearest exit.
  • What happens to R1's choice when R2's eBGP session to provider B goes down?
    R2 withdraws the route over iBGP, so R1's Adj-RIB-In loses path Y and Phase 2 reruns with only the eBGP path from provider A, which now wins. RFC 4271 also requires selection to rerun when the interior cost to a `NEXT_HOP` changes, so an IGP event alone can move this choice.
  • Why is a router-local weight on R1 a poor way to make provider A the enterprise's primary exit?
    A weight is an implementation feature confined to one router and never advertised, so only R1 changes its mind; R2 and internal routers keep choosing by attributes and may still send traffic toward provider B. Setting a higher `LOCAL_PREF` on provider A's routes makes the choice on every router, because iBGP carries it.

saying these in an interview costs you the question

  • R1 must prefer its eBGP path, because eBGP always beats iBGP.
  • A path with an unreachable next hop just loses on IGP cost.
  • MED decides between the provider A and provider B paths.
  • A weight set on R1 changes the choice of every router in the AS.
  • The two-AS path wins because it crosses fewer routers.