When you send a packet from your laptop to a server in Singapore, dozens of routers decide where it goes — none of them have a complete map of the internet. They all share fragments of routing information through a protocol called BGP, and somehow it works. Most of the time.
BGP — the Border Gateway Protocol — is the glue that holds the internet together. It’s the protocol that lets autonomous systems tell each other “I can reach this set of IP addresses” and decide which paths to use to reach the rest of the world.
This post explains how BGP actually works, why it’s a fundamentally trust-based system, the famous outages it has caused, and what it means for anyone building or operating internet-connected services.
The Problem BGP Solves
The internet is roughly 100,000 autonomous systems. Each AS announces which IP prefixes it owns. Every other AS needs to know:
- Which prefixes exist.
- Which AS owns each one.
- The shortest path through other ASes to reach each owning AS.
There’s no central directory. No single authority knows the whole table. The information is built up by every AS gossiping with its direct neighbors and propagating what it learns.
BGP is that gossip protocol. It’s not optimal in any mathematical sense. It’s a political compromise that scales to global routing tables of ~1 million IPv4 prefixes and several hundred thousand IPv6 prefixes.
How a BGP Conversation Works
When two ASes want to exchange traffic, they set up a BGP session — typically a TCP connection on port 179 between their border routers. Once the session is established, each side sends UPDATE messages:
"I can reach prefix 104.18.0.0/16 via my AS"
"I can reach prefix 8.8.8.0/24 via AS3356 → AS15169"
"Withdraw: 192.0.2.0/24 (I can no longer reach it)"Each UPDATE includes the AS path — the sequence of autonomous systems traffic would traverse to reach the announced prefix. AS paths get longer as announcements propagate further from their source.
When a router has multiple paths to the same prefix, it picks one based on a policy. The decision factors, in roughly the standard order:
- Local preference (set by the AS operator — “prefer paths through this peer”).
- AS path length (shorter is preferred).
- Origin type (IGP, EGP, or incomplete).
- MED (Multi-Exit Discriminator) — a hint from the peer.
- eBGP vs iBGP — external sessions usually preferred.
- Lowest router ID — tiebreaker.
The result is a per-router routing table that says “for traffic destined to prefix X, send it out interface Y to AS Z.”
Policy, Not Math
Here’s the key thing that confuses people: BGP doesn’t choose the shortest or fastest path. It chooses the path that matches the AS operator’s policy. Operators set policy based on business relationships:
- Transit — you pay another AS to deliver your traffic to the rest of the internet. Your transit provider is everyone’s expensive default fallback.
- Peering — two ASes exchange traffic directly, usually for free or for nominal cost. Peering reduces transit bills and improves performance.
- Customer — an AS pays you to deliver their traffic. They’re your customer; you announce their prefixes to others.
Operators configure BGP to:
- Prefer customer routes over peering routes over transit routes (more revenue from customers, lower cost via peering, highest cost via transit).
- Withhold customer routes from competitors.
- Send only specific prefixes to specific peers.
- Prepend their own AS multiple times on certain announcements to make paths look longer (a tactic to influence inbound traffic).
So a packet’s path through the internet is shaped by who is paying whom — not who has the fastest cable.
Why This Matters for Your Application
A few practical implications:
Network paths change
BGP advertises new prefixes and withdraws old ones continuously. A packet from your laptop to a server might take different paths minute to minute. If your application is sensitive to latency or jitter (real-time gaming, voice/video calls), you’ll see the symptoms.
Routing isn’t symmetric
The path from A to B is not necessarily the reverse of the path from B to A. Different operators along the way have different policies. This is a common surprise when debugging connectivity issues.
Geographic location of an IP isn’t the geographic location of the network path
Traffic to a server in Singapore might route through Frankfurt and Tokyo before getting there, depending on who has peered with whom. Your “local” CDN edge might actually be reached over an absurdly long path.
Performance optimization happens at the routing layer
The major CDN providers and cloud providers invest enormous engineering in BGP relationships — peering at as many internet exchanges as possible, getting traffic to the user via the shortest practical path. You don’t see this work; you just experience the result as “Cloudflare is fast.”
The Famous Failures
BGP is fundamentally trust-based: each AS announces what it owns, and other ASes believe it. There’s no built-in cryptographic verification that the announcing AS actually owns the prefix.
This has caused some of the largest internet outages on record:
Pakistan Telecom blocks YouTube (2008)
Pakistan Telecom’s order to block YouTube domestically resulted in them announcing YouTube’s IP range globally. Other ISPs around the world accepted the announcement (shorter AS path = more preferred), and YouTube traffic worldwide started routing into Pakistan Telecom’s null route. YouTube was offline for hours.
China Telecom hijacks (2010)
For 18 minutes, China Telecom announced ~37,000 prefixes belonging to other organizations. Some traffic — including from US government IP ranges — was briefly routed through Chinese networks.
Verizon’s Cloudflare leak (2019)
A small ISP in Pennsylvania announced ~70,000 prefixes (including Cloudflare’s) to Verizon. Verizon propagated the announcements without filtering. For about an hour, big chunks of internet traffic to major services were routed through small Pennsylvania networks that couldn’t handle the load.
Facebook’s DNS+BGP outage (2021)
During a maintenance event, Facebook’s automation withdrew the BGP announcements for the prefixes hosting their authoritative DNS. Without DNS, Facebook’s entire infrastructure became unreachable — including the internal tools they would have used to fix it. The outage lasted nearly six hours.
Cloudflare’s RPKI mishap (2023)
Cloudflare briefly mis-configured their RPKI validation (the system meant to prevent the above kinds of issues), causing some of their networks to drop legitimate routes. Result: significant outages affecting many large services for ~30 minutes.
The pattern: BGP is fragile not because it’s a bad protocol, but because it’s built on trust between humans and automated systems making continuous changes to a global state machine that ~all internet traffic depends on.
RPKI: The Slow Fix
The longest-running effort to make BGP less fragile is RPKI (Resource Public Key Infrastructure). RPKI lets the legitimate holder of an IP range cryptographically sign a statement: “AS X is authorized to announce this prefix.” Other ASes can validate announcements against these signatures and drop the invalid ones.
In 2026, RPKI adoption is finally meaningful — the major networks all validate, and rejection of unsigned or invalid announcements is becoming the norm. The remaining gap is in less well-managed networks where RPKI validation isn’t deployed.
The result: large BGP hijacks (intentional or accidental) are now much harder to pull off across the global core. Small-scale leaks still happen and probably always will.
What This Means for You
If you’re not a network operator, you don’t configure BGP. But several things about BGP affect your application:
Diversity matters for resilience
Hosting your service behind a single AS is a single point of failure. If that AS has a BGP issue, you’re down. Major cloud providers (AWS, GCP, Azure, Cloudflare) all operate from many ASes across many geographic regions specifically to mitigate this.
Latency to your users is path-dependent
If you have users in a region you’re not well-peered with, performance suffers — even if your servers are technically “close.” This is why CDNs and edge providers obsess about peering relationships.
Looking up an IP’s path tells you something
Tools like traceroute and mtr show the BGP-determined path between you and a destination. Each hop is a router, often with its own AS. Looking up the ASN of each hop gives you the network operators carrying your traffic.
IP geolocation is downstream of BGP
The geographic location of an IP is partly inferred from where the BGP announcements come from. If an AS is announcing a prefix from servers in Frankfurt, the prefix’s geo data leans toward Frankfurt. When BGP announcements shift (new peering, prefix moves between ASes), geo data needs to catch up.
Hosted IP geolocation APIs tend to update their data continuously by watching BGP routing tables. Offline databases lag because they only update on a download cycle. This is one of the structural advantages of hosted APIs over self-managed databases.
Looking at BGP in Action
A few tools:
traceroute / tracepath
Shows the path your packets take to a destination. Each hop is a router; the IP of each hop can be looked up to find the AS.
mtr
Continuous traceroute. Useful when paths are unstable — you’ll see hops appearing and disappearing.
Looking glass servers
Public services run by major ISPs that let you query their BGP state. Useful for debugging “is my prefix actually announced correctly?” Each big network operates one.
BGP routing inspectors
Online tools that show the current BGP announcements for any AS or prefix. Our ASN directory shows announced prefixes for each AS.
bgpdump / bgpreader
Command-line tools for reading historical BGP archives from RouteViews and RIPE RIS. If you need to know “what was BGP saying about this prefix at 14:32 UTC last Tuesday,” these are the tools.
When BGP “Should I Care?” Becomes “I Have To”
Most application developers don’t need to think about BGP day to day. The cases where you’ll be forced to:
- You’re running your own infrastructure with multiple uplinks. You’ll need to announce your prefixes via BGP and configure preferences.
- You’re operating in a region with unreliable connectivity. Understanding how your traffic is reaching users helps you choose better peering and CDN partners.
- You’re debugging an unexpected outage. Sometimes the answer is “an upstream AS leaked routes” and there’s nothing you can do but wait.
- You’re a CDN/cloud provider, or scaling toward one. BGP becomes one of your core competencies.
For everyone else, BGP is the invisible plumbing. It’s worth understanding the basics so you know what’s going on when something doesn’t work, but you can build excellent applications without ever touching it.
TL;DR
- BGP is how autonomous systems tell each other which IP prefixes they own.
- Routing decisions are policy-based, not shortest-path. Business relationships shape paths.
- The protocol is trust-based — historically vulnerable to hijacks and leaks.
- RPKI is finally fixing the worst cases in 2026 but adoption is still incomplete.
- For application developers, BGP mostly affects you indirectly — through latency, occasional outages, and the freshness of IP geolocation data.
- Tools like traceroute and ASN lookups let you peek at the routing layer when something breaks.
The internet “just working” most of the time is more impressive than most people realize. BGP makes ~5 billion concurrent users routable to each other across 100,000 networks via a protocol that’s basically a global game of telephone. The fact that it works at all is a small daily miracle.