摘要

  • 2026-11-10T00:04:49Z，PeeringDB 的 InterLAN-IX 交换中心记录（id 270）完成一次 IX-F 成员表导入，其中计 132 个网络；本文在 00:06:44Z 读取该记录，间隔不到两分钟。
  • 交换中心在自己的官网写明向伙伴提供两台 route server，但这句话没有地址、没有自治系统号、没有对等网段，也没有过滤或授权策略。

新鲜得可以核对的时间戳

PeeringDB 的交换中心 API 记录 返回的字段里，ixf_last_import 是 2026-11-10T00:04:49Z，ixf_net_count 是 132。本文的读取时间是 00:06:44Z。两个时间戳相差不到两分钟，说明这份机器可读的成员清单背后有一条自动导入流程在运转，而不是一份多年未动的手工快照。

同一份记录还给出：id 270，org_id 591，名称 InterLAN-IX，全称 InterLAN Internet Exchange Romania，城市布加勒斯特，国家 RO，所属大区 Europe，介质 Ethernet。这些字段能证明的事情很具体——这个交换中心在结构化记录里存在，有一个可以被机器读到的成员数，还有一个可以被任何人复核的更新时间。

不能证明的事情同样具体：它不说明商业中立，不说明过滤行为，不说明 route server 的自治系统号，也不说明任何一条公告是否获得授权。

两台 route server，一句话，没有句柄

交换中心自己在官网上写得干脆：

Pentru a facilita schimbul de trafic, InterLAN-IX pune la dispoziția partenerilor săi două route-servere care permit interconectarea directă cu majoritatea celor conectați.

大意是：为便于流量交换，InterLAN-IX 为其伙伴提供两台 route server，使其能与大多数接入方直接互联。

这句话交代了服务形态，也仅止于此。它没有给出两台 route server 的地址，没有给出它们的自治系统号，没有给出对等网段，也没有给出过滤策略，更没有说谁能向 route server 注入什么。对一个要接进来的成员来说，这些恰好是决定「我会收到什么」的参数；对一个做尽调的读者来说，这些是唯一能被独立复核的入口。

结果是：这个交换中心的公开可核查性停在机构层，接口层要靠问人。

一个被错当成交换中心身份的 ASN

这套检索开始时，工作集里有一个候选标识：AS39737。它曾作为「交换中心自己的 route server 自治系统」的候选出现。查看了 Hurricane Electric BGP Toolkit 的 AS39737 页面 之后，这个候选站不住了。页面原文写的是：

AS39737 Prime Telecom srl … Country of Origin: Romania … Internet Exchanges: 6 … Prefixes Announced (all): 414 / Prefixes Announced (v4): 392 / Prefixes Announced (v6): 22

也就是说，这个 AS 在这份第三方目录里属于 Prime Telecom srl，来源国罗马尼亚，接入 6 个交换中心，共宣告 414 个前缀（IPv4 392 个，IPv6 22 个）。这是一个成员型运营商的画像，不是一台中立 route server 的画像。该页面也没有说这个 AS 被 InterLAN-IX 使用，更没有把 414 个前缀和任何 route server 服务连起来。

这里必须把两个数分开：132 是某次 IX-F 导入里计入的网络数，414 是某一个自治系统宣告的前缀数。对象不同、单位不同、记录也不同。把它们摆在一起找「出入」，等于拿两把不同的尺子量同一段距离。

两种可核查性，别混着打分

把上面三份记录放在一起，会看到一条清晰的分界。

机构可核查性问的是：这个交换中心在公开结构化记录里存在吗？有没有可检查的参与者数和更新时间？InterLAN-IX 的答案是肯定的，而且时间戳新鲜到一个谨慎的读者会怀疑自己看错了。

公告可核查性问的是：哪些自治系统在发起 route server 实际交付的东西？谁控制这些系统？什么在验证发起方？在本文读到的记录里，这条链没有形成读者可以复现的路径。一个时间戳证明数据被发布，不证明由它促成的任何一条公告获得授权。

这是本文的分析框架，不是外部事实：把机构可见性和发起可见性当成两个独立的尽调类别，是我的判断。它的实用含义是，一个披露做得干净的中立交换中心，仍然可以在发起层不可读；反过来，一份把 route server 授权委托给某个成员运营商的公开文件，本身也不构成不当行为。

没读到的记录是限制，不是结论

RIPE 数据库里 AS39737 的 aut-num 与 inverse-origin 的 route/route6 对象，本次没有读到；交换中心自己的 route server 地址、对等网段，以及任何覆盖相关前缀的 RPKI ROA 状态，也没有取回。所以本文对发起层的说法是「未核实」，不是「缺失」「空白」或「宽松」。检索范围到此为止，这句话只说明这一次读到了什么，不说明注册库里有什么。

读者若要把这条链补上，路是现成的：交换中心公布 route server 自治系统号与过滤策略，或者把 route server 前缀的 ROA 放在一个可检索的位置。两件事都不需要披露商业条款。