What an Autonomous System Is
An Autonomous System (AS) is a collection of IP prefixes under the control of a single administrative entity that presents a unified routing policy to the internet. The "autonomous" in the name means the network operator makes its own routing decisions — it chooses which prefixes to announce, which paths to prefer, and which neighbours to accept routes from, independently of other networks.
Every organisation that connects directly to the internet routing infrastructure — ISPs, cloud providers, content networks, large enterprises, universities, and some government agencies — operates one or more autonomous systems. Each AS is identified by a unique Autonomous System Number (ASN).
Examples:
- AS15169 — Google LLC (covers Google Search, YouTube, Google Cloud)
- AS16509 — Amazon.com Inc. (AWS infrastructure)
- AS13335 — Cloudflare, Inc.
- AS3356 — Lumen Technologies (formerly CenturyLink), a major transit provider
- AS7018 — AT&T Services, Inc.
ASNs come in two formats:
- 16-bit (legacy): 1–65535. Originally the only format; now largely exhausted for new allocations.
- 32-bit (extended): 65536–4294967295. The current standard for new assignments, written as
ASXXXXXor in dotted notation (e.g.,1.0for AS65536).
Private ASNs — analogous to RFC 1918 private IP addresses — are reserved for internal use and must not be announced to the public internet: 64512–65534 (16-bit range) and 4200000000–4294967294 (32-bit range). These are used inside large networks and in BGP confederation configurations.
ASNs are assigned by the Regional Internet Registries (ARIN for North America, RIPE NCC for Europe/Middle East/Central Asia, APNIC for Asia-Pacific, LACNIC for Latin America, AFRINIC for Africa). Obtaining an ASN requires demonstrating a legitimate need for multi-homed or independently operated routing infrastructure.
BGP: The Protocol That Connects Autonomous Systems
BGP (Border Gateway Protocol, currently version 4, defined in RFC 4271) is the routing protocol that autonomous systems use to exchange reachability information with each other. It is the only exterior gateway protocol in widespread use on the public internet.
BGP differs fundamentally from interior routing protocols (OSPF, EIGRP, IS-IS) in one critical way: it is a path-vector protocol, not a distance-vector or link-state protocol. BGP routers don't exchange metrics (hop counts, bandwidth, delay); they exchange entire AS paths — the sequence of autonomous systems a route has passed through to reach a destination prefix. This makes BGP inherently policy-based rather than performance-based.
A BGP session (also called a BGP peering session) is a TCP connection between two routers — the BGP speakers — that exchange routing updates. BGP sessions between routers in different autonomous systems are called eBGP (external BGP). Sessions between routers within the same autonomous system are called iBGP (internal BGP), used to distribute routing information internally.
BGP's core function is simple to describe: each AS announces the IP prefixes it is responsible for (the prefixes it "originates") and receives announcements of other prefixes from its BGP neighbours. Through a combination of policy rules and the BGP path selection algorithm, each router builds a routing table that maps every reachable prefix to a next-hop router.
Peering vs. Transit: The Two BGP Relationship Types
The internet's routing infrastructure is built on two fundamental BGP relationship types, which are economic and commercial relationships as much as they are technical ones.
Transit
In a transit relationship, one network (the customer) pays another network (the provider) to carry its traffic to and from the rest of the internet. The provider announces all routes it knows to the customer, and announces the customer's prefixes to all of its other peers and providers.
Transit is the hierarchical backbone of internet routing. Large Tier 1 carriers (networks that can reach the entire internet through peering alone, without paying transit) provide transit to Tier 2 regional carriers, which provide transit to Tier 3 ISPs, which provide transit to end customers.
TRANSIT RELATIONSHIP:
[Your Network / AS65001]
|
| (pays for transit)
↓
[Regional ISP / AS3257]
|
| (peers with or pays transit to)
↓
[Tier 1 Carrier / AS1299 — Telia]
|
| (peers settlement-free with other Tier 1s)
↔
[Other Tier 1 Carriers — Lumen, NTT, Cogent, etc.]
Peering
In a peering relationship, two networks of roughly equal standing agree to exchange traffic destined for each other's customers directly, without payment. Peering is settlement-free (neither party pays the other) and is typically arranged between networks that benefit mutually from the direct connection — each gets to avoid sending traffic through (and paying for) a transit provider for the other's destinations.
Peering happens at Internet Exchange Points (IXPs) — physical facilities where multiple networks connect to a shared switching fabric, enabling any-to-any peering without individual bilateral links. Major IXPs include DE-CIX (Frankfurt), AMS-IX (Amsterdam), LINX (London), Equinix IX (multiple locations), and NYIIX (New York).
The routing policy consequence of transit vs. peering:
A network announces different route sets depending on the relationship type:
- To a transit provider: Announce only your own prefixes (and your customers' prefixes)
- From a transit provider: Accept all routes (the full BGP table)
- To a peer: Announce your own prefixes and your customers' prefixes
- From a peer: Accept only the peer's own prefixes and their customers' prefixes — not their transit routes
This routing policy is what prevents route leaks (discussed later) and implements the commercial agreements in the routing protocol.
Route Announcements and the BGP Table
When an AS wants to make its IP prefixes reachable across the internet, it originates a BGP announcement for each prefix it owns. This announcement contains at minimum:
- The prefix: e.g.,
203.0.113.0/24 - The AS path: At origination, just the originating ASN — e.g.,
AS65001 - Next hop: The IP address of the router to send packets to
As this announcement propagates from one AS to the next, each AS prepends its own ASN to the AS path:
Origin AS65001 announces 203.0.113.0/24:
AS path: 65001
AS3257 receives and re-announces to its peers and providers:
AS path: 3257 65001
AS1299 receives and re-announces:
AS path: 1299 3257 65001
A network on the far side of the internet receives:
AS path: 7018 1299 3257 65001
(AT&T → Telia → Transit provider → Your network)
The full BGP routing table — the collection of all prefix announcements from all autonomous systems — contains over 900,000 IPv4 prefixes and growing numbers of IPv6 prefixes as of 2025. Every BGP-speaking router on the internet maintains this table (or a subset of it) in memory and uses it to make forwarding decisions.
The AS Path: How BGP Selects Routes
When a BGP router receives multiple paths to the same prefix, it must select one to install in the routing table. BGP uses a multi-step path selection algorithm. The full algorithm has many steps, but in practice the most influential attributes are:
-
Local preference (LOCAL_PREF) — set internally within an AS, not propagated to neighbours. Higher value is preferred. Used to prefer one transit provider or peer over another for outbound traffic.
-
AS path length — shorter AS paths are generally preferred. Each ASN in the path counts as one hop. An operator can artificially lengthen a path (AS path prepending) to make a route less preferred by other networks.
-
Origin type — routes learned from IGP (i) are preferred over EGP (e) over Incomplete (?). Mostly historical; rarely decisive in practice.
-
MED (Multi-Exit Discriminator) — suggests to neighbours which entry point to use when multiple links connect the same two ASes. Only compared between paths from the same neighbouring AS.
-
eBGP vs. iBGP — routes learned via eBGP are preferred over iBGP.
-
IGP metric to next hop — when all else is equal, the route whose next-hop IP is closest (by IGP metric) wins.
ℹ️ Note: BGP is not a shortest-path protocol in the network-performance sense. A route with fewer AS hops may traverse longer physical distances, slower links, or more congested paths than a route with more AS hops. BGP path selection optimises for policy and AS-level topology, not latency or bandwidth. This is why traceroutes sometimes appear to take counterintuitive geographic paths.
How Route Announcements Propagate Across the Internet
BGP is not a real-time protocol — route changes propagate through the internet at the speed of BGP update processing and session maintenance, not instantaneously.
When a prefix is first announced or when a routing change occurs (a link goes down, a new prefix is originated, a policy change is made), BGP updates propagate hop by hop across the internet. Each AS receives the update, applies its local policies, and if it decides to accept and re-announce the route, propagates it to its own neighbours.
Convergence time — the time for a routing change to propagate fully across the internet — depends on the nature of the change and the number of ASes in the path. Typical convergence for a straightforward prefix announcement takes 2–5 minutes to reach most of the internet. Withdrawals (when a prefix becomes unreachable) can take longer, as some routers need to find alternative paths.
During convergence, different parts of the internet may have different views of where a prefix is reachable. This is the BGP-level equivalent of DNS propagation — and just as with DNS, checking from multiple vantage points (using BGP looking glass tools) shows the propagation state from different locations.
BGP Communities: Policy at Scale
BGP communities are tags attached to route announcements that carry policy signals between ASes. They allow network operators to communicate routing preferences without using separate BGP sessions for each policy intent.
A BGP community is a 32-bit value, typically written as two 16-bit numbers separated by a colon (e.g., 3356:6 or 65001:100). The meaning is entirely defined by the network that sets the community — there is no universal standard for what 3356:6 means (though Lumen/CenturyLink's community values are documented publicly).
Common uses:
- Traffic engineering: A customer attaches a community to tell a transit provider to prefer or de-prefer a particular route: "send traffic to this prefix via your west-coast routers, not east-coast"
- No-export: The well-known community
65535:65281tells receiving ASes not to propagate the route beyond their own AS - Blackhole communities: Many providers honour the community
65535:666to trigger null-routing (blackholing) of a prefix — used for DDoS mitigation to drop traffic at the provider edge
BGP communities are the mechanism by which customers influence how transit providers route their traffic without needing direct access to provider router configurations.
What Goes Wrong: BGP Hijacking and Route Leaks
BGP has no built-in authentication — any AS can announce any prefix, and other ASes may accept and propagate the announcement. This creates two well-known failure modes.
BGP hijacking
A BGP hijack occurs when an AS announces a prefix it doesn't own (or a more-specific sub-prefix of someone else's allocation), attracting traffic that was meant for the legitimate owner. Traffic destined for the hijacked prefix is diverted to the hijacker's network — where it may be dropped, inspected, or manipulated.
Notable real-world BGP hijacks:
- Pakistan Telecom (2008): Accidentally hijacked YouTube's IP space globally by announcing a more-specific prefix, taking YouTube offline for approximately two hours
- Rostelecom (2020): Announced routes for over 8,000 prefixes belonging to major cloud providers including AWS, Google, and Cloudflare, briefly diverting traffic
- Route hijacks for cryptocurrency theft: Targeted BGP announcements to intercept traffic destined for cryptocurrency exchange IP addresses
RPKI (Resource Public Key Infrastructure) is the mitigation: a cryptographic framework that allows IP prefix owners to sign route origin authorisations (ROAs) asserting which AS is authorised to originate a given prefix. Routers configured to enforce RPKI reject invalid announcements. RPKI adoption has grown significantly but is not yet universal.
Route leaks
A route leak occurs when an AS re-announces routes it should not — typically when a customer AS announces transit routes it learned from one provider back to another provider, violating the valley-free routing principle. The leaked routes may be selected by other ASes as preferred paths, inadvertently routing large volumes of transit traffic through the leaking AS.
The most consequential route leaks happen when a leaf AS (single-homed customer) misconfigures BGP and begins announcing the full internet routing table rather than only its own prefixes — temporarily making itself appear to be a transit path for routes it cannot actually carry.
Reading AS Paths in Traceroute and BGP Tools
AS path information appears in several places useful for network diagnosis.
In traceroute output
Traceroute shows IP addresses, not ASNs directly. But each hop's IP address can be correlated to its ASN using an ASN lookup, revealing which autonomous systems a path traverses and where AS boundaries — and therefore network operator handoffs — occur.
traceroute to 8.8.8.8 (Google DNS)
1 192.168.1.1 1.2 ms [Private — your home router]
2 10.0.0.1 8.4 ms [Private — ISP CGNAT]
3 203.0.113.1 12.1 ms AS7018 — AT&T
4 12.122.2.1 18.3 ms AS7018 — AT&T (internal)
5 72.14.232.1 22.7 ms AS15169 — Google ← AS boundary crossing
6 8.8.8.8 23.1 ms AS15169 — Google
The AS boundary crossing at hop 5 indicates a peering or transit handoff between AT&T (AS7018) and Google (AS15169). Use our ASN Lookup tool to identify the ASN for any hop IP, or our Traceroute tool to run a traceroute with ASN annotations built in.
For a full guide to reading traceroute output — including what latency at each hop means and when asterisks indicate a real problem — see our How to Read a Traceroute guide.
In BGP looking glass tools
BGP looking glasses are publicly accessible routers operated by major ISPs and IXPs that allow you to query the BGP table from their vantage point. They show the AS path that a specific network sees for any prefix. Hurricane Electric's BGP Toolkit is one of the most comprehensive public looking glass and BGP data tools available.
# Query a route from Hurricane Electric's looking glass
# Via their public BGP tool at bgp.he.net — https://bgp.he.net
# Example output for 8.8.8.8:
# BGP routing table entry for 8.8.8.0/24
# AS path: 6939 15169
# ^^^^ ^^^^^
# Hurricane Electric → Google
Via whois-based tools
# Find the ASN for an IP address using whois
whois -h whois.cymru.com " -v 8.8.8.8"
# Returns: AS | IP | BGP prefix | Country | Registry | Allocated | AS name
# 15169 | 8.8.8.8 | 8.8.8.0/24 | US | ARIN | 1992-12-01 | GOOGLE
# Look up all prefixes announced by an ASN
whois -h whois.radb.net -- '-i origin AS15169' | grep "^route:"
Use our ASN Lookup tool for point-and-click ASN lookups without command-line access — enter any IP address or ASN to see the organisation, announced prefixes, peer relationships, and geographic allocation.
Frequently Asked Questions
Q: What's the difference between BGP and other routing protocols like OSPF?
OSPF (and similar protocols like EIGRP and IS-IS) are interior gateway protocols — they operate within a single autonomous system and make routing decisions based on link metrics like bandwidth, delay, and hop count. BGP is an exterior gateway protocol designed to route between autonomous systems. It is policy-based rather than metric-based, and it is the only protocol used for inter-AS routing on the public internet. Most networks run both: an IGP internally for fast convergence within the AS, and BGP externally for announcing prefixes and learning routes from neighbours.
Q: Why does a packet sometimes take a seemingly longer geographic route?
Because BGP optimises for policy and AS path length, not physical distance or latency. A packet travelling from London to Paris may transit through Frankfurt if the two major London-Paris peering sessions are down, or if a carrier's routing policy prefers a particular path for commercial reasons. Direct geographic paths are not guaranteed — traffic follows BGP-selected paths, which reflect the commercial and technical relationships between networks. This is why a Paris-to-London traceroute might show hops in Amsterdam.
Q: What is a full BGP table and why do routers need so much RAM?
The full BGP table is the complete set of all IP prefix announcements visible from the public internet — over 900,000 IPv4 prefixes and growing IPv6 prefixes. Every BGP router that participates in the global routing table needs to store and process all of these entries. Early internet routers ran out of memory as the routing table grew beyond their design parameters (the "512k day" in 2014 was a notable event where routers with 512KB routing table capacity were overwhelmed). Modern BGP routers allocate gigabytes of RAM for routing table storage.
Q: What is an IXP and why does it matter for routing performance?
An Internet Exchange Point (IXP) is a physical facility — typically a large data centre — where multiple network operators connect their routers to a shared switching fabric. By connecting at an IXP, networks can peer directly with dozens or hundreds of other networks through a single physical connection, without needing individual bilateral links. IXPs improve routing performance by enabling direct exchange of traffic between networks that would otherwise transit through multiple intermediate ASes. For latency-sensitive traffic, a direct IXP peering path is almost always faster than the equivalent transit path.
Q: How does RPKI protect against BGP hijacks?
RPKI (Resource Public Key Infrastructure) allows IP address holders to cryptographically sign Route Origin Authorisations (ROAs) — records that specify which ASN is authorised to originate a given prefix. Routers that enforce RPKI (called "route origin validation") check incoming BGP announcements against the ROA database. If an AS tries to announce a prefix not covered by a valid ROA for that AS, RPKI-enforcing routers mark the route as "invalid" and reject it. RPKI doesn't prevent hijack attempts but prevents them from propagating through networks that enforce ROV (Route Origin Validation).
Q: Can I get my own ASN?
Yes, if you have a legitimate need — typically multi-homed routing (connecting to two or more transit providers) or operating network infrastructure that benefits from independent routing policy. ASN assignment requires applying through the appropriate RIR for your region (ARIN, RIPE, APNIC, etc.), providing documentation of your network topology and the need for an ASN, and paying a registration fee. ISPs and cloud providers can often sponsor smaller organisations through the application process. A single-homed connection through one ISP generally doesn't qualify — you'd use the ISP's ASN in that case.
Next Steps
Use our ASN Lookup tool to explore the routing context of any IP address — identifying the network operator, announced prefixes, and geographic allocation. Pair it with our Traceroute tool to see AS-annotated path analysis for any destination.
For interpreting the traceroute output that shows AS boundaries in practice — including what each hop's latency and asterisk responses indicate — see our How to Read a Traceroute guide.
For the IP addressing foundation that underpins BGP's prefix-level routing — understanding CIDR notation, subnet masks, and how prefixes are structured — see our Subnetting Explained guide.
Browse all network guides on DNSnexus for related topics.