摘要

  • AMS-IX 在阿姆斯特丹运营两台路由服务器，同为 AS6777，分别是 rs1.ams-ix.net 与 rs2.ams-ix.net；参与意味着两台都要建立会话。
  • 规范只强制一种行为——原样传递 NEXT_HOP——却把 AS_PATH 与 MED 的保持列为建议，并给出了理由。
  • 已公开材料中唯一明确的义务分配，是把前缀列表一致性以及配置合规放在参与者一侧。

一家接入阿姆斯特丹交换中心的网络选择加入路由服务器后，不再逐对端建立 BGP 会话，而是把一条会话建到一台机器上，由它转播其他参与方所宣告的内容。AMS-IX 公开了两台：rs1.ams-ix.net，地址 80.249.208.255 与 2001:7f8:1::a500:6777:1；rs2.ams-ix.net，地址 80.249.209.0 与 2001:7f8:1::a500:6777:2，二者皆以 AS6777 运行。条件写得很具体——两台都要连、每条会话宣告的前缀数量与长度必须一致、主动发起 TCP 179 端口——AMS-IX 的路由服务器文档把这些条款摆得很直白。

这份文档没有做的，是让运营方承担一套对等分量的承诺。它描述行为。它明确列出的义务属于参与者。

规范唯一不让步的地方

RFC 7947定义了交换中心的路由服务器，其最硬的约束落在一个地址字段上：“the NEXT_HOP attribute MUST be passed unmodified”（第 2.2.1 节，2016 年 9 月）。这一句解释了为什么路由服务器对数据包而言根本不算路由器：客户端看到的下一跳是宣告方在交换矩阵上的地址，流量由此在矩阵上对等直传，从不经过那台替它说 BGP 的机器。RFC 7948是同月发布的操作文档，划的也是同一条线：分发可达性信息不等于转发流量。

属性处理一节里其余内容都更软，而且是刻意的。路由服务器“SHOULD NOT prepend its own AS number”，即不得在转播路径前加上自己的 AS 号（第 2.2.2.1 节）。它传递 MULTI_EXIT_DISC，并“SHOULD NOT modify its value”（第 2.2.3 节）。第 2.2 节把属性透明定为默认行为，同时明文允许在本地配置需要时例外；第 2.1 节干脆允许基于策略的过滤。

RFC 自己写明为何在 AS_PATH 上止步于 SHOULD 而非 MUST：存在一批老客户端，一旦看到意料之外的首个 AS 就拒绝会话，若定为强制规则，这批设备会被直接抛下。于是规范转而要求实现必须允许关闭首 AS 校验，最好能按对端关闭，而不是扛下更重的保证。这层工程妥协披着“要求等级”的外衣，对任何以为交换中心已承担“绝不碰我路径属性”绝对义务的人来说，这一点很要紧。

运营方真正写进文档的部分

AMS-IX 公布了自己那一半约定。它不会把 AS6777 插入所转播路由的 AS_PATH，且适用处必须关闭首 AS 校验。出口对端由 RPSL 条目与 community 选择：community 0:6777 阻断全部出口，6777: 打开指定对端；新会话默认启用 IRRDB 与 RPKI 合并过滤。学到的路由可以服务参与方自身及其下游客户，但禁止再分发给上游、外部对端或另一家交换中心的路由服务器。

那段材料里有两句话值得读第二遍。第一句提醒，IRRDB 与 RPKI 数据不附带有效性保证，不应单独依赖——这是运营方对自己默认过滤方式的说明。第二句是责任条款：“Participants are responsible for ensuring that their routing configuration complies with this policy.”

RFC 7948 早就落在同一个分配上。它写明客户端有责任“to ensure that their stated prefix list is compatible with what they announce”（第 4.3 节），建议运营方一侧做泄漏缓解，并主张在存在按客户端入向过滤的地方，对收到的路由与配置好的前缀列表做自动比对。文件勾出的角色是行政性的而非托管性的：路由服务器过滤、选择、再宣告，运营方公布自己做了什么，没有人对每一个具体参与者承担逐项列举的核验义务。

我原本想找的东西，与文本实际写的

我去找的是一份写明的交易：给每个成员一条会话，换回一纸清单，说明交换中心欠你什么。文件只支持了前半截。交易确实存在——会话数量是真真切切地塌缩了——但它的计价单位是暴露面，而不是服务水平。一条绝对 MUST 让数据包不进那台共享设备；两条 SHOULD、一段兼容性理由，再加上本地配置的敞口，让运营方在路径选择与 MED 上保住了自己的手。

所以有用的读法不是“AMS-IX 的路由服务器不认真”，而是这套安排被设计成一个权限受限的管理者：允许做控制平面决策，禁止转发哪怕一个数据包，问责主要通过公开文本完成。这个框架是我的，不是 IETF 的，也不是交换中心的，没有任何正式立场这样表述。

参与者实际能核验的东西

这个路由服务器的名录条目把同样几件公开事实收在一处，而核验难题恰好藏在它们没说的部分。参与者无法靠读一页政策来审计共享设备的内部合规性。它能做的是读自己收到的路由，确认看到的下一跳是对端而不是路由服务器；观察 0:6777 与 6777: 是否产生文档所描述的出口行为；并且把两台会话都维持住、比对各自发来的内容，让分歧以分歧的样子出现，而不是变成一桩悬案。

该文档在发布版本上没有标注日期，检索于 2026 年 11 月 12 日，其在刊发当日的时效性未获确认。本文没有实测线上行为；所检视的页面也不足以确定 rs1 与 rs2 在默认过滤与 community 出口控制上是否完全一致。全文只找到一条显式的责任表述，涉及前缀列表一致性；该页面上没有更宽泛的运营方担保，这是对那一页的观察，而不是“别处也不存在此类文本”的证据。

这笔交易的老实话

路由服务器只说话，不承载流量，文书也是这个形状：一条无条件承诺把流量挡在那台设备之外，两条有条件承诺让交换中心在引导流量的属性上腾出手来。需要更多保障的网络不会在政策文本里找到它。它会在自己的接收路由里找到，或者找不到——而那正是文件早已放置责任的地方。