🌍 Routing, ASNs and BGP

Routing, ASNs and BGP

There is no "the internet". There are tens of thousands of independently operated networks that have agreed to carry each other's traffic, and one protocol — BGP — through which they tell each other what they can reach. Nobody is in charge of the result. Understanding that is the difference between "the internet is down" and "our transit provider is preferring a longer path through an IXP that is dropping our packets".

Autonomous systems

An autonomous system is one network under a single routing policy: an ISP, a university, a bank, a cloud provider, a large CDN. Each is identified by an AS number. ASNs were originally 16-bit; RFC 6793 extended them to 32-bit, so you will see both AS15169-style small numbers and values above 65535. Ranges worth knowing: 64512–65534 and 4200000000–4294967294 are private use (RFC 6996), and 64496–64511 is reserved for documentation (RFC 5398) — which is what the examples below use.

Address space follows a delegation chain: IANA allocates large blocks to the five Regional Internet Registries — ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC — which allocate to ISPs and large end users, who assign to customers. The IANA IPv4 free pool was exhausted in February 2011, and the RIRs have since worked from small final allocations, waiting lists and recovered space, which is why IPv4 addresses now have a resale market and IPv6 deployment finally moved. The registry data is public: look up registration data over RDAP → or find which AS owns an address →.

IGP versus BGP

Inside one AS, an interior gateway protocol — OSPF (RFC 2328) and IS-IS flood link state between your own routers and compute shortest paths by a metric like link cost, while EIGRP is an advanced distance-vector protocol that uses the DUAL algorithm rather than a link-state database. It optimises for speed and convergence, and it assumes every participant is trusted.

Between autonomous systems, BGP-4 (RFC 4271) does something different. It runs over TCP port 179 between explicitly configured neighbours, and it is a path vector protocol: every announcement carries the full list of AS numbers it has traversed. That AS_PATH prevents loops (a router rejects any route already containing its own ASN) and encodes policy. BGP does not look for the fastest path — it looks for the path your business relationships say to prefer. Two networks in the same city can exchange traffic via a third continent if that is what the policies produce.

How a route is chosen

A router usually hears the same prefix from several neighbours and must pick one to install. Implementations differ in detail, but the decision runs roughly in this order, stopping at the first tie-break that resolves:

router> show ip bgp 203.0.113.0/24
   Network            Next Hop        LocPrf  Path
*> 203.0.113.0/24     198.51.100.1       150   64496 64510 i
*  203.0.113.0/24     198.51.100.5       100   64497 64505 64510 i

The *> marks the chosen route: higher local preference, and also a shorter AS path. Prepending your own ASN several times to an announcement is the standard blunt tool for pushing traffic onto the other link — you are deliberately making step 2 go against you.

Prefix length is not on that list, and this is the single most important thing to internalise. The decision process picks the best path for one prefix. Forwarding then uses longest-prefix match: given routes for both 203.0.113.0/24 and 203.0.113.128/25, a packet to 203.0.113.130 follows the /25, whatever the AS paths say. More specific always wins, and it wins in a different table than the one BGP's tie-breakers apply to.

Transit, peering and IXPs

• Transit — you pay a provider to carry your traffic to and from the entire internet. They announce your prefixes to everyone.
• Peering — two networks exchange traffic between their own customers directly, usually settlement-free. Crucially, a peer announces only its own and its customers' routes, not its transit routes: peering does not give you the rest of the internet.
• IXP — an internet exchange point is a shared layer-2 fabric where many networks meet in one facility, often peering multilaterally through a route server so one BGP session reaches dozens of participants.

A "tier 1" network is one that reaches the whole default-free zone through settlement-free peering alone, buying transit from nobody. The default-free zone itself is the set of routers that hold a full table — on the order of a million IPv4 prefixes, and growing — with no default route.

Anycast

Anycast is the same prefix announced from many locations at once. Routing does the load balancing for free: every network's own best-path calculation sends packets to whichever instance is nearest to them, so 8.8.8.8 (Google Public DNS) and 1.1.1.1 (Cloudflare's resolver, run with APNIC) answer from a nearby site almost anywhere on earth, from one address. The root DNS servers work the same way: 13 server identities, served from many hundreds of physical instances worldwide.

Anycast suits stateless request/response traffic best, because nothing guarantees that two packets take the same path. In practice routes are stable for long enough that TCP and TLS work fine over anycast — that is how anycast CDNs and DDoS scrubbing operate — but a route change mid-connection resets it, so long-lived sessions are usually handed off to a unicast address.

When routing goes wrong

BGP has no built-in notion of who is allowed to announce a prefix. A neighbour's announcement is accepted because you configured a session with them, not because it was proved correct. Two failure classes follow:

Prefix hijacking — an AS originates a prefix it does not hold. Announcing a copy of someone's /16 competes with the real one and wins only where the path looks better. Announcing a more specific block inside it — a /24 carved out of that /16 — wins everywhere the announcement is accepted, because forwarding uses longest-prefix match and never consults the AS path. Traffic for those addresses is then delivered to the announcing network instead of the real owner. It either disappears (a blackhole, seen by users as a hard outage) or, if the hijacker maintains a working path back to the legitimate network, is inspected or modified and forwarded on, which users may not notice at all. Two well-documented cases: in February 2008 Pakistan Telecom (AS17557) announced 208.65.153.0/24, a more specific of YouTube's 208.65.152.0/22, intending a domestic block; the announcement escaped to a transit provider and took YouTube globally offline for a couple of hours. In April 2018 more-specific announcements covering Amazon Route 53 DNS servers were used to hijack DNS resolution for a cryptocurrency wallet site and serve a phishing page.

Route leaks are usually accidents rather than attacks: a network re-announces routes it learned from one provider or peer to another, in violation of the intended policy (RFC 7908 catalogues the patterns). Suddenly a small regional ISP looks like the shortest path between two continents, and a fraction of the internet's traffic tries to fit through its links. The result is congestion, packet loss and latency rather than interception — and it is far more common than deliberate hijacking.

The defences

RPKI (RFC 6480) is a public key infrastructure over IP address space. A holder publishes a signed Route Origin Authorisation — a ROA stating "AS 64496 may originate 203.0.113.0/24, with a maximum prefix length of /24". Routers fed by validation software (via the RTR protocol, RFC 8210) then label each announcement with an origin-validation state, defined in RFC 6811:

So when the site's BGP and ASN intelligence tool → reports RPKI invalid, it means the announcement contradicts what the address holder signed. That is exactly the signature a more-specific hijack leaves — but it is far more often a misconfiguration: a ROA created with maxLength /24 while the operator announces /25s, or a prefix moved to a new ASN without updating the ROA. Treat it as "this will be dropped by a growing number of networks, and someone should fix it", then investigate.

RPKI origin validation only proves the first AS in the path is authorised. It says nothing about the rest of the AS_PATH, so it does not stop a leak that keeps the real origin intact. Work on validating the path itself continues — ASPA is in development, and BGPsec (RFC 8205) specifies full path signing but has seen essentially no deployment because of its cost. The other layers in current use:

• IRR filtering — operators build prefix filters from route/route6 objects published in internet routing registries. Widely used, but only as trustworthy as the registry: some databases accept objects with weak authorisation, and stale entries are common.
• Prefix limits and maximum-prefix shutdown — a session that suddenly offers ten times the expected number of routes is almost certainly leaking, and is best torn down automatically.
• MANRS — an industry initiative defining a baseline of four actions for network operators: filter announcements from customers, prevent source-address spoofing (BCP 38 / RFC 2827), maintain contact and routing data, and participate in global validation by publishing ROAs and registry objects.

None of this is exotic to check. Look up your own address with the BGP tool →: it shows the covering prefix, the originating AS and the RPKI state, which is the same view a peer's filters have of you.