Autonomous System (AS)

An autonomous system (AS) is a connected group of IP prefixes. One or more network operators run it. It has “a SINGLE and CLEARLY DEFINED routing policy” (RFC 1930, section 3, BCP 6). This is the unit that inter-domain routing reasons about. Policy is not set per prefix. Instead, it is set “for groups of prefixes. These groups of prefixes are ASes.” Every AS has a globally unique Autonomous System Number (ASN). It is used “in both the exchange of exterior routing information (between neighboring ASes), and as an identifier of the AS itself”. The prefixes themselves are IPv4 or IPv6 address space. BGP is what carries them between ASes.

An AS is not a protocol. BGP is the protocol. The AS is what BGP routes between. An AS is also not a physical network boundary. It is not an ownership label either. Routing policy defines it. So one company may run several ASes, and one AS may hold thousands of prefixes. RFC 1930 warns against the usual mistake: treating an AS as a convenient administrative umbrella. “Without exception, an AS must have only one routing policy” (RFC 1930, section 4). In short: IANA and the regional registries hand out the numbers. Operators announce prefixes with BGP. The ASN is the handle that identifies a network in a routing table, a traceroute, or a WHOIS lookup.

How it works

1. Numbers are delegated, not chosen. IANA allocates blocks of AS numbers to the five Regional Internet Registries: AFRINIC, APNIC, ARIN, LACNIC and RIPE NCC. Then “the RIRs further allocate or assign AS Numbers to network operators in line with RIR policies” (IANA Autonomous System (AS) Numbers registry).
2. An announcement is an offer to receive traffic. An AS announces the prefixes it can reach over an exterior routing protocol. Announcing a prefix “means that ASX is willing to accept traffic directed to NET1 from ASY” (RFC 1930, section 3). It is not a request to send traffic.
3. The neighbour decides. The receiving AS has the privilege to use or disregard what it hears. So traffic reaches a prefix only when announcement and acceptance are both in place. The return direction needs the mirror image. Connectivity in one direction only “is not useful at all” (RFC 1930, section 3).
4. The AS_PATH records the ASes crossed. When a BGP speaker advertises a route to an external peer, it prepends its own AS number to the AS_PATH attribute. This attribute “identifies the autonomous systems through which routing information carried in this UPDATE message has passed”. To internal peers, the attribute is left unmodified (RFC 4271, section 5.1.2). AS_PATH is also the loop check. A route whose path already contains the local AS number is excluded from route selection (RFC 4271, section 9.1.2).
5. Interior and exterior routing are separate jobs. Inside the AS, interior gateway protocols carry internal reachability. OSPF and IS-IS are the RFC's examples (RFC 1930, section 8). To everyone else, the AS “appears to other ASes to have a single coherent interior routing plan and presents a consistent picture of what networks are reachable through it” (RFC 1930, section 3).
6. Two-octet, then four-octet. The AS number was originally a 16-bit integer, “and hence limited to 65535 unique AS numbers” (RFC 1930, section 9). BGP was extended to carry four-octet (32-bit) numbers. This was to prepare for “the anticipated exhaustion of the two-octet AS numbers” (RFC 6793, section 1). The same document reserves the two-octet number 23456, AS_TRANS. It stands in for a non-mappable four-octet number when the path is encoded for a speaker that does not support the extension (RFC 6793, section 3).
7. One number, two spellings. The standard notation is plain decimal. It is called “asplain” (RFC 5396, section 3). You will still meet asdot. Asdot writes values of 65536 and above as two 16-bit halves joined by a dot. So 65546 appears as “1.10” (RFC 5396, section 2).

Why it matters for a CDN

A CDN is an AS operator. Its AS is the delivery network. The CDN announces anycast prefixes from many points of presence. So one prefix is reachable in dozens or hundreds of places at once. Which place a given client reaches is not the CDN's decision to make directly. RFC 4786 explains: “the routing system decides which node is used for each request, based on the topological design of the routing system and the point in the network at which the request originates”. The same document adds that “topological nearness within the routing system does not, in general, correlate to round-trip performance across a network; in some cases, response times may see no reduction, and may increase” (RFC 4786, section 3). Edge performance is therefore an AS-level problem. It depends on who you peer with, at which internet exchange point, and what AS path a client's network actually prefers.

The ASN is also the identity you look up when you need to know which network answered. Resolve the hostname, then look up the AS that announces the returned address. Now you know whose network the request landed in. This is the practical check when validating a multi-CDN split, a failover, or a routing change. Those mappings are deliberately public. “AS number to owner mappings are public knowledge (in WHOIS)” (RFC 1930, Security Considerations).

Two ways to map an address to its AS:

# Look up the ASN for an IP address
whois -h whois.radb.net 104.16.132.229

# Or use the dig command to query Team Cymru's service
dig +short 229.132.16.104.origin.asn.cymru.com TXT
# Returns: "13335 | 104.16.128.0/20 | US | arin | 2014-03-28"

# Look up details about an ASN
whois -h whois.radb.net AS13335

What CDNs do

• Cloudflare runs AS13335. It describes AS13335 as “a global anycast network, spanning over 335 cities, in more than 125 countries” with “an open peering policy”. Peers are “highly recommended to perform RPKI validation, and generate RPKI ROAs for their own routes” (Cloudflare peering policy).
• Fastly peers “with other Internet Service Providers (ISPs) and Content Networks with IPv4 connectivity on Autonomous System (AS) 54113”. Unlike a transit network, Fastly deliberately does not announce the same routes everywhere. It scopes announcements to the point of interconnect. Fastly states that peers “will not receive a consistent routing table from Fastly across multiple points of interconnection” (Fastly peering). One AS, different announcements per location.
• Akamai runs more than one AS. The registry shows AS16625 held by “AKAMAI-AS - Akamai Technologies, Inc.” and AS20940 held by “AKAMAI-ASN1 Akamai International B.V.” (RIPEstat AS overview). This is a working example of one company, several ASes.
• Google serves its edge network from AS15169, registered to “GOOGLE - Google LLC” (RIPEstat AS overview).
• Netflix shows the other model. It partners “with over a thousand ISPs to localize substantial amounts of traffic with Open Connect Appliance embedded deployments” (Netflix Open Connect). Those appliances gather routing information via BGP from the network hosting them. Content served that way comes from inside the ISP, not from a Netflix AS.

Watch out for

• Ownership is not policy. Two networks in the same company may have different routing policies. Then they are two ASes, not one. This is because “without exception, an AS must have only one routing policy” (RFC 1930, section 4).
• Most networks should not have an ASN. Consider a single-homed site, with one prefix or many. For that site, “a separate AS is not needed; the prefix should be placed in an AS of the provider”. For a multi-homed site, “an AS is required”. RFC 1930 calls that “ALMOST THE ONLY case where a network operator should create its own AS number” (RFC 1930, section 5.1).
• Private-use ASNs stay private. The reserved ranges are 64512 to 65534, and 4200000000 to 4294967294 (RFC 6996, section 5). If prefixes originate from them, those numbers “MUST be removed from AS path attributes (including AS4_PATH if utilizing a four-octet AS number space) before being advertised to the global Internet” (RFC 6996, section 4). Separately, 65535 and 4294967295 are reserved outright. They are not usable as ASNs (RFC 7300).
• One prefix, one origin AS. “Generally, a prefix can should belong to only one AS” (the typo is the RFC's). This is a direct consequence: there is exactly one routing policy per destination at each point in the internet (RFC 1930, section 7). That section allows one aggregation exception, AS_SET. It is now discouraged. It blurs what it means to originate a route, and it breaks origin authentication. So RFC 6472 recommends not using it.
• An ASN lookup names the announcing network, not the content owner. Embedded caches inside an ISP deliver a content network's bytes from the host network's address space. Netflix Open Connect appliances are one example, with equivalents from other providers. So the lookup returns the ISP.
• BGP trusts its peers. Its own specification notes that “absent the use of mechanisms that effect these security services, attackers can disrupt these TCP connections and/or masquerade as a legitimate peer router” (RFC 4271, Security Considerations). Watch for a currency trap here. RFC 4271 requires implementations to support the TCP MD5 option, but this option “has been obsoleted by the TCP Authentication Option (TCP-AO; RFC 5925)” (RFC 7454, section 5.1). Protecting the session is not the same as validating the routes.

Best practice

• To find which network served a request, resolve the name and map the address to its origin AS. Use WHOIS at the relevant registry, Team Cymru's origin.asn.cymru.com DNS service, or RIPEstat. The mapping is public by design (RFC 1930, Security Considerations). So treat the ASN as the evidence for which CDN, or which leg of a multi-CDN setup, handled traffic. Re-check it after every failover test.
• Request your own ASN only when you multi-home and need a routing policy distinct from your providers'. Otherwise, stay in your provider's AS (RFC 1930, section 5.1).
• Keep one routing policy per AS. Aggregate what you announce. Register appropriately sized CIDR blocks so the number of prefixes you advertise is, ideally, as low as one (RFC 1930, section 4).
• Never leak private-use ASNs. Strip them from AS paths at your edge. Do not accept prefixes carrying private ASNs from non-customers. Filter in both directions per BCP 194. Protect the sessions themselves with TCP-AO or GTSM where implemented (RFC 6996, section 4; RFC 7454, sections 5 and 9).
• Publish RPKI ROAs for your prefixes. Validate origins on what you receive (RFC 6811). Large CDNs expect it of peers. Cloudflare's policy says so explicitly.