Quick answer
BGP (Border Gateway Protocol) is how the internet's independent networks tell each other which blocks of IP addresses they can deliver traffic to. Each network — an autonomous system, identified by an AS number — announces its own address ranges to its neighbours, who pass those announcements on. There is no central authority deciding routes; the map assembles itself from what everyone claims. That design is what makes the internet resilient, and also why announcements are believed largely on trust.
01How routing decisions get made
An autonomous system is a network under one administrative control — an ISP, a hosting provider, a large company. Each has an AS number, and each announces to its neighbours: these address ranges are reachable through me.
The version in use is BGP-4, specified in RFC 4271. Neighbouring routers, called peers, talk over a TCP session on port 179 and pass announcements along, each adding its own AS number to the path. Nobody has the whole picture; every router makes a local decision from what it has been told.
AS 64500 announces 203.0.113.0/24
neighbour AS 64501 hears: 203.0.113.0/24 path: 64500
then AS 64502 hears: 203.0.113.0/24 path: 64501 64500
then AS 64503 hears: 203.0.113.0/24 path: 64502 64501 64500
shorter path usually wins — but policy can override it02How a router chooses between routes
When several neighbours offer a route to the same prefix, RFC 4271 defines the order in which they are compared, stopping at the first step that separates them. Real routers add vendor-specific steps, but the core sequence is the same everywhere.
| Step | Prefer | Why it exists |
|---|---|---|
| 1 | Highest local preference | The network's own policy, typically reflecting who pays whom |
| 2 | Shortest AS path | Fewer networks in between, as a rough proxy for distance |
| 3 | Lowest origin type | How the route entered BGP in the first place |
| 4 | Lowest MED, among routes from the same neighbouring AS | Lets a neighbour hint at its preferred entry point |
| 5 | Routes learned from another AS over internal ones | Hand the traffic on rather than carry it further |
| 6 | Lowest interior cost to the next hop | Leave the network at the nearest exit |
| 7 | Lowest BGP identifier | A deterministic tie-break when everything else is equal |
03Built on trust, and the consequences
BGP has no built-in way to verify that a network is entitled to announce a prefix. If an operator announces someone else's addresses, neighbours will generally accept it and traffic will follow — this is BGP hijacking, and it has happened repeatedly, sometimes by mistake and sometimes not.
The best-known case is YouTube on 24 February 2008. Pakistan Telecom announced 208.65.153.0/24, a more specific slice of YouTube's address space; its upstream provider propagated it worldwide, and YouTube traffic went to Pakistan for about two hours. YouTube's countermeasure was to announce even more specific /25s — the longest-prefix rule working in its favour.
- RPKI lets a prefix holder sign a statement of which AS may originate it; under RFC 6811, routers classify each route as Valid, Invalid or NotFound
- IRR databases record intended routing policy for filtering
- Prefix filtering between neighbours catches obviously wrong announcements; RFC 7454 notes that IPv4 prefixes longer than /24 and IPv6 prefixes longer than /48 are generally neither announced nor accepted
- Adoption is partial, so the internet still runs substantially on trust
04Why it matters for DDoS protection
Routing is how packet-level protection is delivered. If a provider announces your prefix, all traffic for those addresses arrives at their network first — that is the mechanism by which scrubbing becomes possible at all. The clean traffic then has to reach you, usually through a tunnel, which is the model described in remote DDoS protection.
Because a /24 is the most specific IPv4 prefix that is widely accepted, it is also the smallest block that can be diverted this way: protecting a single address by BGP means moving the whole /24 it sits in.
Routing also underpins anycast: the same prefix announced from many locations, so each visitor reaches whichever instance is nearest, and an attack is divided by the same routing that divides real traffic.
And it is behind the least pleasant word in the industry: null-routing. When a provider decides an attack is not worth absorbing, they can announce your address into a blackhole, discarding the flood — and your legitimate traffic with it. RFC 7999 even standardises the signal, the BLACKHOLE community 65535:666.
| Term | What it means for you |
|---|---|
| BYOIP | You own the prefix; the provider announces it on your behalf |
| Anycast | One prefix from many locations, so attacks spread automatically |
| Null route | Your address announced to a blackhole — the flood stops, so does your service |
| Route leak | An announcement escaping past its intended scope, sending traffic the wrong way |
05What an AS number tells you about an address
Because every address block belongs to an announced prefix, you can map any IP address to the AS that announces it. That is more informative than the address alone: it tells you whether a visitor is on a residential ISP, a hosting provider, a cloud platform or a large company's own network. The IP and ASN lookup does this for any address.
It is also a quick sanity check on claimed identities. A request calling itself Googlebot from a network that is not Google's deserves suspicion, although Google's own documented checks are a reverse DNS lookup confirmed by a forward lookup, or a match against the IP ranges it publishes as JSON files.
And it is why blanket-blocking a whole AS is a blunt instrument: hosting networks carry legitimate API clients, monitoring and VPN users alongside automation.
06Looking up routing data yourself
Public services answer the common questions without a router of your own. Team Cymru serves IP-to-AS mappings over DNS, and RIPEstat exposes the RIPE NCC's routing data, including RPKI status, as a JSON API. The example address belongs to the RIPE NCC itself.
To see the networks your own traffic crosses, a traceroute with AS lookups does the job; reading a traceroute and MTR explains what each hop means.
# which AS announces this address, and in which prefix? (octets reversed)
dig +short TXT 139.6.0.193.origin.asn.cymru.com
"3333 | 193.0.0.0/21 | NL | ripencc | 1993-09-01"
# who is AS3333?
dig +short TXT AS3333.asn.cymru.com
"3333 | NL | ripencc | 1994-05-19 | RIPE-NCC-AS - Reseaux IP Europeens Network Coordination Centre (RIPE NCC), NL"
# is AS3333 a valid RPKI origin for 193.0.0.0/21?
curl -s 'https://stat.ripe.net/data/rpki-validation/data.json?resource=3333&prefix=193.0.0.0/21' \
| grep -o '"status": *"[a-z_]*"'
"status":"ok"
"status":"valid"Questions
Frequently asked questions
Sources
Sources and verification
dig and curl commands run on Debian 12 (dig 9.18.49, curl 7.88.1) in October 2026; the output shown is what they returned.
- 01RFC 4271: A Border Gateway Protocol 4 (BGP-4) · IETF
- 02RFC 6811: BGP Prefix Origin Validation · IETF
- 03RFC 7454: BGP Operations and Security (section 6.1.3, prefix length) · IETF
- 04RFC 7999: BLACKHOLE Community · IETF
- 05YouTube Hijacking: A RIPE NCC RIS case study · RIPE NCC
- 06How Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Today · Cloudflare
- 07Verify requests from Google crawlers and fetchers · Google
- 08IP to ASN mapping · Team Cymru
- 09RIPEstat Data API: rpki-validation · RIPE NCC
Last updated