JOVANA
Explore Library Glossary Getting Started Three Levels Fields How it works Mission
Join the mission
All guides

BGP: Path-Vector Routing Between Networks

Inside an autonomous system, routers agree on the shortest path. Between tens of thousands of autonomous systems, nobody agrees on anything — so the Internet glues them together with one strange, gossipy protocol that advertises whole paths instead of distances. Let's see how BGP actually works.

Why the protocols you already know stop at the border

In the routing rung you met two ways for routers to agree on paths inside one network: link-state flooding (every router learns the whole map and runs a shortest-path computation) and distance-vector (each router tells its neighbours its best distance to each destination). Both are flavours of an interior gateway protocol — an IGP, like OSPF or RIP — and both share one assumption: a single organisation runs every router, trusts every router, and wants the genuinely shortest path.

That assumption shatters at the edge of an autonomous system (AS). As the previous two guides showed, the Internet is roughly seventy-thousand of these independently run networks, stitched together by transit and peering deals at exchange points. Comcast does not trust Vodafone's routers, does not see Vodafone's internal map, and absolutely does not want to carry Vodafone's traffic for free. Between ASes, routing stops being about distance and starts being about money, contracts, and trust.

Path-vector: advertise the whole route, not the distance

The Border Gateway Protocol (BGP) is the one protocol that holds the inter-domain Internet together, and it is a third kind of routing called path-vector. Recall the trouble with plain distance-vector: a router only tells its neighbour "I can reach 10.0.0.0/8 at cost 4," and the neighbour has no idea where that 4 came from. When a link fails, the false hope of an old route can bounce around forever — the count-to-infinity problem. Path-vector fixes this by advertising the entire list of ASes a route passes through.

So instead of a bare number, a BGP advertisement says: "To reach the prefix 203.0.113.0/24, follow this AS-path: AS65010, then AS65002, then AS65001." The AS-path is the heart of BGP. It is a breadcrumb trail of every network the announcement has already crossed, and it carries two superpowers. First, loop detection is trivial: if a router sees its own AS number already in the path, it drops the route — a loop can never form, no count-to-infinity. Second, the path is the raw material for policy, which is the whole point of the next guide.

AS65001 owns 203.0.113.0/24 and announces it outward:

  AS65001 --> AS65002 : prefix 203.0.113.0/24, AS-path = [65001]
  AS65002 --> AS65010 : prefix 203.0.113.0/24, AS-path = [65002 65001]
  AS65010 --> AS65020 : prefix 203.0.113.0/24, AS-path = [65010 65002 65001]

Each AS PREPENDS its own number before passing the route along.
If AS65002 ever saw 65002 already in a path, it would reject it (loop).
A prefix is announced by its owner; each AS prepends itself, so the AS-path grows leftward and records the whole journey.

Notice what BGP advertises: not hosts, not IP addresses, but prefixes — blocks of addresses written in CIDR notation like 203.0.113.0/24. An AS announces "these prefixes are reachable through me," and good network operators aggregate many small prefixes into a few large ones to keep the global routing table from exploding. BGP speaks in prefixes because the Internet has billions of devices but only hundreds of thousands of address blocks worth gossiping about.

Two BGPs in one: eBGP carries routes in, iBGP spreads them around

Here is a subtlety that trips up every newcomer. BGP runs in two modes that look identical on the wire but solve opposite problems — the eBGP / iBGP split. External BGP (eBGP) runs between border routers in different ASes; it is the gossip that crosses the boundary and learns which prefixes the neighbour AS can reach. Internal BGP (iBGP) runs between routers inside the same AS, and its only job is to share what eBGP learned so that every router in the AS knows about external destinations.

Why not just let the IGP carry that information? Because an AS can hear hundreds of thousands of external prefixes, and you would never want to pour all of that into OSPF, which is tuned for a few internal links. So the division of labour is clean: the IGP knows how to physically reach every router inside the AS (the internal map), while iBGP knows which external prefixes exist and which border router each one came in through. A packet to a distant prefix is handed to the right exit border router by iBGP, and the IGP figures out the internal hops to actually get there.

How a route is learned, chosen, and installed

BGP routers do not flood or broadcast. Two of them open a plain TCP connection (BGP rides on TCP port 179, leaning on its reliability so BGP itself never has to retransmit) and become peers. They start by dumping their full set of best routes to each other, and from then on send only incremental updates — "this new prefix appeared," "that prefix withdrew" — keeping the conversation quiet when nothing changes. Here is the full life of one route from a peer:

  1. Receive. A peer sends an UPDATE: a prefix (say 198.51.100.0/24), its AS-path, and a bundle of attributes the next guide will dissect — local preference, AS-path length, MED, and more.
  2. Apply import policy. The router runs the route through filters: is this a path I am even allowed to use? Should I downgrade it? A customer route gets boosted, a route I should not have heard gets dropped right here.
  3. Compare and decide. The router may now hold several routes to the same prefix from different peers. It runs the BGP decision process — highest local preference first, then shortest AS-path, then a tie-breaker chain ending in lowest MED — and crowns exactly one winner as best.
  4. Install. The single best route is written into the router's forwarding table, so future packets to that prefix get matched by longest-prefix match and sent the right way.
  5. Re-advertise (selectively). The router tells its other peers about the winner — but only the ones its export policy permits, prepending its own AS number to the path on the way out.

Two things in that loop are worth underlining. BGP advertises only its single best route to each peer, not every option it knows — so the global view is built from each AS's chosen opinions, not the raw truth. And re-advertisement is filtered by policy, which is precisely how an AS refuses to become a free transit pipe for traffic it earns nothing from. We will spend the next guide on exactly why step 3's order is what it is.

The default-free zone, and why BGP is fragile

Your home router has a simple life: it knows a few local addresses and shoves everything else toward one default route at your ISP. The big routers at the Internet's core cannot cheat like that. They sit in the default-free zone — they hold a BGP route for every prefix on the planet, because there is no "upstream" to punt the unknown to. That global table now carries well over nine hundred thousand IPv4 prefixes, and a core router must store and search all of them. The default-free zone is, quite literally, what it means to be in the middle of the Internet.

All this power rests on an uncomfortable truth: classic BGP trusts what it is told. There is no built-in proof that an AS actually owns the prefixes it announces. That trust is the source of three famous failure modes. A flaky link can make a route appear and vanish over and over — route flapping — and each flip ripples outward as updates, so operators damp persistently unstable routes to stop the churn from spreading.

More serious is prefix hijacking: an AS announces a prefix it does not own, often a more specific one, and because longest-prefix match always prefers the more specific route, traffic for that block silently flows to the wrong network. Its cousin, the route leak, happens when an AS re-advertises routes it should have kept private — for example, passing one provider's routes to another and accidentally offering itself as free transit. Both stem from missing policy or missing authentication, and both have knocked real services offline.