Network & delivery

6 min readUpdated

What is BGP?

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.

An announcement propagating
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 it

02How 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.

StepPreferWhy it exists
1Highest local preferenceThe network's own policy, typically reflecting who pays whom
2Shortest AS pathFewer networks in between, as a rough proxy for distance
3Lowest origin typeHow the route entered BGP in the first place
4Lowest MED, among routes from the same neighbouring ASLets a neighbour hint at its preferred entry point
5Routes learned from another AS over internal onesHand the traffic on rather than carry it further
6Lowest interior cost to the next hopLeave the network at the nearest exit
7Lowest BGP identifierA 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.

TermWhat it means for you
BYOIPYou own the prefix; the provider announces it on your behalf
AnycastOne prefix from many locations, so attacks spread automatically
Null routeYour address announced to a blackhole — the flood stops, so does your service
Route leakAn 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.

Run with dig 9.18 and curl 7.88 in October 2026; output as returned
# 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

No. BGP matters to networks that announce their own address space. Using a CDN or WAF requires only a DNS change; your provider handles routing on their side.

A globally unique identifier for a network that participates in internet routing. Every announcement carries the AS numbers it passed through, which is what builds the path.

A hijack announces address space the network has no right to originate. A route leak passes legitimate routes on beyond their intended scope, such as a customer re-announcing one provider's routes to another. Origin validation checks who originated a route, so it catches many hijacks but not a leak of correctly originated routes.

The provider announces the protected prefix, so all traffic for those addresses reaches their network first and can be filtered there. The clean remainder is then delivered to your server, often through a tunnel.

It announces your address into a blackhole so the flood is discarded upstream. It protects the provider's network and leaves your service unreachable — worth knowing whether your provider does this before you need to know.

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.

  1. 01RFC 4271: A Border Gateway Protocol 4 (BGP-4) · IETF
  2. 02RFC 6811: BGP Prefix Origin Validation · IETF
  3. 03RFC 7454: BGP Operations and Security (section 6.1.3, prefix length) · IETF
  4. 04RFC 7999: BLACKHOLE Community · IETF
  5. 05YouTube Hijacking: A RIPE NCC RIS case study · RIPE NCC
  6. 06How Verizon and a BGP Optimizer Knocked Large Parts of the Internet Offline Today · Cloudflare
  7. 07Verify requests from Google crawlers and fetchers · Google
  8. 08IP to ASN mapping · Team Cymru
  9. 09RIPEstat Data API: rpki-validation · RIPE NCC

Last updated