The internet is not one network with a center. It is tens of thousands of separately owned networks, each with its own number, joined by contracts: some pay others to carry their traffic, some swap traffic for free, and many meet on shared switches in a few hundred buildings. This chapter draws that graph, shows why its shape keeps changing, and counts the routes it costs every router to carry.
Common mix-up: "tier 1" does not mean "biggest." It means transit-free: a network that reaches every destination through its own customers and through peers, without paying anyone for transit. A content network can carry more traffic than many tier 1s and still buy some transit, and a tier 1 can be modest in size. The label describes a position in a web of contracts, not a size.
If BGP, peering and anycast are new to you, start with dynamic routing on networks.jelia.nyc, which introduces BGP as the internet's policy protocol and shows anycast in one picture. This chapter assumes that and zooms out to the whole graph.
The unit of the internet's map is the autonomous system, or AS. RFC 1930 defines it as "a connected group of one or more IP prefixes run by one or more network operators which has a SINGLE and CLEARLY DEFINED routing policy." In practice an AS is an organization's network as the rest of the internet sees it: an access provider, a university, a cloud, a bank, a content network. Each has an AS number (ASN), and each speaks BGP to its neighbors, announcing the address blocks it originates and passing on the ones it is willing to carry. Chapter 8 covers how those sessions work.
How many are there? Geoff Huston's annual report, measured from one vantage point, counted about 77,900 ASes visible in the IPv4 BGP table in January 2026. Only about 11,400 of them were transit ASes, meaning they appear in the middle of some path and so carry traffic for others. The other 66,500 were stubs: networks that appear only at the end of paths, originating their own addresses and nothing else. In IPv6 the same report counted about 36,100 ASes. Most of the internet, by count, is edges.
Between any two ASes there is usually one of three business relationships, and Chapter 9 is all about them: a customer pays a provider for transit to the whole internet; two peers exchange traffic between their own customers, usually without payment. Those contracts, not distance, decide which paths exist. This chapter is about the shape they give the graph.
BGP-4 (RFC 4271) carried AS numbers in two bytes, so there could only ever be 65,536 of them, and some were reserved. By the mid-2000s the registries could see the end of that pool. RFC 4893 (2007), later replaced by RFC 6793 (2012), widened the field to four bytes: 232, about 4.29 billion values.
The hard part was the transition, because the internet cannot upgrade every router at once. The solution has three pieces. Two speakers that both support four-byte ASNs say so when the session opens and then simply send four-byte paths. Toward an old speaker, a new one writes its AS path in two-byte form and replaces any number that does not fit with a reserved placeholder, AS_TRANS, which is AS 23456. The true four-byte path rides along in a new optional transitive attribute, AS4_PATH, which old routers pass on without understanding. When the route reaches a new speaker again, it rebuilds the real path from the two.
Old two-byte numbers stay valid: they are four-byte numbers whose top two bytes are zero. That is why you will see some networks described in "asdot" form, such as 1.0 for 65,536, and most tools today print the plain decimal.
The traditional picture is a pyramid. At the top is a small group of tier 1 networks. Each one buys transit from nobody: it can reach every address on the internet through its own customers or through settlement-free peering with every other tier 1. Below them, tier 2 networks are regional or national providers that peer where they can but still buy transit from someone above to reach the rest. At the bottom, tier 3 and stub networks buy all their connectivity.
The model is useful because it explains a basic shape: a packet between two distant stub networks usually climbs from customer to provider, crosses at most one peering link near the top, and descends from provider to customer. That is the valley-free pattern, and Instrument 1 below computes it.
But the tier labels are fuzzy for several reasons. Contracts are private, so nobody outside knows for sure who pays whom; researchers infer relationships from public BGP data, as CAIDA does in its AS relationships dataset, and inferences can be wrong. Relationships are not all-or-nothing: a network can buy partial transit (routes to one region only), pay for peering, or peer in one country and sell transit in another. And "transit-free" depends on the day: if two would-be tier 1s stop peering in a dispute, each loses reachability to the other's customers until someone pays. For these reasons this chapter will not name or rank commercial networks as tier 1; the CAIDA dataset and its "customer cone" ranking are the place to look for evidence-based numbers.
The internet has flattened. Through the 2000s, large content and cloud networks began building their own long-haul backbones and connecting directly to the access networks where their users are, at exchange points and through private links. A 2008 measurement study by Gill, Arlitt, Li and Mahanti called this "the flattening internet topology," and a 2010 study by Labovitz and colleagues found, in traffic data from many providers, that a growing share of inter-domain traffic flowed directly between content or hosting networks and consumer networks, bypassing the traditional top tier. Huston's 2025 report describes the same economics from the routing side: content and services are increasingly delivered by "fewer, but far larger, service platform operators." The pyramid still exists for reachability, but most of the bytes people actually use travel a much shorter, flatter path.
An AS's customer cone is the set of ASes it can reach by going only downhill: its customers, their customers, and so on. It is a good proxy for a network's position in the transit market, and CAIDA publishes rankings by cone size. Inferring the cone requires knowing which links are customer-to-provider, which is not announced anywhere.
The classic method comes from Lixin Gao's 2001 paper on inferring AS relationships: in a valley-free path, the highest-degree AS is probably the top of the hill, links before it go uphill and links after it go downhill. Later work, notably Luckie and colleagues at CAIDA in 2013, improved accuracy by first finding a clique of transit-free networks at the top and then propagating constraints down, and validated the results against operator-reported data and BGP communities. The answer is still an inference with error bars, which is one more reason tiers are a model, not a fact.
A synthetic internet built from documentation AS numbers: three transit-free networks at the top that all peer with each other, four regional providers, one content network and six stubs. Solid lines are customer-to-provider links (the provider is the upper end); dashed lines are peering. Tap a network to choose where a packet starts, then tap another for where it goes, or use the menus. The instrument runs BGP route selection with the standard commercial rules (prefer routes learned from customers, then peers, then providers; then the shorter AS path; export peer and provider routes only to customers) and draws the path that results in cobalt. If the plain shortest path through the graph is different, it is drawn dashed in red, with each step marked ↑ (to a provider), → (to a peer) or ↓ (to a customer). Then switch on the exchange point and watch paths shorten.
Exchange members when switched on: AS64500, AS64503, AS64510, AS65538 and AS65541, all peering through a route server, AS64511. Notice that AS64511 never appears in a path.
Peering two networks needs a physical link between them. Doing that one cable at a time scales badly: a network that wants to peer with 200 others would need 200 links. An internet exchange point (IXP) solves the physical half. It is a shared layer-2 switching fabric, usually Ethernet, spread across one or more data centers in a city. Each member brings a router, buys a port on the fabric and gets an address on the exchange's shared subnet. From then on every other member is one hop away on the same LAN.
The fabric does not decide anything about routing. Members still choose who they exchange routes with, and there are two ways to do it.
Two details make the route server work, and both are in RFC 7947. First, the route server is not in the forwarding path: it passes each route on with the NEXT_HOP unchanged, so packets go straight from one member's router to the other's across the fabric. Second, it does not prepend its own AS number to the AS path, because it is not a network the traffic crosses, and adding a hop would make paths through the exchange look longer than they are. To a member's router, a route learned from the route server looks exactly as if it came straight from the member that originated it.
Where do members find each other? PeeringDB is the public registry: in its own words "a freely available, user-maintained, database of networks," exchanges and facilities. A network's PeeringDB record lists which exchanges and buildings it is present in, its ASN, its peering policy (commonly described as open, selective or restrictive) and contacts. Operators check it before ordering a port, and many automate their route-server and bilateral configurations from it.
The alternative to the shared fabric is a private network interconnect (PNI): a dedicated cross-connect cable between two networks' routers in the same building. A PNI makes sense once two networks exchange enough traffic to fill whole ports, because then the shared fabric's port fees buy nothing extra, and a dedicated link isolates the pair from congestion or outages on the exchange. Big content networks and big access networks are often joined by many parallel PNIs.
| How you reach another network | Who pays | Routes you get | Scales to |
|---|---|---|---|
| Transit | You pay your provider, usually per Mb/s at the 95th percentile | The whole internet | Everything, at a per-unit price |
| IXP, route server | You pay the exchange for a port; peers usually settlement-free | The routes of every member that shares with the route server | Hundreds of peers per port |
| IXP, bilateral | Same port; one session per agreement | That peer's own and customer routes | As many as you negotiate |
| Private interconnect (PNI) | Cross-connect and router ports; split by agreement | That peer's own and customer routes | One peer, but whole ports of capacity |
A route server runs the BGP decision process on behalf of its clients, and that creates a subtle problem RFC 7947 calls path hiding. Suppose two members both offer a route to the same prefix, and the route server picks one as best. If the member that originated the best route has told the route server not to share it with a third member, the third member should still get the second-best route. A simple route server with a single shared best-path table would send nothing, and the third member would lose a path it was entitled to. RFC 7948 notes that the only fix that needs nothing from the clients is for the route server to keep a separate table (Loc-RIB) per client, at a cost in memory and CPU that grows with the number of paths times the number of clients.
Members steer what the route server does with their routes using BGP communities (RFC 1997), for example "do not announce to this member." Because the route server sees every member's routes, it is also the natural place to filter: RFC 7948 describes building filters from Internet Routing Registry data so a member cannot announce space it has no business announcing. Chapter 11 covers origin validation with RPKI, which exchanges increasingly apply too.
The exchange LAN itself needs care. RFC 7454 recommends that networks not accept more-specific routes for the IXP LAN prefix from outside, since someone announcing them could pull exchange traffic away from the fabric.
Why does a network peer at all? Mostly because transit is billed by volume and an exchange port is billed by capacity. Transit is commonly priced per megabit per second per month, measured at the 95th percentile of five-minute samples, so the bill rises in a straight line with traffic. A peering port costs roughly the same each month whatever you send through it, up to the port's capacity. Below some volume, transit is cheaper; above it, peering wins. That crossover is the break-even point.
Real decisions are messier than one formula. Peering also needs a router at the exchange and backhaul to it; a port is shared by traffic to many peers, so its cost is spread across all of them; the traffic you can move depends on which networks show up and agree to peer; and there are reasons to peer that are not about price at all, such as lower latency, more control over the path and resilience when a transit provider has a bad day. Equally, you never stop buying transit, because peering only reaches the peers and their customers. The model below is deliberately small so you can see the shape of the trade.
Every price here is illustrative, not market data. Set how much traffic you exchange with one destination network and what the three options cost you. The chart plots the monthly cost of each option across traffic volumes on logarithmic axes; the dot marks your traffic, and the cheapest option there is ringed. The model assumes you add a port or link whenever one would pass 70% utilization, which is why the peering lines climb in steps.
Anycast means announcing the same prefix from several places at once and letting BGP deliver each user to one of them. The DNS root servers and most large DNS and content services use it. The networks site shows the idea; here is how it actually behaves.
"Nearest" means nearest by BGP's rules, not by distance. Each network along the way picks one route to the anycast prefix using its own decision process: local preference first, which mostly encodes who pays whom, then AS path length, then tie-breakers such as the IGP cost to the exit. The set of users that end up at a given site is called its catchment, a word RFC 4786 borrows from river geography. A user in one city can be sent to a site on another continent because their provider's transit happens to reach that site in fewer AS hops, or because a peering link prefers it. Operators measure catchments; they do not assume them.
A host route cannot travel the internet. Networks commonly filter announcements longer than a /24 in IPv4 (Huston's 2025 report calls /24 the common minimum), so a single anycast address has to be announced inside a covering prefix, such as 203.0.113.0/24, and the whole block moves together.
RFC 4786, the best-current-practice document on operating anycast services, lists what can go wrong. The main hazards, in the order an operator meets them:
Anycast is also a defensive tool. A flood of traffic aimed at an anycast address is divided among the catchments of all its sites instead of landing on one, and a site that is overwhelmed can be withdrawn so its users drain elsewhere while the attack is absorbed by the rest. The same property makes it hard to tell, from one place, which site you are talking to; RFC 4786 discusses ways for clients and operators to identify the node that answered. Announcing someone else's prefix from an unauthorized place looks, to the routing system, exactly like adding an anycast site, which is why origin validation matters: see Chapter 11.
A router in the default-free zone has no default route: it carries an explicit route for every reachable prefix on the internet. The size of that table is one of the most-watched numbers in networking, because every entry costs memory and lookup work in every such router. Geoff Huston has published a report on it every January for many years; the figures below are his, rounded, measured at the start of each year from his own vantage point (other places in the network see slightly different numbers).
| January | IPv4 routes | of which more-specifics | IPv6 routes | of which more-specifics | IPv4 ASes |
|---|---|---|---|---|---|
| 2022 | 906,000 | 486,000 | 146,500 | 88,700 | 72,800 |
| 2023 | 940,000 | 495,000 | 172,400 | 103,000 | 74,200 |
| 2024 | 943,000 | 486,000 | 201,200 | 117,200 | 75,300 |
| 2025 | 996,000 | 526,000 | 221,500 | 127,500 | 76,700 |
| 2026 | 1,050,000 | 544,000 | 241,800 | 137,900 | 77,900 |
Two things stand out. First, IPv4 is still growing, by about 53,000 entries between January 2024 and January 2025 and 54,000 in the following year, by the report's own table, even though the registries ran out of fresh IPv4 addresses years ago. Address trading and subdividing explain much of it: big blocks are being sliced up and sold, and each slice needs its own route. Second, more than half of the IPv4 table, 544,000 of 1,050,000 entries in January 2026, consists of more-specifics: prefixes that sit inside a larger prefix that is also announced. Every one of those is, in principle, redundant for reachability.
So why announce them? This is deaggregation, and the usual reasons are traffic engineering (announcing halves of a block through different providers to steer incoming traffic, the technique Chapter 9 covers), multihoming a small piece of a provider's block, and defending against hijacks of more-specifics, since the longest match wins. Huston questions how well the last one works in IPv6, where many networks accept prefixes much longer than the /48 that most deaggregators use. The size distribution is lopsided: /22, /23 and /24 prefixes together made up 84% of the IPv4 table at the end of 2025, and /48s about 45% of IPv6.
What does it cost? Each route sits in the router's RIB, with all its paths and attributes, in ordinary memory, and in the FIB, the forwarding table on each line card, often in expensive fast memory such as TCAM. Chapter 2 explains why a line rate lookup needs that hardware, and how tries compress the table. When a FIB fills, routers can start dropping routes or falling back to slow paths; operators plan hardware purchases around projections like Huston's.
Each point is a figure from Huston's January reports, as listed under Sources; nothing between the points is interpolated data, just a line to guide the eye. Tap or move across the chart to read a year. Switch views to split each year into root prefixes and more-specifics (available for 2022 to 2026 in the 2026 report).
Pick a block you hold and the prefix length you choose to announce it as. Splitting a block of length a into prefixes of length b creates 2b−a routes, and every default-free router on the internet has to carry each one. The bar shows the block divided into its announced pieces.