Summary

  • Nebius B.V. answers to one RIPE organisation handle, ORG-NB187-RIPE, and fronts four separately registered autonomous systems: AS203326, AS214415, AS213291 and AS215169.
  • Registration is paperwork; origination is the routing fact. Two of those systems fill almost all of 213.239.160.0/19 between them, a third sits largely outside it, and the fourth originates nothing visible in either of two independent monitors.

If you buy GPU hours from an AI cloud, you are also buying a claim about the network underneath them. For Nebius B.V. that claim is filed as a single organisation handle — ORG-NB187-RIPE, an LIR-type organisation created on 8 December 2022 and last modified on 5 August 2026 — and the handle currently fronts four separately registered autonomous systems. Count those four numbers and the company appears to run four networks. Ask which of them actually originate addresses and the answer is not four, and not the same three on every monitor.

One organisation, four names

An autonomous system number is the identifier a network registers so that other networks can write routing policy toward it. The registration itself is paperwork. RIPE's own object documentation says so plainly: ASSIGNED and LEGACY are administrative statuses on aut-num objects, not measurements of whether anything is being routed (RPSL object types). The object bodies are published per type and can be fetched by source, object type and key through the registry's REST lookup (REST queries).

All four systems carry status ASSIGNED, name the same organisation, and list the same maintainer pair, RIPE-NCC-END-MNT and lir-nl-nebius-1-MNT. What differs is the name each one writes for itself and the exports it declares.

System Registered name Declared exports IPv4 / IPv6 originated (Hurricane Electric)
AS203326 NebiusMAD AS174, AS1299 3 / 2
AS214415 NebiusPA10 AS9002, AS1299 9 / 4
AS213291 NebiusCloud AS208722, AS200632 17 / 17
AS215169 CoreNebiusNet AS1299, AS9002, AS6762, AS12849, AS208905 0 / 0

The object timestamps in that file run from 2023 to 2026: AS213291 in January 2023, AS215169 in April 2024, AS214415 in August 2024, AS203326 as recently as 8 April 2026. Four numbers, four vintages, one incumbent handle behind all of them.

The arithmetic the count hides

Start with what is actually visible on the wire. AS214415 advertises 213.239.160.0/21 and 213.239.168.0/21 (Hurricane Electric, AS214415). AS203326 puts up 213.239.176.0/24, 213.239.177.0/24 and 213.239.184.0/21 (Hurricane Electric, AS203326; bgp.tools, AS203326).

Those five prefixes cover 213.239.160.0 through 213.239.191.255 — a /19 — with one hole in the middle. The six /24s from 213.239.178.0 to 213.239.183.255 appear in none of them. Whether that gap is held in reserve, allocated to something inside the group that does not advertise, or simply not yet assigned cannot be settled without the inetnum object that defines the allocation, and that object was not obtained for this reading.

Two ASNs, one address block, no overlap. That is the operationally interesting sentence, and it appears in no count of autonomous systems anywhere.

AS213291 does not fit that arithmetic. Its listed IPv4 space includes 89.169.96.0/20 (Hurricane Electric, AS213291), which sits well away from 213.239.160.0/19, and its prefixes are the ones the monitors argue about.

A registered network that is not routing

AS215169 is the cleanest test of what a registration actually means. It carries the longest export list of the four — AS1299, AS9002, AS6762, AS12849, AS208905 — and, in the page stamp of 10 November 2026 at 18:52 PST, Hurricane Electric reports zero IPv4 prefixes, zero IPv6 prefixes, zero announced and zero observed peers (Hurricane Electric, AS215169). IPinfo classifies the system as inactive, with no addresses, no upstreams, no downstreams and no peers (IPinfo, AS215169).

A zero in a monitor is an observation with a threshold attached, not a proof of non-use. RIPEstat's announced-prefixes endpoint defaults to a minimum of ten peers seeing an announcement, so anything visible to fewer than ten falls out of the default answer (RIPEstat announced-prefixes). Private interconnection, a system provisioned last week, or routing that never leaves a closed group would all look exactly like this. The record supports one narrow statement: no publicly visible traffic is being originated under that number by enough peers to register.

Three counts, three questions

Ask how many prefixes AS213291 originates and you get three answers. PeeringDB lists info_prefixes4 at 10 and info_prefixes6 at 10, on a record last updated 10 October 2024 (PeeringDB, AS213291) — and those fields are not observations. They are the operator's declared maximum expectation for peers (PeeringDB operator guide). Hurricane Electric reports 17 IPv4 plus 17 IPv6 originated, and 23 announced (Hurricane Electric, AS213291). bgp.tools reports 17 IPv4 and 16 IPv6 (bgp.tools, AS213291).

None of the three is wrong. One is a promise, one is a monitor's cumulative table, one is another monitor's current view. They diverge because they answer different questions on different clocks, and anyone quoting one of them as "the size of NebiusCloud" has picked a question and dressed it as a fact.

The same lesson running backwards

AS401712 belongs to Nebius Inc., the American company, not to the Dutch LIR. Hurricane Electric reports 1 IPv4 prefix and 2 IPv6 originated — 2607:e840:220::/44 and 2607:e840:221::/48 — with 4 announced (Hurricane Electric, AS401712). bgp.tools' headline shows a single prefix, 104.204.96.0/24; the two IPv6 prefixes surface only when the low-visibility view is switched on (bgp.tools, AS401712, low-visibility view).

Here the divergence runs the opposite way to AS215169. This is not a system with nothing visible; it is a system whose visibility is concentrated in prefixes most peers do not carry. Two monitors, one day, two defensible counts, and no contradiction to resolve.

Where the count stops being useful

Four ASNs, one organisation handle, one maintainer pair, one habit of registering a system before its routes are public. When a company is acquired or restructured, the organisation object is what carries the addresses forward; an ASN can be registered long before it can be filled. Read the file that way and the durable identity is ORG-NB187-RIPE plus the address arithmetic, not the digit four.

The count also fails as a competitive metric. A cloud with four ASNs is not four times a cloud with one. It is a cloud with a particular history of how capacity was stood up — Madrid, a Paris access point, the cloud business proper — each time with its own name, its own export policy and its own upstream relationships written into the registry.

What this reading can and cannot settle

The registry attributes here come from published mirrors of RIPE data and from route monitors, not from the registry's own object bodies, and the aut-num, inetnum and route objects that would prove the allocation boundary were not retrieved. What is documented is narrower and still decisive: four registrations under one responsible organisation, two of them tiling a single /19 with a six-/24 hole, one carrying five declared transit relationships and nothing visible, and one whose visible prefix count depends on which monitor is asked and at what threshold.

That is a more useful picture of an AI cloud than any ASN total, and it is the picture the registry was always able to give. The addresses, the handle and the maintainer are what a counterparty inherits. The four numbers are a filing habit.