Autonomous System Number (ASN) Information Lookup

ASN or IP address:

Examples: AS15169, 15169, 8.8.8.8, or 2001:4860::8888; only the first non-empty line is used.

Ignored {{ extraLinesIgnored }} extra line(s). This tool processes only the first non-empty line.

Limit prefixes:

Use 0 for all prefixes, or a cap like 25, 50, or 100 for shorter exports.

rows

Prefix sort:

Source order keeps feed order; Length groups by CIDR size; Alpha sorts lexically.

Peer type:

Choose all, left, right, or uncertain; labels are path clues, not contract roles.

Field	Value	Copy
{{ f.label }}	{{ f.value }}
No ASN overview rows Run a lookup to populate registry, routing, and contact details.

Prefix	IP Version	Copy
{{ p.prefix }}	{{ p.ip_version }}
No prefixes returned The selected ASN did not return announced prefixes in this lookup.

ASN	Name	Type	Copy
{{ pr.asn }}	{{ pr.name }}	{{ pr.type }}
No peers returned RIPEstat did not return neighbour rows for the current filter.

Signal	Status	Note	Copy
{{ row.signal }}	{{ row.status }}	{{ row.note }}
No routing notes available Run a lookup to generate registry, prefix, and peering context notes.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

An ASN is a routing identity, not just a company label.

Internet routes are exchanged between autonomous systems, which are networks or groups of networks that present a shared routing policy to the rest of the Internet. The public number assigned to one of those routing domains is an Autonomous System Number, or ASN. When a firewall log shows an address, a prefix filter changes, a route leak is suspected, or a peering request arrives, the ASN is often the first stable handle for understanding who is visible in the routing system.

The same organization can operate several ASNs, and a single ASN can announce many IPv4 and IPv6 prefixes. Some networks originate their own routes, some appear mainly through transit providers, and some maintain public peering profiles that lag behind operational changes. A useful ASN reading therefore separates identity, route visibility, registry contacts, and peering context instead of treating one holder string as the whole answer.

ASN: The number used by Border Gateway Protocol (BGP) to identify an autonomous routing domain.
Prefix: An address block such as 203.0.113.0/24 or 2001:db8::/32 that may be announced into global routing.
Origin ASN: The ASN seen as originating a prefix in a public routing view.
Neighbour ASN: An ASN observed beside another ASN in BGP path data. It is a routing clue, not proof of a commercial relationship.

Public ASN evidence is strongest when independent views agree. A routing data source can show which ASN is visible for an address and which prefixes or neighbours are returned from collectors. Registration data can identify the resource record and role contacts when a registry publishes them. PeeringDB can add operator-maintained policy, AS-SET, traffic, and interconnection clues. Agreement across those views raises confidence; disagreement tells you what to verify next.

ASN lookups are still snapshots. Route collectors see the Internet from particular vantage points, registry records may be sparse or delayed, and PeeringDB records are voluntary. Treat the result as a strong triage brief for routing, abuse, diagnostics, and peering review, not as a legal ownership certificate or a complete measurement of every path on the Internet.

How to Use This Tool:

Enter one public IP address or one ASN. ASN input can include the AS prefix or only the number. If several lines are pasted, the lookup processes the first non-empty line and warns that the remaining lines were ignored.

Type an ASN such as AS15169, a numeric ASN such as 15169, or a public IPv4 or IPv6 address such as 8.8.8.8.
Use Use my IP only when the lookup should start from the public address currently visible for your connection.
Run Lookup and read ASN Overview for the holder, country, status, first-seen or updated dates, peer counts, RDAP contact clues, and PeeringDB fields when available.
Open Prefixes to inspect announced CIDR blocks. Limit prefixes shortens the visible table for large ASNs while the JSON result keeps the full returned prefix list.
Use Prefix sort when CIDR length or alphabetical order makes the prefix table easier to scan. Sorting changes display order, not the underlying lookup.
Check Peers for observed neighbour rows. Use Peer type only when you need to focus on left, right, or uncertain path-position labels.
Read Routing Notes before copying the result into an incident ticket. The notes call out missing prefixes, uncertain neighbours, available abuse contact data, and missing PeeringDB records.

For a compact handoff, copy the ASN, holder, visible prefix count, abuse contact if present, and any caution note about uncertain neighbour rows or missing public records.

Interpreting Results:

Read the overview as an identity snapshot, then compare it with the prefix table, neighbour table, registry contacts, and peering context. A strong result usually has a clear ASN, a plausible holder, current visible prefixes, and notes that do not conflict with the registry or PeeringDB context. A weak result is not automatically suspicious; it may simply mean the selected public sources did not have enough current data.

ASN and holder identify the routing number and the registered or reported operator name. Use them as an investigation anchor, not a legal ownership conclusion.
Prefixes show announced CIDR blocks returned for the ASN. Empty prefixes can occur for inactive, transit-only, newly changed, or poorly observed routing states.
Peer counts and neighbour rows describe observed AS path adjacency. The labels left, right, and uncertain come from path position and collector context.
RDAP contact fields can help with abuse, administrative, technical, or NOC escalation when the registry publishes role-based email addresses.
PeeringDB fields help with policy and peering review, but they are operator-maintained and should be compared with routing and registry evidence.

When the result will drive a blocklist, abuse report, peering decision, or routing change, verify the ASN and prefix evidence with another current BGP or registry source before acting.

Technical Details:

BGP exchanges reachability information between autonomous systems. A route pairs a destination prefix with attributes, including the AS path that carried the announcement. AS path data helps operators apply policy and avoid loops, but public path intelligence depends on which collectors saw which routes at a given time.

ASN intelligence combines several public evidence families. Routing data maps an IP address to an origin ASN and lists announced prefixes or observed neighbours. RDAP autnum records expose structured registration data for AS number resources when a regional registry publishes it. PeeringDB adds network-profile details supplied by operators, including policy, AS-SET, traffic-profile, looking-glass, and prefix-limit clues.

Lookup Core

The core operation is evidence aggregation. A public IP address is first resolved to an origin ASN when public data has a match. ASN input is normalized to the numeric form used by routing, registry, and peering sources. Returned records are grouped into identity fields, announced prefixes, neighbour rows, routing notes, RDAP contacts, PeeringDB context, and JSON output.

ASN lookup evidence sources and limits
Evidence type	Question answered	Typical fields	Main caution
Routing overview	Which ASN is visible for the query?	ASN, holder, country, status, first seen, last updated.	A recently changed or transit-only ASN can be hard to judge from one public view.
Announced prefixes	Which CIDR blocks are visible for the ASN?	Prefix and IP version.	Collector visibility and time windows can differ from another BGP source.
ASN neighbours	Which ASNs appear beside this ASN in observed paths?	Neighbour ASN, name, and path-position type.	Adjacency does not prove transit, customer, peering, or contract status.
RDAP autnum	What does the registry publish for this AS number?	Handle, name, event dates, role-based email contacts.	Registry data may omit contacts, redact details, or use role labels differently by region.
PeeringDB network profile	What has the operator published about peering?	Policy, website, AS-SET, traffic ratio, service type, notes.	Records are voluntary and may lag current routing operations.

Aggregation Core

Summary counts condense large routing results into fields that are easier to hand off. They are useful for triage, but they are not Internet-wide totals. A visible prefix total counts returned IPv4 and IPv6 prefix rows, and a peer total counts returned neighbour rows before the display filter is applied.

visible prefix total = returned IPv4 prefix rows + returned IPv6 prefix rows

Shortest and longest prefix lengths come from the CIDR suffix after the slash. For example, 203.0.113.0/24 contributes a prefix length of 24, while 2001:db8::/32 contributes 32. Prefix lengths should be compared within the same address family because IPv4 and IPv6 address spaces are not directly comparable by size.

ASN aggregation rules and boundaries
Summary value	Rule	Boundary
Prefix total	Count returned IPv4 and IPv6 prefix rows.	The visible table may be capped by the prefix limit, but JSON keeps the full returned list.
Prefix length range	Extract the CIDR suffix and report the minimum and maximum returned values.	Malformed or missing prefix strings cannot contribute a meaningful suffix.
Peer total	Count all returned neighbour rows before applying the peer-type filter.	The count reflects the selected public route view, not every possible BGP vantage point.
Uncertain neighbours	Report rows flagged as uncertain separately from left and right neighbours.	Uncertain rows need corroboration before they are used as relationship evidence.
Contact availability	Extract role-based email fields from the first successful RDAP registry response.	No extracted email means no suitable public role email was found in that response.

Why Public Sources Disagree

Different ASN sources answer different questions. A BGP collector reports what it saw from its peers. A regional registry reports what is registered in its database. PeeringDB reports what a network operator or approved maintainer has published. Those answers can diverge during transfers, mergers, new prefix turnups, route leaks, registry cleanup, or ordinary documentation lag.

Confidence rises when the origin ASN, holder, prefixes, RDAP contacts, and PeeringDB network name point in the same direction. If one evidence family is missing or conflicts with the others, keep the result as a lead and gather another current source before making an operational or abuse-handling decision.

Accuracy and Privacy Notes:

The lookup sends the entered ASN or public IP address to public routing, registry, IP-detection, and peering data services as needed to build the report. Do not paste private incident notes, customer details, credentials, internal hostnames, or addresses that should not leave your environment.

Private, reserved, or internal IP addresses usually do not have useful public ASN evidence.
Public route visibility is sampled and time-sensitive, not a complete Internet-wide measurement.
RDAP role contacts are public registry clues, not guaranteed abuse-handling instructions.
PeeringDB policy fields are operator-published context, not binding network contracts.
Use my IP checks the public address currently visible for your connection, so that address is necessarily sent to public IP-detection services.

Worked Examples:

A firewall log shows 8.8.8.8. Entering the address maps it to an origin ASN when public routing data has a match, then the overview gives the holder and route context. The prefix table shows the returned route footprint, and any RDAP abuse contact gives a starting point for escalation after manual confirmation.

A network engineer reviewing AS15169 can compare routing evidence with PeeringDB context. If the holder, network name, AS-SET, policy, and prefix limits align, the report is a useful first-pass profile. If they disagree, the mismatch is a reason to check current BGP tables, registry records, and the operator's published peering information.

A pasted note contains several ASNs separated by new lines. The lookup processes the first non-empty line and reports that extra lines were ignored. Run each ASN separately so prefix counts, neighbour rows, and exported JSON do not mix unrelated networks.

FAQ:

Can a public IP address be used instead of an ASN?

Yes. A public IPv4 or IPv6 address is first mapped to an origin ASN when public data has a route match, then that ASN is used for the routing, registry, and peering checks.

Why do some ASNs show no announced prefixes?

The ASN may be inactive, transit-only in the selected view, newly changed, filtered by the public data source, or missing from the current route snapshot. Confirm with another BGP source before treating it as unused.

Do neighbour rows identify upstreams and customers?

No. Neighbour rows show observed AS path adjacency and path-position labels. They can guide BGP investigation, but they do not prove a paid transit, customer, or peering relationship.

Why are RDAP or PeeringDB fields missing?

A registry may publish sparse autnum data, role contacts may be redacted or absent, and PeeringDB records are voluntary. Missing fields mean the selected public source did not return that detail.

What should be checked when a lookup fails?

Confirm that the input is one public IP address or one ASN, remove extra pasted lines, and try the numeric ASN form without AS. If the failure remains, compare with another current BGP or RDAP lookup.

Glossary:

ASN: Autonomous System Number, the public identifier used by BGP for an autonomous routing domain.
BGP: Border Gateway Protocol, the inter-AS routing protocol used to exchange reachability information.
CIDR prefix: An IP address block written with a slash length, such as 198.51.100.0/24.
RDAP: Registration Data Access Protocol, the structured protocol used by registries to publish registration data for resources such as ASNs and IP networks.
PeeringDB: A community-maintained database where network operators publish peering, policy, facility, exchange, and contact context.
AS-SET: An Internet Routing Registry object that names a set of ASNs often used when building routing filters.

References:

How to retrieve Autonomous System details using WHOIS, Simplified Guide.
Guidelines for creation, selection, and registration of an Autonomous System, RFC Editor, March 1996.
A Border Gateway Protocol 4 (BGP-4), RFC Editor, January 2006.
RIPEstat Data API documentation, RIPE NCC.
Registration Data Access Protocol Query Format, RFC Editor, June 2021.
PeeringDB documentation, PeeringDB.