BGP and Internet Routing: How Networks Find Each Other

There is no central map of the internet. No master server knows where every address lives, and no single company runs the wires. What actually exists is tens of thousands of separate networks, each run by a different organisation, that have agreed to carry each other's traffic. The protocol they use to tell one another "here is what I can reach, and here is the path to get there" is the Border Gateway Protocol, or BGP.

BGP is the reason a request from a laptop in Lisbon can find a server in São Paulo without either network knowing the whole route in advance. It is also, quietly, one of the more fragile parts of the internet: when BGP goes wrong, entire services can vanish for hours. This guide explains what BGP does, how it decides which way traffic should flow, and why a protocol this important was built on a foundation of trust that is only now being reinforced.

What BGP actually is#

BGP is a routing protocol. Its job is to spread reachability information between large networks so that every router, everywhere, eventually learns a way to reach every publicly routable block of addresses. The current version, BGP-4, is defined in RFC 4271, published in 2006, and it has been the glue of the global routing table ever since.

Two BGP routers form a session by opening a plain TCP connection to each other on port 179, then exchanging the routes they know about. Once the session is up, they only send changes: a new route becoming available, or an old one being withdrawn. There is no periodic re-broadcast of the entire table, which is what lets the system scale to well over a million routes without melting under its own chatter.

The unit BGP passes around is the prefix, a block of addresses written in CIDR form such as 203.0.113.0/24. That slash number defines how large the block is; if the notation is unfamiliar, our explainer on CIDR notation walks through it. A network announces the prefixes it is responsible for, and BGP carries that announcement, hop by hop, across the world.

Autonomous systems and the path they build#

Each of those independently run networks is called an autonomous system, and each one has a number that identifies it globally: an ASN. Your internet provider has one. So does every large hosting company, cloud, and content network. We have a full write-up on what an ASN is, but the short version is that an ASN is the licence plate of a network, and BGP is the conversation those networks have with each other.

ASNs were originally 16-bit numbers, which meant values from 0 to 65535. The internet outgrew that pool, so RFC 6793 extended them to 32 bits, raising the ceiling to 4,294,967,295. To let old and new equipment coexist during the transition, a single 16-bit value, AS 23456 (nicknamed AS_TRANS), stands in for any 32-bit number that a legacy router cannot understand.

What makes BGP distinctive is how it describes a route. It is a path-vector protocol: along with each prefix, BGP carries the full list of autonomous systems the announcement has already passed through, an attribute called the AS_PATH. When network A hands a route to network B, B prepends its own AS number to the front of that list before passing it on. So a route does not just say "you can reach this block"; it says "you can reach this block by going through these specific networks, in this order."

That running list does two useful things at once. It gives every router a rough sense of how far away a destination is, and it prevents loops for free: if a router sees its own AS number already in the path, it knows the route has circled back and discards it.

How BGP chooses a route#

A busy router hears about the same destination from several neighbours, each offering a different path. BGP has to pick exactly one to use and advertise onward. Two rules do most of the heavy lifting.

First, the most specific prefix always wins, before any other comparison happens. A router that knows a route to 203.0.113.0/24 and another to the larger 203.0.113.0/23 will send traffic for an address inside the /24 down the /24 route, because it is the tighter match. This "longest prefix match" rule is fundamental, and it turns out to matter enormously for security, as the next sections show.

When two candidate routes cover the exact same prefix, BGP walks a tie-breaking list of attributes. In practice the two that matter most are:

• Local preference — a value a network sets internally to express business policy, such as "prefer the link to our cheaper peer over our expensive transit provider." It is checked first, and it is why routing is shaped by commercial relationships as much as by geography.
• AS_PATH length — a shorter list of autonomous systems is generally preferred, on the reasoning that fewer networks in the way tends to mean a more direct route. It is a rough proxy for distance, not a real measurement of speed.

Only if those and several finer tie-breakers are equal does the router fall back to more mechanical choices. The important takeaway is that BGP does not pick the physically shortest or fastest path. It picks the path its operators' policies and the announced prefixes tell it to prefer, which is often a very different thing.

External and internal BGP#

BGP runs in two flavours that look similar but do different jobs. External BGP (eBGP) is the sessions between different autonomous systems: your ISP talking to a peering partner, a hosting company talking to its transit provider. This is the BGP that builds the global routing table.

Internal BGP (iBGP) runs between the routers inside a single large autonomous system, so that a network with dozens of border routers can share a consistent view of everything it has learned from the outside world. A small network with one router barely needs it; a global backbone depends on it. The distinction rarely matters to someone looking up a single address, but it explains why "one AS" can still be a sprawling internal network with routing of its own.

BGP runs on trust, and that is the problem#

Here is the uncomfortable part. BGP has no built-in way to check whether a network is allowed to announce the prefix it is announcing. When a router hears "I can reach 203.0.113.0/24," it has historically just believed the sender. The protocol was designed in an era when the handful of networks involved all knew each other, and that assumption never fully went away.

Combine that blind trust with the longest-prefix-match rule and you get BGP hijacking. If a network announces a more specific prefix than the real owner, routers worldwide prefer it, and traffic bends toward the wrong place. The classic case happened in February 2008, when Pakistan Telecom, trying to block YouTube domestically, announced a more specific route for part of YouTube's address space. The announcement leaked to the wider internet, and because it was more specific than YouTube's own, much of the world's YouTube traffic was drawn toward Pakistan and the site went dark globally for roughly two hours.

Not every outage is malicious. A route leak happens when a network accidentally re-announces routes it should have kept to itself, and a simple withdrawal can be just as damaging. In October 2021, Facebook withdrew the BGP routes to the prefixes hosting its own DNS servers during an internal change, and the company effectively erased itself from the global routing table for more than five hours. Nothing was hacked; the routes simply stopped being announced, and without a route there is no path.

Making routing safer: RPKI and filtering#

The main defence against origin hijacks is the Resource Public Key Infrastructure (RPKI), described in RFC 6480. It lets the legitimate holder of a block of addresses publish a cryptographically signed statement, a Route Origin Authorization (ROA), that says "autonomous system X is authorised to originate routes for this prefix." Other networks can then check incoming announcements against those signed records and drop the ones that fail, a process called route origin validation.

RPKI is not a complete fix. It validates who is allowed to originate a prefix, which stops the crude hijacks, but it does not verify the entire AS_PATH, so a more sophisticated forgery further along the path can still slip through. Work on path validation continues. Alongside it, networks apply plain prefix filtering, set sensible maximum-prefix limits on their sessions, and follow the community norms collected under the MANRS initiative. None of these is glamorous, and together they have measurably reduced how often a stray announcement takes a service offline.

Seeing BGP for yourself#

You do not need a router to observe BGP's fingerprints. Every public IP address you look up carries the traces of the routing decisions above. Our IP lookup returns the owning organisation and the ASN announcing an address, which is the origin end of every route we have been discussing. To go the other way, the ASN Explorer takes an autonomous system number and shows the organisation behind it along with the prefixes it announces to the world, which is precisely the set of blocks that AS is telling BGP it can reach.

From there, the CIDR calculator will expand any one of those prefixes into its address range, so you can see how much of the internet a single announcement covers. Together they let you trace a bare address back to the network that operates it and the footprint that network claims. For a real-world example of why that footprint is worth understanding, see how the big clouds publish theirs in our guide to AWS, Google Cloud, and Azure IP ranges, each of which announces its space through BGP just like everyone else.