Network

The Network group is the lookup and routing toolkit. Give it an ASN, an IP address or a domain and it assembles what is known from every source Atlas carries — RIPE registry data, PeeringDB, geofeeds and geolocation databases, live BGP from RIS, APNIC population estimates, and its own measurement-derived inferences.

Access varies a lot across this group; each view says what it needs.

ASN lookup

/network/asn · public

A single-record lookup for one autonomous system. The input commits on submit and the ASN is reflected in the URL, so a lookup is a shareable link.

From here, the Dossier link is where the value is.

AS dossier

/network/as/:asn · public

One composed "who is this network?" page, assembled in a single call from everything Atlas already caches:

• Overview — holder name, RIR, country, and how many IPv4 and IPv6 prefixes the AS announces
• RIPE Atlas footprint — probes in the AS, broken down by status
• PeeringDB presence — name, network type, and how many IXPs and facilities it appears at
• APNIC population — an estimate of how many users sit behind the AS
• Anycast — how many of its prefixes are in known anycast space

The pairing of population with probe count is the one to notice: it is exactly the ratio that AS population gaps ranks on, so the dossier is where you check an individual case against the fleet-wide view.

IP lookup

/network/ip · public

A fan-out aggregation for one address or one CIDR prefix — the input accepts either. The structured cards come first:

• Hero card — the headline facts about the address
• Geo cross-check — the geolocation sources side by side. Agreement is reasonable confidence; disagreement is a question worth asking, not proof that one source is wrong. See Geofeeds and geolocation.
• Map — where the sources place it
• Routing — announcement and routing status

Whois is rendered as structured tables, because it is the section people actually read. The remaining sources — MaxMind geoip, prefix and RIR allocation, reverse DNS, routing status, RPKI, IPmap — are available as collapsible raw JSON panels. Their shapes vary per address and per registry, so they are shown faithfully rather than flattened into a lossy common format.

Probes at an address, and across a prefix

Below the cards is the list of RIPE Atlas probes registered at the resource.

For a bare address that is the probes on exactly that address. For a prefix it is every probe whose address falls inside it, plus a connected probes per address table — one row per address in the range that has a probe, with how many probes sit there and how many of those are currently connected.

That table is usually the answer you want from a prefix lookup: it tells you which parts of a range have vantage points and how many are actually up. Each address links through to its own lookup.

Note the address family: a v4 prefix surfaces probes by their IPv4 address and a v6 prefix by their IPv6 address, so a dual-stack probe appears under whichever family you queried.

Domain lookup

/network/domain · public

A DNS chase for one domain: the forward resolution graph (hostname → addresses), the reverse graph (address → hostnames), and the nameservers consulted along the way. Rendered as nested lists rather than a graph, since most domains are small enough to read linearly.

The reverse graph is the interesting half — it is how you notice that a hostname's address also answers for a dozen unrelated names.

RIS Live

/network/ris · public

Live BGP updates for an ASN, from RIPE's RIS Live feed.

Two things to expect. The upstream sometimes declines a request — most commonly telling you it cannot serve the latest RIS Live data right now — and Atlas shows that as a soft warning rather than an error, because the request itself succeeded. And the response is currently rendered as raw JSON: the payload shape varies and isn't stable enough yet to justify a structured timeline.

Routing history

/routing/history · requires an account

Prefix and ASN announcements over time, as a chart. The chart owns its own URL state — the resource you are looking at, the zoom, and the filters — so a view you have set up is a link you can send.

One chart per page by design.

PeeringDB views

All staff.

• IXPs (/network/ixps) and IXP detail — internet exchanges and who is present
• Peering networks (/network/peering-networks) and network detail — the PeeringDB record for an AS
• Facilities (/network/facilities) and facility detail — data centres and their occupants

PeeringDB is self-reported and refreshed daily. It tells you where operators say they are present, which is useful and not the same as where traffic goes.

Anycast

/network/anycast, /network/anycast/intel, and per-prefix detail · staff

Known anycast prefixes with confidence scores and observed catchments, imported weekly from manycast.net. Read Anycast before relying on the scores — in particular the difference between the AnyBest probability and the dispersion figure, and what a partial prefix means.

Geofeed accuracy

/network/geofeed-accuracy · staff

Scores published geofeeds against the other available evidence. The view for "is this operator's feed any good?" — which matters because geofeeds are otherwise the most trusted geolocation source Atlas has.

---

Background reading: Anycast · Geofeeds and geolocation