摘要

  • Nebius B.V. 在 RIPE 里只以 ORG-NB187-RIPE 这一个组织标识出面，其下分别登记了四个自治系统：AS203326、AS214415、AS213291 与 AS215169。
  • 登记是行政动作，宣告才是路由事实：其中两个系统合起来几乎占满 213.239.160.0/19，第三个的主要地址落在别处，第四个在两家独立观测站上都看不到任何宣告。

买 GPU 时长的人，其实同时买下一句关于底层网络的承诺。在 Nebius B.V. 这里，这句承诺今天装在一个注册对象里：ORG-NB187-RIPE，一个 2022 年 12 月 8 日建立、2026 年 8 月 5 日最后修改的 LIR 类组织，其下四个自治系统各自登记。数这四个编号，公司看着像有四张网；换成问一句「哪几个真的在宣告地址」，答案就不是四个，连那个三在两家观测站之间都对不齐。登记身份可以在 Nebius B.V. 的名录条目里查，网络本身得到别的地方读。

一个组织，四个名字

自治系统号是网络向注册库登记的识别码，好让别的网络能针对它写路由策略。登记这件事本身只是纸面动作。RIPE 的对象文档写得很直白：ASSIGNED 与 LEGACY 是 aut-num 对象上的行政状态，并不测量有没有流量在跑（RPSL 对象类型说明）。对象正文按类型公开，可按数据源、对象类型与主键经由注册库的 REST 查询取出（RESTful API 查询）。

这四个编号状态都是 ASSIGNED，都指向同一个组织，也都列着同一对维护者：RIPE-NCC-END-MNT 与 lir-nl-nebius-1-MNT。彼此不同的，是每个系统给自己起的名字，以及它对外声明的出口关系。

系统 登记名称 声明的出口 已宣告 IPv4 / IPv6（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

对象时间从 2023 年 1 月一路排到 2026 年 4 月：AS213291 是 2023 年 1 月，AS215169 是 2024 年 4 月，AS214415 是 2024 年 8 月，AS203326 最近一次改到 2026 年 4 月。四个编号、四个年代，身后站着同一个组织标识。

计数掩盖的算术

先看线上确实出现的东西。AS214415 宣告 213.239.160.0/21 与 213.239.168.0/21（Hurricane Electric，AS214415）。AS203326 补上 213.239.176.0/24、213.239.177.0/24 与 213.239.184.0/21（Hurricane Electric，AS203326；bgp.tools，AS203326）。

这五个前缀合起来覆盖 213.239.160.0 到 213.239.191.255，也就是一个 /19，但中间缺了一角。从 213.239.178.0 到 213.239.183.255 的六个 /24，在上面任何一条里都没有出现。是留着没动、分给了集团内部某个不对外宣告的系统，还是压根没分配出去，要由定义这段地址的 inetnum 对象说了算，而这次阅读并没有取到它。

两个 ASN，一段连续地址，互不重叠。从运维视角看，这才是值得写进正文的一句，而它在任何一个「自治系统数量」里都读不出来。

AS213291 不服从这套算术。它列出的 IPv4 空间里有 89.169.96.0/20（Hurricane Electric，AS213291），离那个 /19 相当远，而恰恰是它的前缀让观测站之间打起来。

登记了，却没在路由

要检验「一次登记到底意味着什么」，AS215169 是最干净的样本。它的出口列表在四个里最长——AS1299、AS9002、AS6762、AS12849、AS208905——而按 2026 年 11 月 10 日 18:52（太平洋时间）的页面时间戳，Hurricane Electric 给出的数字是 IPv4 零前缀、IPv6 零前缀、零宣告、零个可观测对端（Hurricane Electric，AS215169）。IPinfo 把该系统归为 inactive：无地址、无上游、无下游、无对端（IPinfo，AS215169）。

观测站里的零，是带着阈值的观测，不是从未启用的证明。RIPEstat 的 announced-prefixes 接口默认要求至少十个对端看见同一条宣告，被少于十个网络看见的东西直接从默认结果里消失（RIPEstat announced-prefixes 文档）。私有互联、上星期才开通的系统，或者永远走不出封闭互联组的流量，看起来都长一个样。这份材料只支撑一句范围很窄的话：在足够多对端可见的层面上，这个编号下没有正在宣告的公网流量。

三个数字，三个问题

AS213291 到底宣告多少前缀？有三个答案。PeeringDB 把 info_prefixes4 与 info_prefixes6 都记为 10，记录最后更新于 2024 年 10 月 10 日（PeeringDB，AS213291）；而这两个字段不是观测数据，它是运营方对「对端最多能看到多少条」的自我声明（PeeringDB 运营方指南）。Hurricane Electric 给出 IPv4 17 条、IPv6 17 条已宣告前缀，另有 23 条宣告（Hurricane Electric，AS213291）。bgp.tools 给出 IPv4 17 条、IPv6 16 条（bgp.tools，AS213291）。

三个数字都不算错。一个是承诺，一个是某家观测站累积的表格，另一个是另一家此刻的视角。它们分歧，是因为回答的不是同一个问题、跑的也不是同一个时钟。把其中任何一个当成「NebiusCloud 的规模」来引用，等于先挑好了一个问题，再把它包装成事实。

同一堂课，反着讲一遍

AS401712 属于美国公司 Nebius Inc.，不属于荷兰这家 LIR。Hurricane Electric 记它 1 条 IPv4、2 条 IPv6 已宣告前缀——2607:e840:220::/44 与 2607:e840:221::/48——另有 4 条宣告（Hurricane Electric，AS401712）。bgp.tools 的首页只显示一个前缀 104.204.96.0/24，那两条 IPv6 得打开低可见度视图才露出来（bgp.tools，AS401712，低可见度视图）。

这里分歧的方向正好相反。这不是一个什么都没有的系统，而是一个可见度集中在少数对端并未承载的前缀上的系统。同一天、两家观测站、两个都站得住脚的数字，没有需要化解的矛盾。

计数失效的地方

四个 ASN、一个组织标识、一对维护者，再加一个习惯：先把系统登记下来，路由晚点再填。公司靠并购长大时，把地址带过去的是那个组织对象；一个 ASN 完全可以在填不满的时候先挂着。这样读下来，真正耐久的身份是 ORG-NB187-RIPE 加上那套地址算术，而不是那个数字四。

拿这个计数当竞争指标同样站不住。有四张网的云，不是一张网的云的四倍；它只是有某种特定建设史的云——马德里一套、巴黎一个互联点、云业务本尊一套——每一步都带着自己的名字、自己的出口策略，以及写进注册库的上游关系。

这次阅读能定什么，定不了什么

本文引用的注册属性来自 RIPE 数据的公开镜像与路由观测站页面，不是注册库自己的对象正文；能划定分配边界的 aut-num、inetnum 与 route 对象也没有取到。留下来的记录更窄，但仍旧决定性：同一家责任组织名下四条登记，其中两条合填同一个 /19、中间空出六个 /24，第三条声明了五条过境关系却什么也看不见，第四条可见前缀的数量取决于你问哪家观测站、用什么阈值。

对一家 AI 云来说，这比任何 ASN 总数都更有信息量，而且注册库一开始就能给出这张图。地址、标识与维护者才是交易对方法律上真正继承下来的东西；那四个编号，只是报备习惯留下的痕迹。