skip to content

Why does a BGP speaker not simply pick the path with the fewest autonomous systems, the way an IGP picks the lowest metric?

level: juniorimportance: should knowfreq 38%

answer

  1. policy before path length
  2. degree of preference comes first
  3. an AS is not a hop
  4. LOCAL_PREF outranks AS_PATH length

basics

~20 s

BGP's decision is policy first: a route's degree of preference, carried as LOCAL_PREF inside an AS, is compared before AS_PATH length. And AS_PATH length counts networks, not routers, bandwidth or delay, so it is only a rough tie-breaker.

solid answer

~40 s

BGP connects networks run by different operators, and each one chooses routes by its own policy rather than by a metric everyone shares. In RFC 4271's decision process the **degree of preference** — carried inside the AS as `LOCAL_PREF` — is compared first, so an operator can prefer a paying customer's route or a primary provider over a path that is shorter. Only among routes tied on preference does the speaker prefer the shortest `AS_PATH`, then lowest `ORIGIN`, lowest `MULTI_EXIT_DISC`, eBGP over iBGP, lowest interior cost to the `NEXT_HOP` and finally identifiers. Even where it decides, AS_PATH length is a crude signal: one AS can be a single router or an intercontinental backbone, and the count says nothing about bandwidth, latency or load.

go deeper

for a junior

Recall that BGP is policy first: the degree of preference, LOCAL_PREF inside an AS, is compared before AS_PATH length, and AS_PATH length counts networks rather than routers.

for a middle

Explain what follows preference — AS_PATH length, ORIGIN, MED within one neighbouring AS, eBGP over iBGP, interior cost, identifiers — and why each step is only a tie-breaker.

for a senior

Show when path length misleads: a one-AS backbone across oceans against three short regional hops, and why operators state preference explicitly instead of trusting the count.

for a principal

Frame it as a trade-off: BGP gives every operator sovereignty over its own choice at the cost of global optimality, which is why inter-domain paths are often longer than the shortest.

## What the question is really testing The question checks whether you know that BGP is a **policy routing protocol**, not a shortest-path protocol. An interior gateway protocol (IGP) such as OSPF runs inside one organisation, where every router agrees on one metric and the goal is the cheapest path. BGP runs **between** organisations — autonomous systems (ASes) — that do not share a metric, do not trust each other, and each have commercial reasons to prefer one neighbour over another. So the first thing a BGP speaker asks is not "which path is shortest?" but "which path does my own policy prefer?". ## How an IGP chooses versus how BGP chooses | | IGP (for example OSPF) | BGP | |---|---|---| | Who sets the ranking | one operator, one metric for the whole domain | each AS, by its own policy | | First criterion | lowest total metric | highest **degree of preference** | | What "distance" means | sum of link costs the operator chose | number of ASes in `AS_PATH`, and only as a tie-breaker | | Goal | optimal path inside the domain | a path acceptable to every AS's policy | ## Where AS_PATH length sits in the decision RFC 4271 §9.1 first discards routes it cannot use — a route whose `NEXT_HOP` cannot be resolved, or whose `AS_PATH` already contains the local AS. Among the rest it applies an ordered list: 1. Highest **degree of preference** — for a route learned over iBGP this is its `LOCAL_PREF`; for a route learned over eBGP the speaker computes it from local policy. 2. Shortest `AS_PATH` (an `AS_SET` counts as one AS). 3. Lowest `ORIGIN` code (IGP 0, EGP 1, INCOMPLETE 2). 4. Lowest `MULTI_EXIT_DISC`, compared only among routes from the same neighbouring AS. 5. eBGP-learned over iBGP-learned. 6. Lowest interior cost to the `NEXT_HOP`. 7. Lowest BGP Identifier, then lowest peer address. AS_PATH length is step two. Whenever policy has set different preferences, the decision is over before length is looked at. Many implementations add steps of their own (a router-local weight before preference, a preference for routes the router originated itself), but the common ones do not move length ahead of preference. ## Why counting ASes is a weak proxy for distance - **An AS is not a hop.** One AS may be a single router in a server room; another may span several continents with dozens of internal hops. `AS_PATH` hides everything inside each AS. - **No capacity or delay.** RFC 4271's decision uses no bandwidth, latency or utilisation; a two-AS path over a congested link still beats a three-AS path over an idle one. - **Lengths are easy to change.** A network can add its own AS number more than once to make a path look longer, so the count reflects intent as much as topology. - **Business comes first.** A network usually prefers a route through a customer (who pays it) over one through a provider (whom it pays), whatever the lengths. ## What preference usually encodes Because preference decides first, it is where an operator writes down its commercial and operational intent. Common patterns: - **Customer routes highest** — traffic sent to a customer earns money. - **Peer routes next** — settlement-free exchange costs little. - **Provider routes lowest** — traffic sent to a transit provider is paid for. - **Backup links lowest of all** — used only when nothing better remains. None of this is in RFC 4271, which leaves the computation of preference as "a local matter"; it is simply why preference, not length, has to come first. ## A worked example Enterprise AS 64500 learns `203.0.113.0/24` two ways: - through its customer AS 64510: `AS_PATH 64510 64509 64511`, three in all; - through its transit provider AS 64501: `AS_PATH 64501 64511`, two in all. Its policy gives routes from customers `LOCAL_PREF 200` and routes from providers `LOCAL_PREF 100`. Step one already separates them: 200 beats 100, so the three-AS customer path wins. Had both carried the same preference, step two would have chosen the two-AS transit path. The shorter path lost only because policy spoke first — which is exactly what the operator wanted. ## What to say in an interview - BGP compares **preference before length**; length is a tie-breaker. - `AS_PATH` length counts **networks**, not routers, and carries no bandwidth or delay. - The result is that inter-domain paths are often longer than the shortest available one, by design: every AS keeps control over its own choice.

  • If AS_PATH length is such a crude measure, why does BGP compare it at all?
    Once policy expresses no preference, the number of ASes is a signal every speaker can compute identically from the update itself. Fewer ASes usually means fewer administrative hand-offs and fewer places where policy or failures intervene, so it is a sensible default tie-breaker — just not a measurement of distance, delay or capacity.
  • Does an AS_SET count as several ASes when BGP measures path length?
    No. RFC 4271 counts an `AS_SET` as one, however many ASes it lists, so an aggregate formed from routes through several networks is not penalised for each of them. Inside a confederation, RFC 5065 adds that the confederation segments should not be counted either.

saying these in an interview costs you the question

  • BGP always picks the path with the fewest AS hops.
  • AS_PATH length counts the routers a packet crosses.
  • BGP ranks paths by bandwidth or delay, like OSPF's link cost.
  • AS_PATH length is compared before LOCAL_PREF in BGP's decision.
  • Every AS on the internet uses the same metric for BGP paths.