BGP, how the internet decides where everything is

When we talk about "how the internet routes," the actual mechanism is BGP (Border Gateway Protocol). It's the protocol that lets autonomous systems exchange reachability information, agree on paths, and collectively maintain a working global routing table without any central authority.

BGP is the single most important protocol most internet users have never heard of. This article explains what it does and how it works.

BGP path propagation

Each AS prepends itself to the path. Routers along the way see something like [7922, 174, 32934] and use it to detect loops and pick shortest paths.

What BGP solves

The internet has ~75,000 ASes. Each AS announces some IP prefixes (blocks of addresses). Other ASes need to know:

• Which prefixes exist.
• How to reach each one.
• Which path among multiple options is best.

BGP solves this by letting ASes tell each other "I can reach prefix X via this path," with metadata that helps recipients pick which version to use when multiple paths are available.

The protocol has to:

• Scale to a million-plus prefixes.
• Converge in reasonable time when topology changes.
• Allow operators to express complex policy ("send traffic to network X through this path, not that one").
• Detect and prevent routing loops.
• Be reasonably resilient to misbehavior (with operational mitigations).

BGP is what does all this. It's the protocol that makes "the internet just works" technically possible.

The basic model

BGP runs between pairs of routers, called BGP peers or BGP neighbors. Each side announces the prefixes they can reach. They exchange routes.

Two flavors:

eBGP (external BGP): between routers in different ASes. Most "internet routing" is eBGP.

iBGP (internal BGP): between routers in the same AS, used to distribute external routes inside the AS.

For Series-B purposes, we focus on eBGP, which is what makes the internet's routing work.

What an announcement looks like

Conceptually, a BGP announcement contains:

• Prefix: the IP block being announced, like 203.0.113.0/24.
• AS path: the sequence of ASes the announcement has traversed, like [64501, 7018, 32934].
• Next hop: the IP of the router that should be the next destination for traffic to this prefix.
• Origin: how the route was originally injected (IGP, EGP, or unknown).
• Local preference, MED, communities, and other metadata.

When a router receives an announcement, it adds it to its BGP table (also called the RIB, Routing Information Base). The router selects the best path for each prefix and installs it in its forwarding table (the FIB).

Path selection

For each prefix, a BGP router may have many announcements (from different peers). It must pick one as the "best." The decision uses a long checklist:

1. Highest local preference. The operator's preference, set by policy.
2. Shortest AS path. Fewer ASes = shorter path = better.
3. Origin type. IGP > EGP > Incomplete.
4. Lowest MED (Multi-Exit Discriminator).
5. eBGP over iBGP. Prefer paths learned from external peers.
6. Lowest IGP cost to the next-hop.
7. Oldest path (for stability).
8. Lowest router ID (tiebreaker).
9. Lowest peer IP (final tiebreaker).

Each step is consulted in order; the first that distinguishes the candidates wins. In practice, most decisions resolve at steps 1-3.

A simple example

Consider AS 64500 (your network) buying transit from two providers: AS 7018 (provider A) and AS 64497 (provider B).

For most destinations, you'll receive routes from both A and B. Say 8.8.8.8 is reachable via:

• A: AS path 7018 15169 (length 2)
• B: AS path 64497 174 15169 (length 3)

By the AS-path-length rule, you'd prefer A's route. Traffic to 8.8.8.8 flows out via A.

You can override this with local preference. If you set local pref for A's routes to 100 and B's to 200, B wins despite the longer AS path. Operators do this to direct traffic for cost or performance reasons.

Filtering and policy

BGP gives operators extensive control. Common policies:

Filter what you accept. Only accept routes that match expected prefixes. Reject routes for prefixes you know don't belong to the announcer. This is the basic defense against route hijacks.

Filter what you announce. Only announce your own prefixes (and your downstream customers' prefixes) to your peers. Don't accidentally tell the world "I can reach Google" when you can't.

Prefer specific paths. Set local preference to prefer specific upstreams for specific destinations.

Prepend AS path. Make a route look less attractive by adding your ASN multiple times to its AS path. Used to push traffic to a different upstream.

Communities. BGP communities are tags attached to routes that downstream peers can interpret. Common pattern: "If you tag a route with community X:Y, my network will prefer/drop/redirect it." Lets operators expose routing policy hooks to customers.

Filtering is the operational heart of BGP. Bad filtering causes most BGP-related internet incidents.

Convergence

When a link goes down or a route changes, BGP propagates the update to neighbors. They update their tables and propagate further. Eventually all routers converge to a consistent view of the new topology.

Convergence time depends on:

• How many ASes are involved.
• Whether routes need to be reannounced or just withdrawn.
• Various dampening features (route flap dampening, MRAI timers).

Typical convergence:

• Local changes: seconds.
• Wide-spread changes: 30 seconds to a few minutes.
• Worst case (massive policy changes): up to 10 minutes.

During convergence, packets may be dropped or take suboptimal paths. The "BGP storm" that followed major outages is real and observable.

BGP's biggest weakness: trust

BGP was designed in an era when operators knew each other and trusted each other. The protocol itself has no authentication. If you announce a route, your peers generally accept it. If they propagate further, the internet now believes you.

This is the BGP trust problem. Misconfigurations and malice both have history:

1997: AS 7007 incident. A misconfiguration in a small ISP caused it to announce thousands of more-specific routes for prefixes it didn't own. Most of the internet routed traffic to AS 7007. Service was disrupted for hours.

2008: Pakistan Telecom and YouTube. Pakistan's government ordered local ISPs to block YouTube. Pakistan Telecom did this by announcing a more-specific YouTube route into BGP. The announcement leaked beyond Pakistan, taking YouTube offline globally for about 2 hours.

2018: BGP hijack of cryptocurrency wallets. Attackers manipulated BGP routes to redirect traffic for specific cryptocurrency services, then stole funds via misissued certificates.

2024: Various large-scale leaks that caused regional internet slowness.

RPKI: the mitigation

To address this, the community developed RPKI (Resource Public Key Infrastructure). It lets prefix holders cryptographically sign statements saying "this prefix should be announced only by these ASes."

Routers check incoming BGP announcements against these signed records. If the announcement claims to originate from an unauthorized AS, routers can reject it.

RPKI adoption has grown rapidly in the 2020s. By 2026, most major networks validate RPKI on incoming announcements. The rate of hijack incidents has dropped meaningfully.

RPKI isn't perfect: it protects against origin hijacks but not against more sophisticated path manipulation. But it's the most important security improvement BGP has had in 20 years.

BGP communities, in practice

Communities are tag-like attributes on BGP routes. They have the format X:Y, where X is an ASN and Y is a value defined by that AS.

Common uses:

Customer signaling. A transit provider might publish: "Tag a route with community 7018:666 to have it dropped at our network's edge." Lets customers signal blackholing of attacked IPs without phone calls.

Geographic preference. "Tag with 7018:101 to prefer ingress in North America; tag with 7018:201 to prefer Europe."

Action signaling. "Tag with 7018:301 to depref this route; tag with 7018:302 to preference it."

For hosting customers, knowing your upstream provider's communities lets you tune routing without operator intervention. Most major providers document their communities publicly.

The BGP table size

The global BGP table has grown steadily:

• 1994: ~25,000 prefixes.
• 2000: ~100,000.
• 2010: ~370,000.
• 2020: ~850,000.
• 2026: ~1,000,000+ IPv4 prefixes, plus ~200,000 IPv6.

Each router needs enough memory to hold the full table (if it's running "full tables"). Carrier-grade routers have many gigabytes of RAM dedicated to BGP.

Smaller networks can run "partial tables" or "default + customers" and avoid the memory cost.

What a hosting company does with BGP

For a hosting business:

Get your own ASN and prefixes. Year 1 setup.

Set up BGP peering with multiple upstreams. Diversity is essential.

Filter announcements both directions. Drop nonsense; only announce your own.

Validate RPKI. Accept the security improvement.

Monitor your routes. Tools like RIPE Stat, bgp.he.net let you see how the world sees your prefixes.

Use communities offered by upstreams to fine-tune routing.

Add anycast where useful (more on anycast in a later article).

This work is mostly done once, then monitored. It's also the work that distinguishes "a hosting company with its own network" from "a hosting company reselling someone else's service."

What BGP gives you, what it doesn't

BGP gives you:

• Global reachability for your prefixes.
• Failover when paths fail.
• Operator control over policy.

BGP doesn't give you:

• Performance optimization at the packet level.
• Per-application routing.
• Cryptographic identity (RPKI helps but doesn't fully solve).
• Per-hop visibility for end-users.

Other tools (traffic engineering protocols, segment routing, custom anycast deployments) complement BGP for specific needs.

Conclusion

BGP is the protocol that makes the internet's routing actually work. It's old (the current version, BGP-4, dates to 1994), occasionally fragile, and operationally complex, but it has scaled with the internet for three decades.

Most users will never interact with BGP directly. Operators and network engineers live in it daily. For hosting companies, BGP knowledge is the difference between being a tenant on someone else's network and operating an actual independent network.

The next time you hear about a "BGP issue" causing internet outages, you'll understand what's happening: somewhere, an AS announced something it shouldn't have, and the rest of the network is sorting it out.

Coming up

We've seen the basic BGP machinery. Next: BGP hijacks and RPKI in detail, the routing security problem and how the industry has slowly addressed it.