BGP and Autonomous Systems

A packet leaving your phone for a server in Frankfurt crosses a dozen independent companies that have never coordinated their engineering, run different equipment, and often actively compete. Yet the packet arrives, usually in tens of milliseconds. There is no master map of the Internet stored anywhere; no committee computes the routes. Instead the whole global structure emerges from thousands of networks each shouting to their neighbours, "here are the destinations I can reach, and here's the path to them." That gossip protocol is BGP, the Border Gateway Protocol — the single piece of software that glues the Internet into one network.

We have already seen how routing works inside one network. BGP is different in kind: it is inter-domain routing, and its job is not to find the shortest path but to respect business policy — who pays whom, who is allowed to carry whose traffic. This page is about the unit BGP connects (the autonomous system), the path-vector mechanism it uses, the money-shaped policies that actually decide routes, and the alarming fact that the protocol holding the Internet together is built almost entirely on trust.

The autonomous system: the atom of the Internet

BGP does not route between computers or even between routers; it routes between autonomous systems. An AS is a set of IP prefixes and routers under a single administrative control with one consistent routing policy — an ISP, a big cloud, a large university. Each AS is stamped with a globally unique Autonomous System Number (ASN), handed out by the regional registries.

ASNs were originally 16-bit (0–65535), but those ran out, so BGP was extended to 32-bit ASNs (up to ~4.2 billion). Familiar examples: AS15169 is Google, AS32934 is Facebook/Meta, AS13335 is Cloudflare.
An AS originates the prefixes it owns — e.g. Cloudflare originates 104.16.0.0/12 — meaning "traffic for these addresses should ultimately come to me."
Ranges 64512–65534 and 4200000000–4294967294 are private ASNs, used internally the way private IP ranges are, never seen in the global table.

There are roughly 75,000+ active ASes today, and the global BGP routing table has grown past ~950,000 IPv4 prefixes — a number every core router must hold in memory and search on every packet, which is why router memory (the "FIB") is a real and expensive constraint.

Path-vector: advertise the whole AS-path

Interior protocols like OSPF flood link states; simple distance-vector protocols advertise only a distance. BGP does something cannier — it is a path-vector protocol: every route advertisement carries the entire list of ASes the route passes through, the AS-path. When AS3 tells its neighbour AS4 "I can reach 203.0.113.0/24 via AS-path 3 2 1," AS4 records the route and, if it chooses to re-advertise it, prepends its own ASN: it tells AS5 the path is 4 3 2 1.

Carrying the full path buys two things a plain distance never could:

Loop freedom, instantly. Before accepting a route, an AS checks whether its own ASN already appears in the AS-path. If it does, the route would loop, so it is rejected outright. No counting-to-infinity, no hold-down timers — the loop is visible in the path.
Policy, not just distance. A shorter AS-path is preferred by default, but an AS is free to pick a longer path for business reasons, or to refuse to advertise a route at all. The path is data for a policy decision, not an order.

Watch a prefix originated by AS1 ripple outward, each AS prepending itself so the path grows as it travels:

The routes are chosen by money, not distance

This is the part that surprises everyone: BGP's real decisions are commercial. Networks interconnect in two economically different ways:

Relationship	Who pays	What routes are shared
Transit (customer ↔ provider)	Customer pays the provider per bit	Provider gives the customer routes to the whole Internet
Peering (peer ↔ peer)	Usually settlement-free (nobody pays)	Each shares only its own + its customers' routes, not the whole Internet

These relationships drive the famous valley-free rule (Gao–Rexford): a network happily carries traffic for free if doing so earns money or reaches a paying customer, but it will not spend money to carry traffic that benefits a competitor. Concretely, an AS prefers routes in this order: customer > peer > provider — because a customer route earns revenue, a peer route is free, and a provider route costs money.

BGP encodes this with attributes, applied in a strict order when choosing among candidate routes for the same prefix:

LOCAL_PREF — highest wins. This is where the customer > peer > provider policy is injected, so it dominates everything else.
Shortest AS-path — fewer ASes, all else equal.
MED, origin, eBGP-over-iBGP, then finally lowest router ID as an arbitrary tie-break.

The upshot: the path your packets take is often not the geographically or topologically shortest one — it is the cheapest one for the networks in between. Routing on the Internet is an economic phenomenon wearing an engineering costume.

// BGP best-path selection (simplified): LOCAL_PREF first (higher wins), // then shortest AS-path, then lowest router ID as a tie-break. interface Route { nextHopAs: string; localPref: number; // set by policy: customer=200, peer=100, provider=50 asPath: number[]; routerId: number; } const candidates: Route[] = [ { nextHopAs: "provider-X", localPref: 50, asPath: [7, 9], routerId: 3 }, { nextHopAs: "peer-Y", localPref: 100, asPath: [11, 22, 33], routerId: 5 }, { nextHopAs: "customer-Z", localPref: 200, asPath: [44, 55, 66], routerId: 2 }, ]; function best(routes: Route[]): Route { return [...routes].sort((a, b) => b.localPref - a.localPref || // 1. highest LOCAL_PREF a.asPath.length - b.asPath.length || // 2. shortest AS-path a.routerId - b.routerId // 3. lowest router ID )[0]; } const chosen = best(candidates); console.log(`Chosen next hop: ${chosen.nextHopAs}`); console.log(` (LOCAL_PREF ${chosen.localPref}, AS-path length ${chosen.asPath.length})`); console.log("Note: the customer route wins DESPITE having the LONGEST AS-path,"); console.log("because LOCAL_PREF (policy = revenue) is checked before path length.");

BGP wears two hats. eBGP (external) runs between different ASes — this is the part that swaps routes across company boundaries and prepends ASNs. iBGP (internal) runs within a single AS, distributing the externally-learned routes to all the AS's own border routers so they agree on how to leave the network. A subtlety: to prevent internal loops, a route learned via iBGP is not re-advertised to another iBGP peer — which is why large ASes need route reflectors or a full mesh of iBGP sessions. Same protocol, two very different jobs.

The trust problem: hijacks and leaks

Here is the uncomfortable truth. Classic BGP has no built-in authentication of who owns what. When an AS announces "I originate 203.0.113.0/24," its neighbours largely believe it. That trust, combined with a rule that more-specific prefixes win, makes two disasters possible:

Prefix hijack. An AS announces a prefix it does not own. Because routers prefer the most specific match, announcing a longer (more specific) prefix — say a /24 inside someone's /22 — pulls the world's traffic to the impostor. In the famous 2008 incident, Pakistan Telecom (AS17557) announced a more-specific route for YouTube intending to block it locally; the announcement leaked to its provider and globally, taking YouTube offline for about two hours. A 2018 hijack rerouted Amazon Route 53 DNS traffic to steal cryptocurrency.
Route leak. An AS re-advertises routes it should have kept to itself — e.g. a multi-homed customer accidentally tells provider A about routes learned from provider B, making itself look like a transit path between two giants. Traffic floods through a network far too small to carry it, and everything melts. This has repeatedly caused large regional outages.

The defences are being deployed but are still incomplete: RPKI (Resource Public Key Infrastructure) cryptographically signs "AS X is authorised to originate prefix P" as a Route Origin Authorization, so routers can drop invalid origins; BGPsec would sign the whole AS-path but is barely deployed; and the MANRS initiative pushes operators to filter their customers' announcements. The Internet's core routing still runs largely on the assumption that everyone is telling the truth — which is exactly why a single fat-fingered config in one AS can, and occasionally does, break connectivity for millions.

The seductive wrong model is "BGP finds the best route." It does not. BGP finds a route that is consistent with every network's business policy, and among those, prefers a short AS-path — but AS-path length is a crude proxy. One "hop" might be a transcontinental AS spanning 10,000 km; another might be a tiny local network. A path of two large ASes can be slower than a path of four small ones. BGP has no idea about latency, bandwidth, or congestion; it counts ASes and obeys money.

So your traffic can take a bizarre detour — Toronto to Montreal via New York, or two European users' packets routed through the US — not because it is shorter, but because that is the path the commercial relationships allowed. Never assume the BGP path is the geographically or performance-optimal one; it is merely the policy-legal one with the fewest AS hops.