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

When traffic crosses the public Internet, it moves between networks that advertise reachability to one another. The number attached to one of those routing domains is an Autonomous System Number, or ASN. An ASN is often the first clue behind a suspicious address, a route leak, a prefix-filter change, a peering request, or a plain question about who appears to operate the network that announced an IP address.

An autonomous system is not simply a company name. It is a routing-policy boundary: a connected group of IP prefixes that presents a consistent routing plan to the rest of the Internet. Large operators may use several ASNs for different regions or products, while smaller networks may rely on an upstream provider's ASN. A single holder label can therefore hide several routing realities, and a single ASN can cover many IPv4 and IPv6 blocks.

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

ASN information becomes most useful when several public records agree. A route collector can show that an address is currently seen under a particular origin ASN. A registry record can identify the registered number resource and publish contact roles. An operator-maintained peering record can add policy, AS-SET, and traffic-profile clues. Agreement across those views is stronger than a single holder string or a single neighbour row.

There are common traps. Public BGP visibility is sampled from route collectors, so it is not a guarantee of what every network on the Internet will choose. Registry data may be old, sparse, or privacy-filtered. Peering records are voluntary and can lag operational changes. Treat ASN lookup results as evidence for triage and verification, not as a final ownership certificate.

The safest workflow is to separate identity, route visibility, contacts, and peering context. Identity tells you which ASN is being discussed. Prefixes show the visible route footprint. Contacts help with abuse or operational escalation. Peering context helps when the question is about policy, route-server expectations, or whether an operator-published profile matches the routing evidence.

How to Use This Tool:

Enter one public IP address or one ASN. ASN input can include the AS prefix or just the number. If you paste several lines, only the first non-empty line is processed and the page shows a warning for the ignored lines.

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 you want the lookup to start from the public address currently visible for your connection.
Run Lookup and start with ASN Overview for holder, country, status, first-seen or updated dates, peer counts, RDAP contact clues, and PeeringDB fields when available.
Open Prefixes to review the announced CIDR blocks. Limit prefixes shortens the visible table for very 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 and use Peer type only when you need to focus on left, right, or uncertain path-position labels.
Read Routing Notes before using the result in 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 and neighbour tables. A strong result usually has a clear ASN, a plausible holder, current visible prefixes, and routing notes that do not conflict with the registry or peering context. A weak result is not automatically suspicious; it may simply mean the selected public sources did not have enough current or complete data.

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

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 is the inter-AS routing protocol that exchanges reachability information between autonomous systems. A BGP route pairs a destination prefix with path attributes, including the AS path that the route information traversed. That path data lets operators detect loops and apply policy, but it also means public ASN intelligence is based on observations from particular collectors and times.

ASN lookup data combines several mechanisms. Public routing data maps an IP address to an announcing ASN and lists prefixes or neighbours visible from the routing information service. RDAP autnum records expose structured registration data for AS number resources when a regional registry publishes it. PeeringDB records add network-profile fields supplied by operators, including policy and routing-filter clues such as AS-SET and prefix limits.

Lookup Core

The core operation is evidence aggregation. A public IP address is first resolved to an origin ASN from public routing or IP intelligence data. ASN input is normalized to the number form used by routing, registry, and peering sources. Returned records are then grouped into identity fields, announced prefixes, neighbour rows, routing notes, RDAP contact fields, PeeringDB context, and a JSON payload.

ASN lookup evidence sources and limits
Evidence type	What it answers	Typical fields	Main caution
Routing overview	Which ASN is visible for the query?	ASN, holder, country, status, first seen, last updated	A transit-only or recently changed ASN can be hard to judge from one route view.
Announced prefixes	Which CIDR blocks are visible for the ASN?	Prefix and IP version	Collector visibility and time windows can hide or add routes compared with another view.
ASN neighbours	Which ASNs appear beside this ASN in observed paths?	Neighbour ASN, name, and path-position type	Path adjacency is not proof of transit, customer, settlement-free peering, or contract status.
RDAP autnum	What does the registry publish for this AS number?	Handle, name, event dates, role-based email contacts	Registry records may omit contacts, redact data, or use role labels differently across regions.
PeeringDB network profile	What has the operator published about peering?	Policy, website, AS-SET, traffic ratio, service type, notes	Records are voluntary and may not match current routing operations.

Aggregation Core

Summary counts are derived from returned rows. They are useful for triage because they condense a large ASN into a few fields, but they should not be read as global truth. A visible prefix count is a count of returned prefix rows, and a peer count is a count of returned neighbour rows before the display filter is applied.

visiblePrefixTotal = returnedIPv4PrefixRows + returnedIPv6PrefixRows

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. Smaller IPv4 suffixes generally describe larger blocks, but IPv4 and IPv6 prefix lengths should be compared within their own address family.

ASN aggregation rules and interpretation boundaries
Summary value	Rule	Boundary
Prefix total	Count returned IPv4 and IPv6 prefix rows.	The visible table may be capped by the display limit, but the JSON payload 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 email fields from RDAP entities that carry matching public contact roles.	No extracted email means no suitable role email was found in the first successful registry response.

Why Public Sources Disagree

Different ASN sources answer different questions. A BGP collector answers what it saw from its peers. A regional registry answers what is registered in its database. PeeringDB answers what a network operator or its approved users have chosen to publish. Those answers can diverge during transfers, mergers, route leaks, new prefix turnups, registry cleanup, or ordinary lag between operations and documentation.

The most reliable reading is comparative. If the origin ASN, holder, prefixes, RDAP contacts, and PeeringDB network name all point in the same direction, confidence rises. If one family is missing or conflicts with the others, keep the result as a lead and gather another 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 generally do not have useful public ASN evidence.
Public route visibility is sampled and time-sensitive; it is not a full Internet-wide measurement.
RDAP role contacts are public registry clues, not guaranteed abuse-handling instructions.
PeeringDB policy fields should be treated as operator-published context, not as binding network contracts.
If you use Use my IP, the public IP detection step necessarily checks the address currently visible for your connection.

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 provides 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, PeeringDB name, AS-SET, policy, and prefix limits align, the result 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 page.

A copied note contains several ASNs separated by new lines. The page 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 the ASN is used for the rest of 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 data source, or missing from the current public 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 network 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:

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.