| Field | Value | Copy |
|---|---|---|
| {{ f.label }} | {{ f.value }} | |
| No data. | ||
| Prefix | IP Version | Copy |
|---|---|---|
| {{ p.prefix }} | {{ p.ip_version }} | |
| No prefixes. | ||
| ASN | Name | Type | Copy |
|---|---|---|---|
| {{ pr.asn }} | {{ pr.name }} | {{ pr.type }} | |
| No peers. | |||
An Autonomous System Number, or ASN, identifies a network that applies its own routing policy on the public internet. When an incident report, BGP change, or abuse complaint points to an AS number or a single public IP address, the first practical question is usually who operates that network and what footprint it is actually announcing.
This tool answers that question by building one lookup around a single ASN key. It can start from an AS number directly or from an IP address that is first mapped to an origin ASN, then it pulls together holder details, country, announcement status, visible prefixes, observed neighbours, and public registry contacts.
That mix is useful when the raw identifier alone is not enough. A network engineer may want to confirm that a route belongs to the expected operator, an incident responder may need ownership and abuse contacts before escalating, and a peering analyst may want a quick read on how broad or specific the network's public routing footprint looks.
The page is strongest as a correlation view. It compares routing visibility with registration and interconnection records so you can tell whether the ASN looks active, documented, and broadly consistent across public sources.
It is not a full routing audit. The data comes from several public services with different update cadences, and the neighbour and peer counts are observation-based rather than a guaranteed inventory of every business relationship or private interconnect.
For a first pass, enter one ASN or one public IP and leave the advanced fields untouched. That gives you the source order of the returned prefixes, the full visible prefix list, and the unfiltered neighbour set, which is the easiest way to understand the network before you start narrowing the view.
If you are starting from an alert, ticket, or firewall log, an IP lookup is often the fastest path because the tool resolves the likely origin ASN first and then continues with the same routing and registry pass it would use for a direct ASN search. If you are checking your own connection, Use my IP fills the box with the current public address before running the same lookup.
ASN Overview first. Resource, Holder, Country, and Status usually tell you whether you are looking at the right network before you dive into the longer tables.Prefixes next when the footprint matters. The shortest and longest prefix lengths give a quick sense of whether the network is mostly advertising broad aggregates, more specific routes, or a mix of both.Peers only after you know what kind of question you are asking. A large neighbour list is useful context, but the Peer type filter helps when you need to focus on left, right, or uncertain relationships.Last Updated and any RDAP Last Changed value before assuming the routing view and the registry record describe the same moment in time.The most common overread is treating missing RDAP, PeeringDB, or contact rows as proof that the ASN is suspicious or inactive. In practice, public registration quality varies a lot. Treat blank fields as “not provided here,” then confirm with another authoritative source if the decision matters.
The lookup normalizes everything around one ASN string. If the input already looks like an ASN, the page removes a leading AS and accepts only one to ten digits. If the input looks like an IPv4 or IPv6 literal, the page asks public routing data for the origin ASN first. Only the first non-empty line is processed, so a pasted block becomes a single-item lookup with a warning about the ignored extra lines.
The routing view comes primarily from RIPEstat. AS Overview supplies identity and visibility fields, Announced Prefixes supplies the current prefix list, and ASN Neighbours supplies observed path adjacencies. The page also requests RIS Peer Count, but the summary shown here reads only the IPv4 upstream and downstream counts from that payload.
RDAP and PeeringDB are added afterward. RDAP contributes autnum contacts and change metadata, while PeeringDB contributes operator-published peering and policy context when the ASN has a matching network record.
| Layer | What the tool extracts | Why it matters |
|---|---|---|
| AS overview | Resource label, holder, country, status, first seen, last updated | Headline identity and visibility state. |
| Announced prefixes | Prefix strings and IP version markers | Shows what address ranges are currently visible. |
| RIS peer count | IPv4 upstream and downstream counts used in the summary rows | Rough visibility cue, not a full relationship map. |
| ASN neighbours | Neighbour ASNs, names, and observed path positions | Adds path-adjacency context. |
| RDAP autnum | Handle, name, event timestamp, abuse/admin/tech/NOC emails | Supplies public contacts and change metadata. |
| PeeringDB net | Descriptive, policy, website, and service-type fields | Adds operator-published peering context. |
| Field | How the page computes it | Interpretation boundary |
|---|---|---|
Prefixes (total), Prefixes (v4), Prefixes (v6) |
Counted from the returned announced-prefix list | Visible routes only, not a full historical picture. |
Shortest prefix length, Longest prefix length |
Taken from the minimum and maximum CIDR suffix in the current prefix list | Useful for aggregation style, not traffic volume. |
Upstream Peers, Downstream Peers |
Read from the IPv4 peer-count group in the RIS peer-count response | Observation cue, not a complete relationship count. |
Peers (left/right/uncertain) |
Counted from neighbour rows by the observed path-position type | Uncertain rows need extra caution. |
The privacy boundary is straightforward but important. The browser does not talk to RIPEstat, RDAP, PeeringDB, or public IP-detection services directly. Instead it sends your query through the shared CORS helper at function.simplified.tools, which then forwards the request to those external services.
Comparisons are most defensible when you keep the lookup method consistent and capture the returned timestamps. Also remember that the page stops after the first successful RDAP registry rather than reconciling every registry view in parallel.
Run one clean lookup from input to interpretation so the summary, tables, and JSON all describe the same network state.
ASN or IP. Use an AS number such as AS15169 or a single public IP literal such as 8.8.8.8. If you want the current browser-facing address, use Use my IP.Lookup. If the input box contained several lines, the page keeps the first non-empty one and shows a warning that the others were ignored.Resource label and the holder, country, and status badges tell you whether the lookup landed on the network you expected.ASN Overview long enough to scan First Seen, Last Updated, prefix totals, peer totals, and any RDAP or PeeringDB fields that were populated.Prefixes when route footprint matters. Use Limit prefixes if the list is long, and switch Prefix sort to Length or Alpha only after you have seen the unsorted source view once.Peers if adjacency context matters. Use Peer type to isolate left, right, or uncertain rows, then compare the neighbour names against what you expected from the network's public role.JSON when you need a handoff artifact or want to preserve the raw structured payload. If the page shows Enter an ASN or IP address., Could not detect your IP., or Lookup failed., correct the input and rerun before trusting any partial conclusion.A good closing habit is to copy the result only after noting the returned timestamps. That makes later comparisons much easier when registry data or route visibility changes between runs.
The strongest result fields are the ones that anchor identity and timing. ASN, Holder, Country, Status, First Seen, and Last Updated tell you what network the page believes it is describing and how current that particular source view is.
Prefixes (total) tells you how many visible routes were returned, but not how much traffic the ASN carries or how important those routes are operationally.Shortest prefix length and Longest prefix length are quick aggregation hints. Shorter prefixes usually mean broader route blocks; longer ones usually mean more specific advertisements.Upstream Peers and Downstream Peers are easy to overread. In this page they come from the IPv4 RIS peer-count group, so treat them as rough visibility signals rather than definitive provider or customer counts.uncertain deserve a second check before you build an argument around them. RIPE documents that classification as a collector-observation ambiguity, not a firm relationship label.The best verification cue is to compare the routing rows with the registration rows. If the holder, country, timestamps, and neighbour context all point in the same direction, confidence rises. If the routing view looks current but registry contacts are missing or stale, slow down and verify with another authoritative source before acting.
A ticket may contain only a source address such as 8.8.8.8. In that case the page resolves the likely origin ASN first, then fills the overview, prefix, and neighbour views around that network.
Suppose the overview identifies the ASN you expected, but the prefix list is long. Leaving the initial result unsorted shows the collector's source order. Switching Prefix sort to Length then makes broad aggregates and more specific routes easier to compare.
A copied email thread might contain AS15169 on one line and commentary below it. The page keeps only the first non-empty line, warns that the extras were ignored, and proceeds only if that surviving line is valid.
Yes. If the input looks like an IPv4 or IPv6 literal, the page first resolves the likely origin ASN and then performs the rest of the lookup against that ASN.
Because those public sources do not cover every ASN equally. A valid lookup can still have empty contact, website, policy, or service-type rows when that information is missing from the source record.
uncertain mean in the Peers view?It is RIPE's label for neighbour observations that may be influenced by the route collectors' own direct peerings. Treat those rows as tentative adjacency hints, not final relationship evidence.
No. The summary here uses the IPv4 peer-count data returned by RIS. It is useful for visibility and comparison, but it is not a guaranteed complete inventory of every relationship or exchange edge the ASN has.
The page transmits the ASN or IP through the shared CORS helper so RIPEstat, RDAP, PeeringDB, and optional public IP-detection services can answer the lookup. The shipped bundle does not define its own persistent storage for saved searches.
192.0.2.0/24 or 2001:db8::/32.