ASN Lookup technical details

What you can look up

Special-purpose numbers and addresses are explained instead of looked up: private, documentation and reserved ASNs, and private, loopback, link-local, carrier-grade NAT, documentation, multicast and other non-global addresses. No autonomous system announces those on the public internet.

Where the data comes from

Every lookup reads public data at the time you ask, and answers are cached for an hour. No lookup history is kept.

RIPEstat is built on the RIPE NCC’s Routing Information Service (RIS), route collectors that receive full BGP tables from hundreds of networks around the world. A route that none of those networks carry, such as one used only inside a region or between two private peers, does not appear.

Answers are cached for an hour, because routing tables change slowly and the sources ask heavy users to be considerate. The page says when a result came from the cache. Lookups are rate limited per visitor.

Prefixes

RIPEstat lists every prefix the AS originated in the last two weeks that at least 10 RIS peers saw. The counts and charts include only prefixes still announced at the end of that window; the rest are counted separately as recently withdrawn.

• IPv4 addresses counts each address once, even where announcements overlap, such as a /16 and a /24 inside it. “/24 blocks” divides that by 256.
• IPv6 /48 networks is the same total for IPv6, in units of /48, the size most networks accept as the longest route.
• Prefixes by length charts how many announcements there are of each size. A smaller number after the slash is a bigger block.
• The prefix list shows up to 1,000 prefixes, IPv4 first, in address order. The counts always cover them all.

Upstreams and downstreams

The neighbour graph comes from the AS paths the RIS collectors recorded. A neighbour that appears to the left of the AS in a path, between it and the collector, is shown as upstream. One that appears to the right, behind it, is shown as downstream. Left usually means a transit provider and right usually means a customer, but BGP data shows positions in paths, not contracts: a peer can appear on the left, and a network that is both a customer in one region and a peer in another can appear on either side.

RIPEstat flags a third group, shown as possibly upstream: neighbours that also feed the route collectors directly. Because their own sessions with the collectors put them at the left of every path they send, they may look upstream when they are not.

The graph and tables show the 10 neighbours on each side that appear in the most AS paths (6 per side on narrow screens), and up to 6 possibly upstream networks. The “Paths” number is that count, and line thickness follows it. Counts above the graph cover every neighbour. Select a neighbour to look it up.

Where an address sits

For an address or prefix, three bars show how it nests: the block IANA allocated to a registry (for example a /8), the prefix announced in BGP and its share of that block, and the address’s position inside the prefix. The registry shown is the one IANA allocated the block to; addresses can later be transferred between registries, so the holder’s own registry record is the final word. Website Recon reads that record for the addresses a website uses.

When more than one AS originates the prefix, all of them are listed and the first is profiled. Multiple origins can be deliberate, such as during a migration or with some DDoS protection services, or a sign of a leak or hijack.

RPKI status

Route origin validation, defined in RFC 6811, compares the announced prefix and origin AS with the route origin authorizations (ROAs) published in RPKI:

The status is checked for the first origin AS only. RPKI Explained shows how to publish ROAs.

Limits

If RIPEstat cannot be reached, the lookup stops with an error rather than showing partial data as complete. If only the neighbour or prefix data is missing, that section says so and the rest is shown.