Autonomous systems, AS numbers and BGP, explained
The Internet is a network of networks, and each of those networks is an autonomous system (AS) with its own number. Autonomous systems tell each other which addresses they can reach using the Border Gateway Protocol (BGP). When a site is unreachable from one country but fine from another, the answer is usually somewhere in BGP, and free public tools let you look.
What an autonomous system is
RFC 4271, the BGP-4 specification, gives the classic definition: a set of routers under a single technical administration. ARIN puts it in practical terms: a group of IP prefixes run under one clearly defined routing policy. Your ISP is an AS; so are cloud providers, content networks, universities and large companies. A network needs its own AS number mainly when it connects to two or more other networks (it is multihomed) and wants to control its own routing policy. A small business with one ISP normally uses the ISP’s AS.
AS numbers: 16-bit and 32-bit
IANA hands blocks of AS numbers to the five Regional Internet Registries (AFRINIC, APNIC, ARIN, LACNIC and the RIPE NCC), which assign them to networks. The original BGP carried AS numbers in 2 bytes, allowing 65,536 values (0 to 65535). That was not enough, so RFC 6793 (December 2012, replacing RFC 4893) extended them to 4 bytes: 4,294,967,296 values. ARIN notes that the transition began in 2007 and that all AS numbers should now be treated as 4-byte numbers.
Old routers that only understand 2-byte numbers see a newer 4-byte AS as AS 23456 (called AS_TRANS). If you see AS 23456 in a path, an old BGP speaker is involved somewhere, not a real network with that number.
| Range | Use |
|---|---|
| 0 | Reserved |
| 23456 | AS_TRANS (2-byte stand-in for 4-byte numbers) |
| 64496–64511 and 65536–65551 | Documentation and sample code |
| 64512–65534 | Private use (1,023 numbers) |
| 4200000000–4294967294 | Private use (94,967,295 numbers) |
| 65535 and 4294967295 | Reserved |
Private AS numbers work like private IP addresses: fine inside your own network, for example between a data center and a cloud provider, but they must be removed before routes reach the public Internet. The private 32-bit range is large: 4,294,967,294 − 4,200,000,000 + 1 = 94,967,295 numbers.
How BGP works
Two routers in different autonomous systems open a BGP session over TCP port 179. This is external BGP (eBGP). Routers inside the same AS share what they learned over internal BGP (iBGP). The protocol has four message types: OPEN starts a session, UPDATE announces or withdraws routes, KEEPALIVE confirms the session is still alive, and NOTIFICATION reports an error and closes the session.
Each announced route carries an AS_PATH, the list of autonomous systems it has passed through. Suppose AS 64500 originates the prefix 198.51.100.0/24 and passes it to AS 64501, which passes it to AS 64502. A router in AS 64502’s customer sees:
198.51.100.0/24 AS_PATH: 64502 64501 64500
Read from right to left, it shows the origin (64500) and the chain of networks. If a router sees its own AS number already in a path, it rejects the route, which prevents loops. When several routes to the same prefix are available, each network first ranks them by its own local policy (inside the AS this is carried as LOCAL_PREF); only among routes with equal preference does the shorter AS_PATH win. That is why BGP is a policy protocol more than a shortest-path protocol, and why traffic sometimes takes a surprisingly long route.
The most specific prefix wins in forwarding: if one network announces 198.51.100.0/24 and another announces 198.51.100.0/25, traffic for addresses in the /25 follows the /25. Accidental or malicious announcements of someone else’s addresses, called route hijacks or leaks, exploit exactly this.
Looking at real routing data
- Looking glasses
- Web pages, run by many networks, that let you run commands such as “show route” or traceroute from their routers. They show how the Internet looks from that network’s point of view.
- RouteViews
- A public archive of BGP data collected from peers at Internet exchange points and partner networks, supported by the Network Startup Resource Center at the University of Oregon. It offers routing tables and update archives (archive.routeviews.org), a looking glass (lg.routeviews.org) and an API.
- RIPEstat
- The RIPE NCC’s information service for IP address space and AS numbers, drawing on more than 35 datasets, with a web interface, embeddable widgets and a data API. Useful for registration details, routing history and abuse contacts.
- bgp.tools
- A free website for browsing the routing ecosystem: search by AS number (for example AS13335), prefix (8.8.8.0/24) or DNS name to see who announces it, its upstreams and peers.
A quick check when a network seems unreachable: look up the destination prefix in two of these tools, confirm which AS originates it, and compare the path from several looking glasses. A different origin AS from the one you expect is a red flag.
RPKI: checking who may announce what
BGP itself has no way to prove that an AS may announce a prefix. The Resource Public Key Infrastructure (RPKI) adds that. Address holders get a certificate from their RIR and publish signed Route Origin Authorizations (ROAs): “AS 64500 may announce 198.51.100.0/22, up to /24.” The RIPE NCC and the other RIRs offer hosted RPKI, or networks can run their own certificate authority.
Routers then do route origin validation, defined in RFC 6811 (January 2013). Each route gets one of three states:
- Valid: a ROA covers the prefix, the length is within the maximum, and the origin AS matches.
- Invalid: a ROA covers the prefix, but the origin AS or length does not match. Networks that enforce origin validation usually drop these routes.
- NotFound: no ROA covers the prefix.
The maximum length matters. A ROA for a /16 with a maximum length of /18 allows the /16, /17s and /18s, but a /19 would be Invalid. RFC 6811 is clear about the limit: origin validation checks only the origin AS, not the whole path, so it protects mainly against mistakes rather than determined attackers who fake the origin in the path.
Sources
- RFC 4271: A Border Gateway Protocol 4 (BGP-4), IETF
- RFC 6793: BGP Support for Four-Octet AS Number Space, IETF
- Autonomous System (AS) Numbers registry, IANA
- Autonomous System Numbers, ARIN
- RFC 6811: BGP Prefix Origin Validation, IETF
- Resource Public Key Infrastructure (RPKI), RIPE NCC
- RouteViews, University of Oregon
- RIPEstat, RIPE NCC
- bgp.tools