An Autonomous System Number (ASN) is the globally unique identifier assigned to a network, called an autonomous system, that manages its own IP address blocks and routing policy under the Border Gateway Protocol (BGP). It identifies the operator of a set of IP addresses, not a single device, a physical location, or a company registration.
You have likely already seen one: a firewall log entry reading AS16509, a geolocation API response with an asn field, or an abuse report that names the source network by AS number instead of by IP. Once you know what that number represents, this kind of log data stops being opaque. You can separate a residential broadband connection from a cloud instance, attribute traffic to the network that actually carries it, and measure how much address space one organization controls.
ASN is an overloaded acronym. This guide covers the networking definition only, not the Advance Ship Notice used in logistics and EDI, and not the Associate of Science in Nursing.
TL;DR
- BGP requires it: the AS_PATH attribute that prevents routing loops and drives path selection is literally a list of ASNs.
- The field is 32 bits (0 to 4,294,967,295); assignable 16-bit values (1-64495) sit at the low end of that same space and remain fully valid.
- RFC 5396 defines three text notations (asplain, asdot, asdot+); normalize to asplain if you're parsing mixed sources.
- 122,182 ASNs are delegated worldwide, but only 79,355 were visible in the global routing table as of August 2026, so a valid lookup can return zero announced prefixes.
- An ASN is not identity, geography, or a permanent assignment; an operator can hold several; and a hijacked or misconfigured origin AS is exactly what RPKI is built to catch.

What Is an ASN, Formally?
ARIN's guide to Autonomous System Numbers frames it this way: what makes a set of networks "autonomous" isn't size or ownership structure, it's that whoever operates them enforces one clear, unified routing policy across the whole group, however many separate IP blocks that group contains. RFC 1930 formalizes this framing. The ASN itself is just the number assigned to that system so other networks can reference it.
Two elements of that definition determine everything else in this guide.
Prefixes. An autonomous system isn't an abstraction. It holds real address space, expressed in CIDR notation: 198.51.100.0/24, 2001:db8::/32. Those blocks are what the AS announces to the rest of the internet as "reachable through me."
Single routing policy. Internally, an AS can run whatever it likes: OSPF, IS-IS, static routes, or a mix of all three. None of that is visible outside. What the rest of the internet sees is one consistent set of statements about which prefixes belong to this network and how traffic should reach them. That external consistency is what makes the system "autonomous."
An ASN is therefore an operator identifier, not a device identifier. AS15169 is Google. AS13335 is Cloudflare. AS16509 is one of Amazon's networks. When your logs show an AS number, they're telling you which organization runs the infrastructure a packet came from, which is a different and often more useful question than where the packet came from.
Why ASNs Exist: BGP Needs a Name for Every Network
IP addressing tells a router where a destination numerically sits, but it says nothing about which of several possible physical paths should actually carry traffic there, or which paths a given network is even willing to carry. Interior routing protocols like OSPF solve that problem inside a single network, where one operator controls every router and can simply dictate the rules. That control disappears the moment traffic crosses into a network somebody else owns: no single operator can dictate policy across the whole path, and each network involved has its own commercial relationships and rules about whose traffic it carries and how. BGP exists to coordinate exactly that, and it can't coordinate anything without a way to name each independently-run network in the conversation.
The internet isn't one network. It's tens of thousands of independently operated ones that agreed on a single protocol for telling each other what they can reach: the Border Gateway Protocol, standardized as BGP-4 in RFC 4271. That protocol can't function without a naming scheme for its participants.
When a network announces a prefix through BGP, the announcement carries an attribute called AS_PATH: the ordered list of autonomous systems the announcement has traveled through. Every AS that passes the announcement along prepends its own number. A route arriving at your border router with an AS_PATH such as 174 3356 15169 has crossed three networks, and the rightmost one originated it.
That single attribute does three jobs at once:
- Loop prevention. If a router sees its own AS number already in the path, it drops the announcement. No counting hops, no timers.
- Path selection. A shorter AS_PATH is generally preferred, which is why BGP counts networks rather than routers.
- Policy enforcement. Operators write filters against AS numbers: prefer routes from this transit provider, never accept these prefixes from that peer, don't carry traffic between these two networks.
BGP is a path vector protocol: the vector is literally a list of ASNs. Remove the numbers and there's no path to build. This is also why BGP frequently picks a route that isn't the fastest one: commercial relationships and configured preference drive the decision far more than raw latency does.
Where Autonomous Systems Physically Connect
A BGP session is a logical relationship, but it still has to run over a real link somewhere. Two patterns cover most of the internet. A private interconnection is a direct cable or virtual circuit between two networks, usually justified once the traffic between them is heavy enough to skip a third party entirely. An internet exchange point (IXP) is the more common answer for everyone else: a shared facility where dozens or hundreds of networks connect to one switching fabric, so any two participants can strike up a BGP session over shared infrastructure instead of running a dedicated link to each neighbor individually. Facilities like DE-CIX in Frankfurt and AMS-IX in Amsterdam each host hundreds to over a thousand member networks trading traffic directly this way, which is a big part of why peering between well-matched neighbors tends to be cheaper than buying transit.
How an ASN Maps to Actual Address Space
As of August 26, 2026, the CIDR Report counted 79,355 autonomous systems in the global routing table. That figure comes from route-collector vantage points rather than a complete census of every path on the internet, so treat it as a close, well-sourced estimate rather than an exact count. Of those, 28,012 (35%) announce exactly one prefix, while the largest single announcer, AS16509 (Amazon), announced 16,005 prefixes out of roughly 1,075,000 prefixes in the table overall.
That scale creates two practical problems for anyone building on ASN data.
First, "block an ASN" isn't one firewall rule. For a small hosting provider announcing three prefixes, it's three CIDR entries. For a hyperscaler announcing sixteen thousand, it's a very different piece of work, and the list changes week to week as prefixes are added and withdrawn. Any ASN-level allowlist or blocklist has to come from live routing data on a refresh schedule, since a list typed out once will be stale within days.
Second, "this traffic came from an ASN" tells you very little about scale on its own, because AS sizes vary enormously: a single-prefix operator might hold nothing more than a lone /24 (256 addresses), while a large operator's total announced space, spread across thousands of prefixes, can run into the hundreds of millions.
The relationships between autonomous systems are where the shape of the internet actually lives, and they come in two commercial flavors. In a transit relationship, one network pays another to carry its traffic to the rest of the internet. In a peering relationship, two networks exchange traffic between their own customers directly, usually without payment, because both benefit. A good ASN lookup separates these into upstreams, downstreams and peers, and that split is the fastest way to read a network's position: an AS with several upstreams and no downstreams is buying access, and an AS with hundreds of downstreams is selling it.
The Two ASN Formats, and the Notation That Trips People Up
ASNs were originally a 16-bit field, giving values 0 through 65535. The internet outgrew that. Four-octet AS numbers were introduced in RFC 4893 and are now specified by RFC 6793, extending the space to 32 bits: 0 through 4,294,967,295.
Crucially, this was an extension, not a replacement. A 16-bit ASN like AS174 is still perfectly valid; it's simply a 32-bit number whose high-order bits are zero. There's no migration for existing holders and no "legacy" flag to handle.
asplain, asdot and asdot+
Most ASN explainers skip this, but it matters for anyone parsing AS numbers from mixed sources. RFC 5396 defines three text notations. In asplain, every AS number is written as a plain decimal integer, so 65526 is "65526" and 65546 is "65546". In asdot+, every number is written as two integers joined by a period, high-order 16 bits then low-order 16 bits, so 65526 becomes "0.65526" and 65546 becomes "1.10". In asdot, values below 65536 use asplain and values from 65536 up use asdot+, so 65526 stays "65526" while 65546 becomes "1.10".
RFC 5396 settles on asplain as the notation to use and instructs IANA registries to use decimal representation. Modern registries, APIs and reports follow that. But asdot notation still appears in older router configurations and vendor documentation, so if you're ingesting AS numbers from mixed sources, a regex that only matches digits will silently fail on 1.10. Normalize to asplain on the way in.
The AS prefix is purely a display convention; it isn't part of the number itself. AS64496, as64496 and 64496 all refer to the same autonomous system, which is why well-built lookup APIs accept all three.
AS23456, the Placeholder You'll Occasionally See
AS23456, known as AS_TRANS, is reserved under RFC 6793 as a compatibility placeholder. It exists so a router that understands 32-bit AS numbers can talk to an older router that doesn't: the 32-bit number is swapped for AS23456 in the fields the old router reads, and carried intact in a separate attribute alongside.
If AS23456 shows up in your data as an origin, it isn't an organization. It's an artifact of that translation, and it means the real origin AS is somewhere else in the announcement.
Reserved and Private ASN Ranges
Some AS numbers will never appear as the legitimate origin of a route in the global table. A lookup against one of these returns nothing because nothing is there; the lookup itself hasn't failed. The values below come directly from the IANA Autonomous System Numbers registry.
| Range | Status | Reference |
|---|---|---|
| 0 | Reserved | RFC 7607 |
| 23456 | AS_TRANS | RFC 6793 |
| 64496-64511 | Documentation and sample code | RFC 5398 |
| 64512-65534 | Private use | RFC 6996 |
| 65535 | Reserved | RFC 7300 |
| 65536-65551 | Documentation and sample code | RFC 5398 |
| 65552-131071 | Reserved | |
| 4200000000-4294967294 | Private use | RFC 6996 |
| 4294967295 | Reserved | RFC 7300 |
The private ranges work like RFC 1918 addresses. Large enterprises and multi-site networks run internal BGP between their own sites and need AS numbers to do it, but those numbers never leave the organization. Two unrelated companies can both use AS65001 with no conflict, precisely because it's never announced publicly.
The documentation ranges are the ASN equivalent of 192.0.2.0/24 and example.com. If you're writing tutorials, tests or fixtures, use them instead of picking a plausible-looking real number and accidentally putting a live network into your examples.
Who Assigns ASNs, and Who Can Get One
Allocation is a two-step hierarchy. IANA allocates blocks of AS numbers to the Regional Internet Registries, and the RIRs allocate or assign individual numbers to network operators according to their own policies. There are five RIRs: ARIN for the Americas, RIPE NCC for Europe, the Middle East and parts of Central Asia, APNIC for Asia Pacific, LACNIC for Latin America and the Caribbean, and AFRINIC for Africa.
Check the registry directly and one thing becomes clear: the 16-bit space is finished. Every block from 1 to 64495 has already been handed to an RIR. IANA has no 16-bit blocks left to hand out, so most new assignments come from the 32-bit space, which is why recently issued numbers commonly run to six digits. RIRs do still reissue recovered 16-bit numbers from their own pools.
You can't get an ASN simply because you want one. RIR policies vary in detail but converge on the same justification: you need either multihoming (connections to two or more other networks) or a routing policy that genuinely differs from your upstream provider's. A single-homed network that just consumes internet access from one ISP has no technical need for its own AS number, and will be told so. In practice, actually obtaining one runs through one of two paths. Larger networks typically join their regional registry directly as a paying member and request the ASN as part of that membership. Smaller networks more often go through a sponsoring LIR (Local Internet Registry), a member organization that requests and holds the ASN on the applicant's behalf without requiring them to join the RIR outright, usually for a smaller one-time or annual fee.
The Gap: 122,182 Allocated, 79,355 Actually Routing
This gap explains a category of confusing lookup results that most ASN explainers don't address.
According to RIR delegation files, 122,182 AS numbers had been delegated worldwide as of August 24, 2026. The CIDR Report for August 26, 2026 counted 79,355 in the global routing table. That leaves roughly 43,000 delegated AS numbers, over a third of the total, that weren't visible in the global routing table.
Those numbers aren't errors. An AS number can be allocated and unrouted for entirely mundane reasons:
- The holder obtained it in advance of a network build that hasn't gone live.
- It was acquired through a merger and the address space was consolidated under a different AS.
- It's used only for internal or private peering that never reaches the public table.
- The organization stopped announcing but kept the registration current.
The practical implication for anyone querying ASN data: a lookup can legitimately return a complete WHOIS registration with an organization name, allocation date and contact details, and zero announced prefixes. Your code should treat an empty route list as a valid state rather than assuming the query failed. Run a delegated-but-unrouted number through the ASN Lookup API and you'll see exactly this: a full registration record with numOfIPv4Routes and numOfIPv6Routes both at zero. Distribution is also lopsided, with the United States holding 32,144 delegated ASNs, about 26 percent of the world total.

Why the Origin AS Matters for Routing Security
Because BGP was designed on the assumption that participants tell the truth, an autonomous system can announce a prefix it doesn't hold. Sometimes that's a typo in a router config. Sometimes it's deliberate. Either way, if neighboring networks accept the announcement, traffic destined for the real holder gets pulled toward the wrong AS. This is prefix hijacking, and the effects range from minor packet loss to multi-hour outages.
The defense that has actually gained traction is Resource Public Key Infrastructure, or RPKI. A Route Origin Authorization (ROA) is a cryptographically signed statement from the holder of an address block declaring which AS number is authorized to originate it, and at what prefix length. Networks that perform route origin validation check incoming announcements against those signed statements and drop the ones that fail.
RPKI binds a prefix to an AS number specifically, not to a company name or a contact address. That's how much weight the AS number carries in the routing system, and why an origin AS appearing somewhere it should not is a signal worth alerting on.
Origin validation does have real limits: it only confirms that the AS at the end of the path is authorized to announce the prefix. It says nothing about the rest of the path, so route leaks and forged paths remain open problems, and the protection only extends as far as the networks between you and an attacker actually enforce validation.
Types of Autonomous Systems and What Each One Tells You
ARIN's guide to Autonomous System Numbers groups autonomous systems into three categories based on how they connect and what they do with traffic that isn't theirs. At one end sits the stub AS, which peers with exactly one neighbor (it can still run private, unadvertised connections behind that single public-facing link). A multihomed AS adds redundancy by peering with two or more neighbors, so a single link failure doesn't take it offline, but it still won't carry anyone else's traffic through itself. A transit AS is the one that does: it maintains multiple connections and actively forwards traffic between other networks that aren't its own.
For someone reading routing data rather than designing a network, what matters is what each type implies about the traffic you see from it.
A stub AS is usually a single organization: a university, a government department, a company that runs its own edge. Traffic from a stub AS has a reasonably narrow set of plausible explanations.
A multihomed AS is typically a business that can't tolerate an outage. Same interpretive logic, slightly larger.
A transit AS is where interpretation gets hard. These are ISPs, backbone carriers, hosting companies and cloud providers, and the traffic leaving them belongs to their customers rather than to the carrier itself. Attributing behavior to a transit AS tells you who carried the packet. It doesn't tell you who sent it.
What Developers Actually Do with ASN Data
Separating data center traffic from residential traffic. A signup from a consumer broadband AS and a signup from a cloud hosting AS carry very different prior probabilities. This is one input among several rather than a standalone verdict, and it's available from a single lookup. APIFreaks returns the AS number on every response from the IP Geolocation API in the top-level asn.as_number field, so you rarely need a separate call for it.
When you need to report abuse or trace an investigation back to its source, the AS is often the more useful unit than the individual IP. The abuse contact for a network lives on its RIR record rather than on the individual IP's own record, so resolving the AS first gets you the right contact directly. Given one suspicious IP, the AS behind it also reveals the full address space the same operator controls, which is often where the rest of the activity is. Pairing ASN data with per-IP risk signals from the IP Threat Intelligence API gives you operator context and per-address reputation together.
Two more mechanical uses round this out. Diffing an AS's prefix list on a schedule turns unexpected additions or origin changes into a signal in your own monitoring, a lighter version of what dedicated BGP monitoring services do. And summing an operator's announced prefixes is the most direct way to answer how much address space it actually controls.
What an ASN Doesn't Tell You
An ASN isn't identity. A cloud provider or CDN hosts millions of unrelated tenants inside one AS: AS16509 describes Amazon's network as a whole, never the specific person who rented an instance inside it. Treating an AS number as if it were a single actor is the most common mistake in ASN-based analysis.
It isn't geography either. The country in an AS registration record is purely administrative. RIPE NCC, for instance, sometimes registers regional allocations against "EU" rather than a specific member state, and a network registered in one region routinely announces address space that terminates on several continents. If you actually need location, pull geolocation data for the specific address instead.
And it isn't permanent. AS numbers get transferred between organizations, and large companies commonly hold several: Google announces prefixes from both AS15169 and AS396982, its cloud platform network. A historical record showing that AS X belonged to company Y describes a moment in time; it's no guarantee that still holds today.
How to Look Up an ASN
For a single number, the free ASN Lookup tool returns the registered organization, every IPv4 and IPv6 prefix the network announces, its BGP upstreams, downstreams and peers, and the registry that holds the record. No signup required.
For anything programmatic, the ASN Lookup API returns the same data as structured JSON from a single GET request:
curl -X GET \
'https://api.apifreaks.com/v1.0/asn/whois/live?asn=AS12' \
-H 'X-apiKey: YOUR_API_KEY'
{
"asNumber": "12",
"asName": "NYU-DOMAIN",
"orgName": "New York University",
"country": "US",
"domain": "nyu.edu",
"type": "EDUCATION",
"dateAllocated": "1984-07-05",
"numOfIPv4Routes": "12",
"numOfIPv6Routes": "1",
"whoisHost": "ARIN",
"routeObjects": [
{"route": "192.76.177.0/24", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 256},
{"route": "216.165.96.0/20", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 4096},
{"route": "2607:f600::/32", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 7.922816251426434e+28},
{"route": "128.122.0.0/16", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 65536},
{"route": "192.86.139.0/24", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 256},
{"route": "216.165.103.0/24", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 256},
{"route": "128.238.0.0/16", "origin": "AS12", "originName": "New York University", "isp": "Polytechnic University", "numberOfIps": 65536},
{"route": "216.165.89.0/24", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 256},
{"route": "216.165.0.0/18", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 16384},
{"route": "216.165.112.0/21", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 2048},
{"route": "216.165.64.0/19", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 8192},
{"route": "216.165.102.0/24", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 256},
{"route": "216.165.120.0/22", "origin": "AS12", "originName": "New York University", "isp": "New York University", "numberOfIps": 1024}
],
"upstreams": [
{"asNumber": "AS3356", "description": "Level 3 Parent, LLC", "country": "US"},
{"asNumber": "AS6461", "description": "Zayo Bandwidth", "country": "US"},
{"asNumber": "AS3754", "description": "NYSERNet", "country": "US"},
{"asNumber": "AS137", "description": "Consortium GARR", "country": "IT"},
{"asNumber": "AS286", "description": "GTT Communications Inc.", "country": "US"},
{"asNumber": "AS3257", "description": "GTT Communications Inc.", "country": "US"},
{"asNumber": "AS8220", "description": "COLT Technology Services Group Limited", "country": "GB"},
{"asNumber": "AS3269", "description": "Telecom Italia S.p.A.", "country": "IT"}
],
"downstreams": [
{"asNumber": "AS394666", "description": "NYU Langone Health", "country": "US"}
],
"peers": [
{"asNumber": "AS3356", "description": "Level 3 Parent, LLC", "country": "US"},
{"asNumber": "AS6461", "description": "Zayo Bandwidth", "country": "US"},
{"asNumber": "AS3754", "description": "NYSERNet", "country": "US"},
{"asNumber": "AS137", "description": "Consortium GARR", "country": "IT"},
{"asNumber": "AS286", "description": "GTT Communications Inc.", "country": "US"},
{"asNumber": "AS3257", "description": "GTT Communications Inc.", "country": "US"},
{"asNumber": "AS8220", "description": "COLT Technology Services Group Limited", "country": "GB"},
{"asNumber": "AS3269", "description": "Telecom Italia S.p.A.", "country": "IT"},
{"asNumber": "AS394666", "description": "NYU Langone Health", "country": "US"}
],
"legacyRoutes": ["216.165.88.0/24"]
}
(This excerpt is edited from the raw response in five ways, not two. whoisResponse and parsedWhoisResponse are both omitted, since the latter contains institutional contact details (NOC and abuse-desk names, phone numbers, emails) that don't belong reproduced in published content even at the departmental rather than individual level. The top-level contacts object (emailContacts, abuseContacts) is omitted for the same reason. A handful of fields that came back empty or minimal for this specific ASN, description, website, allocationStatus, and the internal registry handle orgHandle, are left out since they add nothing to read. And the peers array shown here has 9 entries, not the 10 in the raw response: the raw data lists AS286 (GTT Communications) twice, once tagged "country": "NL" and once "US", and the duplicate is collapsed to one entry. Two things worth noticing in what's shown: the IPv6 entry's numberOfIps renders in scientific notation, since a /32 block's address count doesn't fit cleanly into standard numeric precision, so don't assume every numberOfIps value is a plain integer you can print directly. And most of the networks listed as peers here are also listed as upstreams, that's not a data error, the same neighbor can carry NYU's default route on some paths while exchanging direct, settlement-free traffic on others.)
The asn parameter accepts AS-prefixed or plain numeric values and ignores case, so AS12, as12 and 12 all return identical responses. Useful fields in the response:
orgName,asName,type,allocationStatusanddateAllocatedfor the registrationrouteObjects, an array of every announced prefix with itsroute,origin,originName,ispandnumberOfIpsnumOfIPv4RoutesandnumOfIPv6Routes, so you know the size of that array before iterating (these come back JSON-typed as strings, so parse them before doing numeric comparisons)upstreams,downstreamsandpeersfor the BGP relationshipslegacyRoutes, older announcements tied to the AS that fall outside its current route objectswhoisHost, identifying which of the five registries answeredparsedWhoisResponsefor structured contact records, andwhoisResponsefor the raw registry text when you need it verbatim
Each successful lookup costs 15 credits, and 4xx or 5xx responses aren't charged. The 10,000 free credits on signup cover roughly 666 lookups.
If you're starting from an IP address rather than an AS number, that's the reverse direction. The IP to ASN Lookup tool takes an IPv4 or IPv6 address and returns the AS number, organization and network block, and the Bulk IP Geolocation Lookup API handles the same resolution across many addresses in one request. For allocation detail on a specific block rather than the whole operator, the IP WHOIS Lookup API returns the assignment record including the originating ASN.
FAQs
What is an ASN in simple terms?
An ASN is the unique number that identifies a network on the internet, the way an IP address identifies a single interface. It's assigned to an autonomous system, a set of IP address blocks run under one routing policy, so networks can identify each other when exchanging routes over BGP.
What is ASN in networking?
In networking, ASN means Autonomous System Number: the identifier for a network that takes part in BGP routing. It's assigned by a regional internet registry and used by routers worldwide to reference that network when exchanging routes. Other industries use the same acronym for unrelated things, so context matters.
What is the ASN in an IP address?
The ASN isn't part of the address itself. It's the number of the network that announces the block containing that address, so you find it by looking the address up against current routing data rather than by reading the address. Two IPs in the same /24 will almost always share an ASN; two IPs in unrelated blocks usually won't.
What is the difference between an IP address and an ASN?
An IP address identifies one endpoint. An ASN identifies the network that owns and announces a whole range of addresses. A single ASN typically covers thousands or millions of IPs. Looking up an IP tells you about that address; looking up its ASN tells you who operates the infrastructure it sits in.
How do I find the ASN for an IP address?
Use an IP to ASN lookup, which resolves the address against current routing data and returns the originating AS number, the operator name and the network block containing that address. For one address a free tool is enough; for a list, use an API that accepts multiple addresses per request.
What is an ASN used for?
Developers most often use ASN data to classify traffic (separating data center sources from residential ones), attribute abuse reports to the right network instead of a single address, map the address space an operator controls during an investigation, monitor an AS's announced prefixes for unexpected changes, and total up how much address space an organization actually holds.
Wrapping Up
Start resolving AS numbers to network owners with 10,000 free credits. The APIFreaks ASN Lookup API requires no credit card to get started. Create a free account and make your first call in minutes.
