摘要

  • PIT-IX 的交换点记录写明三处机房关联、三十六个注册网络，以及 2026 年 11 月 4 日 01:14 刷新的四十一个网络的 IX-F 导入——足以排除“只有一间机房的俱乐部”这种猜测。
  • 同一份记录一处机房也没点名；而成员真正建立会话时配置的 AS30365，机房关联为零、交换点关联为零、机房关联日期为空。

这份记录并不寒酸。它带着 PIT-IX 这个名字、别名 PIT-IX Pittsburgh、全称 Pittsburgh Internet Exchange、城市匹兹堡、大洲分组北美。它写明 fac_count 为 3、net_count 为 36、ixf_net_count 为 41，IX-F 导入时间戳是 2026-11-04T01:14:26Z，读到时不过几小时（PeeringDB 的 PIT-IX 交换点记录）。介质标明以太网，单播与 IPv6 为真、组播为假。它宣告开放对等策略、不要求接入地点、不要求合同；紧接着又说服务等级“未披露”、条款“未披露”。交换中心的建档日期是 2017-11-07，最后一次修改是 2025-08-05。

这是一份清点清单，而且清点得挺整齐。但它不是地图。

数出三个，几乎可以意味着任何事

三处机房是事实，也是弱事实。同一栋楼里的三个机笼，共用一路市电、一套冷机、一条光纤入口，通常还共用同一条街下的同一段管道。三栋彼此独立的楼，各走独立的配电和独立的进线路径，遇到挖掘机挖错管道时的表现完全是两回事。机房数量这个数字区分不了这两种世界，因为两边数出来都是三。

组织记录只填了一个地址：1016 North Lincoln Ave，宾夕法尼亚州匹兹堡 15233，坐标 40.450257、-80.020202，2017 年建档、2022 年最后一次改动（PeeringDB 组织记录 18417）。现有记录里没有任何一处把这个地址绑到被计入的那三处机房上。它可能是其中之一，也可能是间办公室，也可能是门后没有任何设备的法定注册地址。读者分不出来，记录也没给任何猜测。该组织的运营商集合与园区集合都是空的，连条传输线索都没留下。

成员要配置的那个 ASN，字段是空的

真正扎手的地方在这里。PIT-IX 的成员不是跟“交换点”这个对象做对等，而是向一个自治系统配置 BGP 会话，而组织自己的网络列表写得很清楚：AS30365，名称“PIT-IX Route Servers”，类型为路由服务器，作用域为区域级，关联 IRR AS-SET AS-PITIX，前缀上限为 IPv4 十万条、IPv6 三万条（PeeringDB 组织记录 18417）。这个 ASN 的网络记录把网站指向交换中心，名称也照抄同一套（PeeringDB 的 AS30365 网络记录）。注册库那边也吻合：29696–30719 这个由 ARIN 在 IANA 十六位 AS 号段内分配的块，持有者写作“PITIX - Pittsburgh Internet Exchange”（RIPE NCC 的 AS30365 概览）。

身份从三个方向都确认了。可在确认身份的同一份记录上，fac_count 是 0，ix_count 是 0，netfac_updated 是空值。这个对象的交换点—网络关联最后一次更新停在 2023-09-14。

零字段不是证人证词。它不证明路由服务器不在任何地方，它只证明记录没有就“在哪儿”作出任何主张——而这恰恰是全部问题所在，因为潜在对等方、保险方、做接入前核查的网络工程师，真正会去读的就是这份记录。“我的 BGP 会话会不会跟我的端口吃到同一套物理设施”这个问题，决定一位成员的流量能不能扛过一栋楼的事故，而它在这个 ASN 的任何字段里都找不到答案。

同一个组织下还有第二个 ASN，它把事情搅得更糊而不是更清：AS400798，“Pittsburgh Internet Exchange Services”，2023-06-28 建立，ix_count 为 1、fac_count 为 1，交换点—网络关联更新到 2026-03-26。哪个身份承载成员服务、哪个承载交换矩阵，现有字段一个字都没说。

三十六与四十一

两个网络计数相差五个，而现有材料没有一处界定各自的统计口径。读者无法确定 IX-F 导入里是否包含只属于路由服务器的条目，也无法确定一个数算的是成员、另一个算的是与前缀相关的会话，更无法排除这只是运营方自己的名册与自动导入流之间惯常的滞后。IX-F 时间戳只能证明 2026 年 11 月 4 日上午跑过一次导入，既不证明流量，也不证明可用性，更不证明任何单个成员的体验（PeeringDB 的 PIT-IX 交换点记录）。文件很新，跟交换矩阵健不健康是两码事。

对等方真正需要的四件事，以及这份记录扣住的东西

第一，名字。一份没有地址的机房统计，没法拿来对照成员自己的布点、它的运营商，或者它客户早已进驻的那些楼。

第二，路由服务器功能是否存在于三处中的两处以上。任播路由服务器与按站点分设的多套实例，是两种不同的产品，故障行为和运营成本都不一样，而记录在这两者之间保持沉默。

第三，成员的端口与它的路由服务器会话，能否被有意放进不同的故障域。没有这张对照图，成员提出“要冗余”就是在要一个背后没有任何书面依据的承诺。

第四，站点之间的流量怎么走、谁控制这条传输。交换中心自己的统计页面和路由服务器页面（两条记录的引用都在），本文都没能取到；交换点 1999 的机房列表同样没有取到：三次请求分别返回权限错误与容量错误。列表缺失是因为没取到，不是因为任何人证明了它不存在。这条限制要跟在结论旁边，而不是塞进脚注，因为它正好区分了两件事：一个藏起自己拓扑的运营方，和一份根本没被要求交代拓扑的记录。

商业面更直白。服务等级与条款都标为未披露。比较接入方案的买方能看见 PIT-IX 存在、开放、已经不止一间房。而在韧性这件事上，公开记录给出的仍是一个数字，而这里需要的是地图。在那三栋楼有了名字、路由服务器在至少两处有了地址之前，诚实的读法只有一句：这是清点，不是拓扑。