Blogfoundation
Sugra NetAtlas: three kinds of truth about a network
State, flow and measurement are three different claims about a network. Registries describe intent, route updates describe events, and sixty thousand probes describe what is actually reachable.
Network questions look alike and are not alike. “Who owns this block”, “is this route authorised”, “is this network degrading right now” and “what does the path from Frankfurt actually look like” sound like four lookups against one database. They are four different kinds of claim, and treating them as interchangeable is how monitoring gets built that is confidently blind.
There are three kinds of answer here, and NetAtlas keeps them apart on purpose.
State is what the internet currently declares about itself. Allocations, announcements, cryptographic authorisations, registry contacts. It changes slowly and it answers “how things are”.
Flow is what is happening to that state. Route updates, withdrawals, outage signals, hijack events. It only exists as a time series, and it answers “what is going on”.
Measurement is neither. It is an experiment: thousands of physical devices asked to try something and report what they saw. It answers “what is actually reachable from where I am”, which no registry can tell you.
Most network data products sell you the first kind and let you assume it covers the other two.
State: nothing here has a single owner
Take one prefix that belongs to a very well known network:
GET /api/v1/network/prefix/34.1.0.0%2F20
announced: true
asns:
43515 YOUTUBE Google Ireland Limited
19527 GOOGLE-2 - Google LLC
15169 GOOGLE - Google LLC
block: 34.0.0.0/8, administered by ARIN (IANA IPv4 registry)Three autonomous systems, one prefix. Ask “which ASN announces this” and the honest reply is a list, not a value. Any schema that models this as a single field is going to be wrong for a large slice of the internet, and it will be wrong silently.
Zoom out to the network itself and the shape gets clearer:
GET /api/v1/network/asn/15169/prefixes -> 1,409 prefixes (1,231 IPv4, 178 IPv6)
GET /api/v1/network/asn/15169/peers -> 335 neighbours: 141 upstream, 20 downstreamThat peering split is the useful part. Upstream and downstream are not symmetric relationships, and a graph that flattens them into “connected to” loses the direction that determines who can reach whom when something breaks.
Authorisation is the only cryptographic layer
Announcement says someone is originating a prefix. It does not say they were allowed to. That question has a signed answer:
GET /api/v1/network/prefix/8.8.8.0%2F24/rpki?asn=15169
status: valid
roa: origin 15169, prefix 8.8.8.0/24, max_length 24The asn parameter is required, and refusing to make it optional is a design position. A prefix alone has no validity. Only the pair of a prefix and the network claiming it does. An API that accepted the prefix by itself would be answering a question that does not exist.
When two registries disagree, you get told
Ask who to contact about abuse for an address and the response carries a contradiction on its face:
GET /api/v1/network/abuse-contact/8.8.8.8
abuse_contact: email: "" source: ripe-db
cross_check: email: network-abuse@google.com source: ripestat
authoritative_rir: arin
agrees: falseOne registry has nothing. Another resolves a working mailbox. The field is called agrees and its value is false.
Most products would pick the non-empty one and return it. That is defensible, and it also means the caller never learns that the authoritative registry for this address holds no abuse contact at all, which is exactly the sort of thing worth knowing before you rely on a takedown process.
Flow: state is a photograph, routing is a film
A network is not a static object. It is constantly re-announcing itself, and the volume of that chatter is a signal in its own right.
GET /api/v1/network/asn/15169/updates (6-hour buckets)
2026-07-18 12:00 17,597 announcements
2026-07-18 18:00 101,697
2026-07-19 00:00 22,463
2026-07-19 06:00 31,588
2026-07-19 12:00 21,478
2026-07-19 18:00 43,591One window carries roughly six times the neighbouring traffic. Nothing in the state layer would show this. Query the prefix list before and after and you might see identical results, because the endpoints converged back to the same place. The interesting event lives entirely in the transitions.
The same distinction drives outage detection:
GET /api/v1/network/outage/alerts -> 50 alerts over the last 168 hours
AS138915 (KAOPU-HK) bgp critical value 643 vs history 655 method: median
AS29049 (Delta-Telecom-AS) bgp critical value 50 vs history 51 method: medianRead the method. These are not thresholds someone guessed. Each alert compares a current value against that entity’s own historical median, so “critical” means this network is behaving unlike itself, not unlike some global average. A network that normally announces 50 prefixes dropping to 50 is fine. The same drop for a network that normally announces 5,000 is an event.
Country-level questions pull from several independent datasources at once, so a single failing sensor cannot manufacture an outage:
GET /api/v1/network/outage/recent?country=IR -> 8 datasources, 30-minute stepsThe filter is mandatory here, and deliberately so: country, asn or continent, exactly one. “Show me all outages everywhere” is not a question with a useful answer.
Hijack detection runs on the same principle, comparing announcements against what the registry authorises:
GET /api/v1/network/hijack/recent -> rolling 7-day windowA quiet window is a result in its own right, and it is one you want logged with its timestamp rather than inferred later from the absence of an alert.
Measurement: the part registries cannot do
Everything above is observation of what the network publishes. The third kind of data is different: it comes from hardware.
GET /api/v1/network/atlas/probe/list -> 59,696 probes
probe #1 NL AS206238 connected since 2026-07-25T11:18Z
52.3475, 4.9275 prefix 45.138.228.0/22
tags: Home, NAT, Native IPv6, IPv4 Works, IPv6 Works, ...Nearly sixty thousand devices in homes and datacentres worldwide, each able to run a traceroute, a DNS query or a ping on request and report what it saw from where it physically sits. Anchors and measurements are addressable too, including raw per-probe results.
This is the only layer that can answer questions the registries structurally cannot. Whether a prefix is reachable from a particular country right now. Whether a path is being intercepted somewhere in the middle. Whether your own service is visible from the networks your customers actually use. A routing table describes intent. A probe reports experience, and the two diverge exactly when it matters most.
Privacy signals need their definitions read
Two addresses, both part of the Tor network:
| Address | Role | is_tor | risk | confidence |
|---|---|---|---|---|
80.82.76.41 | relay carrying the Exit flag | true | 50 | medium |
204.76.203.203 | relay, not an exit | false | 25 | high |
The second is a genuine Tor relay and is correctly not flagged. The signal is built from the published exit list, because exits are the only relays whose traffic reaches your service. Flag a middle relay and you have blocked a volunteer who never contacted you.
The same care applies to geography. Look up 8.8.8.8 and you get a city, coordinates to six decimals, and this:
privacy: is_anycast: true
_meta: accuracy: city, geo_confidence: lowBoth are true. The address is announced from many places at once by design, so a single city is meaningless for it, and the response says so in the same payload rather than in a footnote on a pricing page.
What the alternatives sell
MaxMind publishes accuracy for its own GeoIP City database: 99.8% at country level, 80% at state level, 68% at city level for the United States, at $148 per month (maxmind.com, checked 2026-07-25). ASN and ISP data is a separate database at $49, connection type another at $137, and the online pricing covers “Internal Restricted Business purposes only” with commercial use requiring a separate licence. ipinfo.io runs $0 for country-level with no privacy detection, $41 per month for city plus VPN and Tor detection at 150,000 requests, $130 to add residential proxy and carrier data (ipinfo.io/pricing, checked 2026-07-25).
Those are good products and the 68% figure is not a scandal, it is probably near the limit of what inference achieves. But notice what the whole category is: state data, and only state data. Geolocation and ASN attribution are a photograph. Neither vendor sells you route update volume, outage detection against a network’s own historical baseline, hijack timelines, RPKI validation, or sixty thousand probes you can ask to go and look.
For scale, Sugra Dev is $25 per month for 5,000 requests per day, roughly 150,000 per month, spanning all seven directions rather than network data alone. The honest trade-off: our limit is daily and cannot be spent in a single afternoon, theirs is monthly and can.
Every answer names the layer it came from
GET /api/v1/network/sources/coverage returns the provenance behind the atlas, source by source, with volumes and ingest times:
rir_delegated 260,915 IPv4 allocations, 146,872 IPv6 registry
routeviews_rib 1,099,703 prefixes bgp_collector
caida_geofeed 932,769 prefixes operator_published
tor_exits 1,394 addresses ingested 2026-07-24 privacy_signal
firehol_anonymous 2,538,556 CIDRs ingested 2026-07-24 privacy_signalRegistry, collector, operator-published and privacy sets are separate rows because they are separate kinds of evidence. A geolocation derived from what an operator published about its own prefix is a stronger claim than one inferred from measurement, and this endpoint is how you tell which one you are holding. Log it alongside the answer and a decision made three weeks ago stays explainable.
The join that mostly teaches you to distrust one signal
The natural pairing is physical events against connectivity: a flood happens, does the network in that country degrade. It is a good question and running it honestly is more instructive than the answer people expect.
Four countries with active hazards, connectivity signals over the same six-hour window:
Brazil flood web traffic -51% active probing -33% BGP 0%
Ethiopia flood web traffic +46% active probing +114% BGP 0%
Afghanistan flood web traffic -1% active probing +1% BGP 0%
Philippines earthquake web traffic -15% active probing +7% BGP 0%Brazil looks dramatic and means almost nothing. That window spans local night into morning, so a halved search volume is a diurnal cycle wearing the costume of an outage. Ethiopia moves the other way entirely. And the layer that would actually indicate broken connectivity, the routing table, does not move anywhere.
The correct reading is that nothing here shows a hazard breaking a network, and any dashboard that plotted the Brazilian line against the flood would have produced a compelling and false story.
What a real degradation looks like is different in kind:
GET /api/v1/network/outage/alerts
MPX-AS active probing critical 61 against a median of 78
AS51026 routing critical 28 against a median of 35
AS14315 routing normal 56 against a median of 56Each network compared against its own historical median rather than a global threshold, which is why the third line is quiet at a value that would be alarming for a different network.
So the join is worth building, and it is worth building with three conditions: a physical event with coordinates from Earth, a routing-level signal rather than a usage-level one, and a baseline that controls for time of day. One signal out of three proves nothing, and the usage layer is the one that will fool you first.
Where this stops
NetAtlas describes what the internet publishes about itself and what probes can observe. It does not tell you who attacked you.
Attribution is a legal and investigative act and no routing table supports it. A hosting flag is not intent, a risk score is not evidence, an abuse mailbox is a contact and not proof of who is responsible. We are not a SIEM and we do not replace your own capture. A clean privacy signal means the address was absent from the sets loaded when the atlas was built, which is a statement about our data rather than about the sender.
The metadata block is heavier in this direction than elsewhere. Responses carry confidence, accuracy, geo_confidence, partial, atlas_built_at and the full source list, because a network number without its uncertainty is not a smaller answer. It is a different one.
Running it
H="x-api-key: $SUGRA_API_KEY"
B=https://sugra.ai
# STATE
curl -sS -H "$H" "$B/api/v1/network/ip/8.8.8.8"
curl -sS -H "$H" "$B/api/v1/network/prefix/34.1.0.0%2F20"
curl -sS -H "$H" "$B/api/v1/network/asn/15169/peers"
curl -sS -H "$H" "$B/api/v1/network/prefix/8.8.8.0%2F24/rpki?asn=15169"
curl -sS -H "$H" "$B/api/v1/network/abuse-contact/8.8.8.8"
# FLOW
curl -sS -H "$H" "$B/api/v1/network/asn/15169/updates"
curl -sS -H "$H" "$B/api/v1/network/outage/alerts"
curl -sS -H "$H" "$B/api/v1/network/outage/recent?country=IR"
curl -sS -H "$H" "$B/api/v1/network/hijack/recent"
# MEASUREMENT
curl -sS -H "$H" "$B/api/v1/network/atlas/probe/list?limit=10"
# does a physical event show up in connectivity at all
curl -sS -H "$H" "$B/api/v1/network/outage/recent?country=BR"
# PROVENANCE
curl -sS -H "$H" "$B/api/v1/network/sources/coverage"Log atlas_built_at next to any decision you automate. When someone asks in three weeks why traffic was blocked, the answer is not the risk score. It is which atlas produced it.
Network observations, not attribution. Competitor figures taken from vendor pages on 2026-07-25 and subject to change. Atlas values pulled live the same day.
Previous: Sugra Entity. Next: Sugra News. Full series: Platform intro.