BGP — path vector, AS, policy routing: Question bank

Before you start, one anchor you must hold in your head: BGP is policy-first, distance-second. Almost every trap here is built by assuming the opposite.

Glossary — every term this page uses (define once, use everywhere)

Definition The core acronyms the traps are built from

AS (Autonomous System): one network under a single owner/policy, wearing a unique number called its ASN. Think "one company's slice of the internet." See AS and ASN allocation.
AS_PATH: the ordered list of ASNs a route has passed through, e.g. $[100, 400, 70]$ . Read right-to-left: the rightmost AS originated the prefix. Its length = number of AS hops.
eBGP (external BGP): the BGP session between routers in different ASes — it crosses an AS boundary.
iBGP (internal BGP): the BGP session between routers inside one AS, used to spread externally-learned routes across that AS. Both ends share the same ASN.
LOCAL_PREF (Local Preference): a number an AS stamps on incoming routes to say "I prefer this exit." Higher = more preferred. This is the money knob — used to rank customer > peer > provider.
MED (Multi-Exit Discriminator): a hint a neighboring AS attaches to say "if you have two links to me, enter here." Lower = preferred, and it is only compared between routes from the same neighbor AS.
ORIGIN: a tiny tag recording how the prefix first entered BGP. It has three values, ranked IGP < EGP < incomplete (lower wins): IGP = the origin AS injected it cleanly from its own interior routing (most trusted), EGP = it came from the old Exterior Gateway Protocol (legacy, rarely seen), incomplete = it was redistributed from somewhere else (e.g. a static route) so its pedigree is unknown. Lower rank = better-understood origin.
IGP cost: the internal distance (from an intra-domain protocol like OSPF) to reach the router that exits the AS. Used to pick the nearest exit.
router-ID: a unique number each BGP router carries; the final deterministic tie-break so every router agrees on one path.
withdrawal: a special BGP message that says "the prefix I told you about earlier is no longer reachable through me — delete it." Unlike a normal announcement (which adds/updates a route), a withdrawal removes one, so neighbours can stop using a path the instant a link dies.

Definition The three business relationships (the whole page depends on this picture)

The figure below shows all three at once. Read it slowly:

Provider ↑ / Customer ↓ (the two vertical black arrows): the customer pays the provider to reach the whole internet. In the figure, You (AS-Y, orange) pay Provider (AS-P, teal) above you; below you, Customer (AS-C, teal) pays you. Money flows up the page, so the higher a node sits, the closer it is to the internet core.
Peer ↔ (the horizontal double arrow between AS-Y and AS-Q, plum): two ASes swap their own + their customers' traffic for free — but neither gives the other transit to the rest of the internet. That's why it's drawn flat and level: neither peer is "above" the other.
Sibling: same owner, full sharing (rare; ignore for the traps).

Figure — BGP — path vector, AS, policy routing

Trace the picture once: money always climbs the vertical arrows, and the flat plum arrow carries no money at all. That single geometric habit — vertical = paid, horizontal = free — is the seed of every export rule below.

Walk the figure: the plum arrows climb A→B→C, cross one peer hop at the top C→D, then descend D→E — a clean "up, top, down" shape, so it's valid. Now look at the dashed orange arrows dipping down to node F and back up: that V-shape is a valley. Node F at the bottom would be handing free transit between two parties above it — earning nothing — which is exactly why Gao–Rexford forbids it. The rule is literally "no valleys in the path."

True or false — justify

TF1. BGP always chooses the route with the fewest AS hops.

False. Fewest AS hops (AS_PATH length) is only step 2; step 1 is highest LOCAL_PREF, a money knob. The reason distance loses is economic: a 4-hop route through a customer earns you money, a 2-hop route through a provider costs you money, so the longer path is chosen on purpose.

TF2. If two routes have the same LOCAL_PREF, the shorter AS_PATH wins.

True. Once policy has no preference between them (equal LOCAL_PREF), BGP falls to the next criterion, and shorter AS_PATH is exactly that. Distance only gets to speak after money has stayed silent.

TF3. The AS_PATH is read left-to-right, origin first.

False. It is read right-to-left because each AS prepends (adds to the front) its own ASN as the route travels outward. So the number that has been there longest — the origin — ends up on the far right.

TF4. iBGP is used to exchange routes between two different ASes.

False. That is eBGP (external, crossing a boundary). iBGP lives inside one AS: after an edge router learns a route via eBGP, iBGP is how it tells the AS's other routers, all of which share one ASN.

TF5. A route learned from a peer may be advertised to your provider.

False. Gao–Rexford sends peer-learned routes only to customers. The economics: telling your provider would advertise yourself as a free transit path for peer traffic, and your provider would then bill you for carrying traffic you earn nothing on.

TF6. A route learned from a customer may be advertised to everyone.

True. Every extra AS that uses this route to reach your customer is traffic your customer pays you to carry. Widening the audience directly widens your revenue, so you announce it to customers, peers, and providers alike.

TF7. MED can override AS_PATH length when comparing routes from two different neighboring ASes.

False by default. MED is step 4 and is only meaningful between routes learned from the same neighbor — it answers "which of your links should I enter?", a question that makes no sense across two different neighbors, so it's usually skipped there.

TF8. Path vector eliminates count-to-infinity entirely.

True (for AS-level loops). The full AS_PATH is carried, so a router that sees its own ASN in the path rejects the route instantly. The path is a certificate of non-loopiness, which is exactly the global view that distance-vector lacks when it slowly counts to infinity.

TF9. Two Tier-1 providers routing traffic for each other must have a customer-provider relationship.

False. A Tier-1 AS by definition has no provider — it can't pay anyone because there's no one "above" it. Two Tier-1s therefore must connect as settlement-free peers, exchanging only their own and their customers' routes.

TF10. Prepending your own ASN multiple times makes a route more attractive to others.

False. Each prepend lengthens the AS_PATH, and step 2 prefers shorter. Operators exploit this backwards — they pad the path on a backup link precisely so neighbours avoid it until the primary fails.

Spot the error

SE1. "AS3 receives AS_PATH [3, 2, 1] for a prefix and accepts it."

Error. The AS running the test, AS3, sees its own ASN already inside the path. Accepting would mean traffic loops back through AS3 — the path itself is proof of a loop, so the rule forces an immediate reject.

SE2. "BGP and OSPF are interchangeable; both minimise a link-cost metric."

Error. OSPF assumes one cooperative owner and honestly minimises cost inside that AS. BGP assumes untrusting parties with money at stake and deliberately picks policy-preferred, often longer, paths. Same word "routing," opposite design goals.

SE3. "A valley-free path can go provider→customer→provider."

Error. Trace it on the figure: down to a customer, then back up to a provider is a "valley." The AS at the bottom would be handing free transit between two providers it earns nothing from — precisely what Gao–Rexford forbids by exporting provider-learned routes to customers only.

SE4. "Since MED is a metric, the lowest MED always wins the route."

Error. MED is step 4, far beneath LOCAL_PREF and AS_PATH, and it's a suggestion from your neighbor about their own links — you're free to weigh it last. Calling it "a metric" oversells a weak, same-neighbor-only hint.

SE5. "eBGP and iBGP both prepend the local ASN when passing a route on."

Error. Prepending marks an AS boundary crossing, which only eBGP does. iBGP stays inside one AS, so adding the ASN would be meaningless (and would even make the AS look like a loop to itself) — the AS_PATH is left untouched.

SE6. "AS100 prefers a peer route over a customer route because peering is free."

Error. "Free" still loses to "paid-for." The customer route brings AS100 revenue, so it gets the highest LOCAL_PREF; the free peer route is merely cost-neutral. Preference order is customer > peer > provider, and the peer route loses at step 1.

SE7. "Distance vector could scale to the internet if we just made the metric bigger."

Error. A bigger number still hides which ASes a route crossed, so loops stay invisible and policy stays inexpressible. The cure isn't a larger metric — it's carrying the whole path, which is a different kind of information, not more of the same.

SE8. "A prefix 8.8.8.0/24 and a more-specific 8.8.8.128/25 are the same route, so BGP keeps one."

Error. They are two distinct CIDR prefixes covering different address ranges. BGP stores both, and at forwarding time longest-prefix match sends the overlapping addresses down the /25 — throwing one away would break reachability.

Why questions

WHY1. Why does BGP prepend the local ASN instead of just incrementing a hop counter?

The prepended list of identities lets each AS

X

(the one running the test) ask "is my own ASN already in this list?" — a direct loop check. A bare counter would only tell you how far, never through whom, so loops would stay invisible.

WHY2. Why is LOCAL_PREF placed above AS_PATH length in the decision process?

Because the protocol's real objective is honouring contracts, not minimising distance. Putting the money knob at the very top guarantees a revenue-earning customer path is chosen even when a shorter, costlier provider path exists.

WHY3. Why do Gao–Rexford rules forbid exporting peer/provider routes to a provider?

Because re-advertising them upward would volunteer you as free transit — your provider would then send you (and bill you for) traffic that earns you nothing. Only paying customers are worth relaying such routes to.

WHY4. Why is hot-potato routing the default egress choice (step 6)?

Hot-potato hands traffic to the nearest exit, minimising the miles it travels on your expensive backbone. You let the next AS absorb the long haul, since carrying it further costs you, not them.

WHY5. Why can't the internet just use one global routing table computed centrally?

Because no AS trusts a central authority with its private commercial policy, and ~1M prefixes across tens of thousands of ASes make one global computation brittle. BGP is decentralised so each AS enforces its own policy locally, no coordinator required.

WHY6. Why does route flap damping exist if path vector already prevents loops?

Loop-freedom stops incorrect paths, not unstable ones — a flaky link can announce-then-withdraw a route endlessly. Flap damping suppresses such a jittery prefix so its churn doesn't ripple across the whole internet.

WHY7. Why is AS_PATH length a poor proxy for actual latency or throughput?

Because one AS hop is an administrative count, blind to physics: it may cross a single city or an entire ocean. Two ASes can be one hop apart yet wildly different in delay and capacity, so hop count can't predict performance.

Edge cases

EC1. What happens when an AS receives no routes to a prefix at all?

The prefix is simply unreachable from that AS — BGP has no built-in default fallback. Until some neighbor advertises a valid AS_PATH, the AS cannot forward traffic there at all.

EC2. What if two routes are identical through every step down to router-ID?

They cannot tie forever: step 8, lowest router-ID, is unique per router, so it always breaks the deadlock. This guarantees every router deterministically picks the same single best path with no oscillation.

EC3. What does an AS_PATH of length 1, e.g. [15169], mean?

You are receiving the route straight from its origin AS — you're a direct eBGP neighbor of the AS that owns the prefix, with zero intermediate ASes between you and the source.

EC4. Can an AS legitimately appear twice in an AS_PATH?

Yes, but only when that AS itself deliberately prepends (e.g. [100, 100, 70]) to deprioritise its own route. If a different AS tried to re-insert an already-present ASN, that would be a loop and gets rejected.

EC5. What happens to a route from a customer AS that goes offline (link dies)?

BGP sends an explicit withdrawal message for that prefix, telling neighbours to delete it. Because path vector never held a looping stale alternative (the full AS_PATH would have exposed any loop on arrival), neighbours converge promptly to another valid path or mark it unreachable — no slow count-to-infinity crawl.

EC6. A stub AS (only one provider, no customers/peers) — what does it export?

Only its own originated prefixes, and only up to its provider. Having no customers, it never gives transit, so it never re-advertises anything it learned from that provider to anyone else.

EC7. iBGP has a "split-horizon" rule — what is it and why?

A router must not re-advertise an iBGP-learned route to another iBGP peer. Since iBGP carries no AS_PATH change inside the AS, this rule (not path-based loop detection) is what prevents internal loops — which is why large ASes need a full iBGP mesh or route reflectors instead.

EC8. Does receiving a route obligate an AS to use or advertise it?

No. Import policy may discard it on arrival, and Gao–Rexford export policy may forbid re-advertising it. Learning that something is reachable is separate from offering that reachability — that separation is the very heart of policy routing.

Recall One-line self-test before you leave

Which single principle collapses most of the traps above? ::: Policy beats distance — LOCAL_PREF (money) is step 1, AS_PATH length (distance) is only step 2.