BGP's decision process selects one best path per prefix; under what conditions can a BGP speaker still install several paths for load sharing?
answer
- one best path, several forwarders
- equal through interior cost
- same neighbouring AS, unless relaxed
- peers still hear only one
basics
~20 sRFC 4271 installs one path; multipath is an implementation extension. Paths qualify when they tie through interior cost to the NEXT_HOP — same LOCAL_PREF, AS_PATH length, ORIGIN, MED, session type and IGP cost — usually from the same neighbouring AS.
solid answer
~50 sRFC 4271's Phase 2 installs exactly one route per destination in the Loc-RIB, so load sharing is something implementations add. RFC 7938 §6.1 records the common rule: paths count as equal if they match up to and including tie-breaker e — equal degree of preference, `AS_PATH` length, `ORIGIN` and MED, the same session type (all eBGP or all iBGP), and equal interior cost to the `NEXT_HOP`. By default they must usually also come from the same neighbouring AS; an implementation option relaxes that to equal-length paths through different ASes, which RFC 7938 §6.2 needs in an eBGP-only data centre. The speaker still picks one best path with the remaining tie-breakers and advertises only that one; peers learn more only with ADD-PATH (RFC 7911). How many paths, and how traffic is hashed across them, are implementation and forwarding-table matters.
go deeper
Recall that BGP normally uses one best path per prefix and that load sharing needs paths that are equal on every comparison up to interior cost.
Explain the equality rule through RFC 4271's step e, why eBGP and iBGP paths never tie, and why the default demands one neighbouring AS.
Show operational awareness: relaxing the neighbouring-AS condition in an eBGP fabric, peers still hearing one path without ADD-PATH, and reflectors hiding extra paths.
Weigh where to spread load — BGP multipath, more announcements, or hashing at another layer — against determinism, table size and how failures shift traffic.
## What the RFC actually says RFC 4271's Phase 2 chooses, for each destination, the route with the highest degree of preference, or the single route left after the tie-breakers, and installs **that one route** in the Loc-RIB. Nothing in the base protocol installs two. **BGP multipath is an implementation extension**: the speaker still runs the decision process, but it also marks other paths that are "as good as" the best one and gives all of them to the forwarding table. ## When paths count as equal RFC 7938 §6.1 records the rule most implementations follow: paths are equal for multipath if they **match up to and including step (e)** of RFC 4271 §9.1.2.2. In order: 1. Same degree of preference (`LOCAL_PREF`). 2. Same `AS_PATH` length. 3. Same `ORIGIN`. 4. Same `MULTI_EXIT_DISC` (where comparable). 5. Same session type — because step d removes iBGP-learned routes whenever an eBGP-learned one exists, an eBGP path and an iBGP path never tie. 6. Same interior cost to the `NEXT_HOP`. Steps f and g — lowest BGP Identifier, lowest peer address — still run, but only to pick which of the equal paths is the **best path**; they do not disqualify the others. ## The neighbouring-AS condition | Condition | Typical default | Relaxed option | |---|---|---| | Neighbouring AS | the same for every path | different ASes allowed | | `AS_PATH` | often the same content as well as length | same length, different content | | Where it matters | two links to one provider | an eBGP-only fabric | RFC 7938 §6.2 explains why the relaxed form exists: in a data centre built on eBGP alone, the same server prefix is announced by several devices, each in its own AS. Their `AS_PATH`s differ in content but have equal length, so the default same-AS rule would leave one path; an implementation option that allows different neighbouring ASes lets equal-cost load sharing span them. The RFC also notes that, with no IGP in that design, interior costs are taken as equal and attributes that vary by implementation default, such as MED and `ORIGIN`, may need to be equalised by policy. ## What multipath does not change - **Advertisement.** The speaker advertises only its single best path to each peer. A peer learns several paths for a prefix only if both support **ADD-PATH** (RFC 7911), which tags each path with a **Path Identifier**. - **Behind a route reflector.** A reflector passes on its own best path, so a client may never see the extra paths it could share across — a property of iBGP propagation rather than of this decision. - **Numbers.** The maximum number of paths installed is an **implementation choice**, often bounded by hardware. - **Forwarding.** How packets are spread across the installed next hops — typically a per-flow hash — is the forwarding table's job, the same as for any equal-cost route. ## Why the equality rule stops at interior cost Stopping at step e is what keeps multipath safe inside an AS. Every criterion up to and including interior cost is one that every router in the AS evaluates the same way, so any of the equal paths is a choice the rest of the AS would also accept. Steps f and g are arbitrary by design: they exist only to make the choice deterministic, so treating paths that differ only there as equal costs nothing. A path that loses at step e, by contrast, really is further away, and sharing load onto it would send traffic the long way round. ## A worked check Enterprise AS 64500 has two links to provider AS 64501 and receives `192.0.2.0/24` on both. Both paths: `LOCAL_PREF 100`, `AS_PATH 64501 64511`, `ORIGIN` IGP, MED 0, eBGP, directly connected next hops. They tie through step e, so a multipath-enabled border router can install both. If AS 64501 sent MED 10 on one link and MED 0 on the other, the MED step would separate them: one best path, no sharing. If the second path came instead from provider AS 64502 with the same length, the default same-neighbouring-AS condition would exclude it unless relaxed. ## Pitfalls interviewers probe - Assuming equal `AS_PATH` length is enough — every earlier and later criterion through interior cost must tie too. - Expecting peers to see the extra paths without ADD-PATH. - Mixing eBGP and iBGP paths, which the standard steps keep apart. - Treating the path count as a protocol constant.
- Does installing several BGP paths change what the speaker advertises to its peers?No. The speaker still selects one best path, using the identifier and peer-address tie-breakers among the equal paths, and advertises only that one. Peers receive several paths for a prefix only when both sides support ADD-PATH, RFC 7911, which distinguishes each path by a Path Identifier.
- Why does an eBGP-only data-centre fabric need multipath across different neighbouring ASes?RFC 7938 gives each device or tier its own AS, so one prefix announced from several devices arrives with AS_PATHs that differ in content but match in length. The default rule of one neighbouring AS would install a single path; relaxing it to equal-length paths through different ASes lets traffic spread across all of them.
saying these in an interview costs you the question
- RFC 4271 lets a BGP speaker select several best paths per prefix.
- Any BGP paths with equal AS_PATH length are load-shared.
- Multipath makes peers learn every installed path automatically.
- An eBGP path and an iBGP path are load-shared by default.
- RFC 4271 fixes the maximum number of BGP multipaths.