摘要

  • RFC 7947 刻意把 IXP 路由服务器的控制面职责与转发路径分开。它通常不应把自己的 AS 写进 AS_PATH，并且必须保留原始 NEXT_HOP，因为流量应在参与者之间直接穿过交换网。
  • 客户收到的 UPDATE 因而可能来自路由服务器，但 AS_PATH 最左端和下一跳都指向另一位参与者。关闭首 AS 一致性检查只能限定在经过核验的路由服务器邻居上，不能顺手取消其他导入、环路与资源约束。
  • 完整证据必须贯通宣布方输入、路由服务器校验、逐客户选择、Adj-RIB-Out、客户 Adj-RIB-In、FIB、邻居解析和真实数据包。会话存活、总路由数相等或单个 looking glass 页面都不能代替这条链。

绿灯没有回答数据包去哪里

设想一个只使用文档专用地址和 ASN 的实验交换网。参与者甲向两台路由服务器发布一个探针前缀，参与者乙与两台服务器都建立了 eBGP 会话。乙从第一台收到 UPDATE：AS_PATH 以甲的 ASN 开头，NEXT_HOP 是甲在 peering LAN 上的接口地址，路由服务器自身的 ASN 没有出现在路径里。

乙沿用普通外部邻居模板，要求路径最左端必须等于会话对端 ASN。路由被拒绝，但会话仍然显示正常。工程师只对经过 IXP 官方资料核验的路由服务器地址关闭这项检查，路由随即进入 Adj-RIB-In，并最终装入 FIB。

此时数据包仍然不通。乙能访问路由服务器，却无法解析甲的 NEXT_HOP。交换网发生了非传递性故障：乙到服务器可达，服务器到甲也可达，乙到甲却不通。用服务器地址做探针，恰好绕开了真正的数据路径。

第二台服务器则没有向乙发送这个前缀。它的公共表里明明有甲的路径，但逐客户策略在错误的选择顺序之后把首选路径滤掉，也没有提供仍被乙允许的备选路径。两条 Established 会话，于是同时掩盖了两类不同问题。

这不是对任何真实 IXP 的事故指控，而是把路由服务器最容易被混淆的四个身份拆开：BGP 会话对端、AS_PATH 左端的 AS、NEXT_HOP 所属路由器，以及数据包真正穿过的设备。

它是经纪人，不是过路人

在共享二层网络上，每个自治系统若与所有其他成员建立双边会话，运维关系会迅速膨胀。路由服务器让成员通过少量会话交换许多网络的可达性，从而降低加入和维护成本。

这种系统并非被动收集器。收集器主要保存 BGP feed 供观测和分析；IXP 路由服务器参与实时路由分发，会校验路由、执行策略，并为不同接收者产生不同输出。

它也不是转发路由器。它运行 BGP、维护 RIB、做选择，却不应成为成员流量的中转站。数据包应该直接从接收者发往宣布者在交换网中的接口。

这一区别决定 AS_PATH 该记录什么。AS_PATH 服务于自治系统路径、策略和环路判断，不是所有处理过 UPDATE 的软件进程名单。路由服务器确实影响了结果，但仅因它传递了控制消息就把它写成一个转发跳，会制造错误历史，还可能改变接收者的选路。

因此，路由服务器既不是“透明所以无权”，也不是“集中所以统管”。它拥有一项受限职能：在不冒充转发参与者的前提下，经纪和筛选可达性。

属性透明是一项主动约束

RFC 4271 描述普通 eBGP 广告时的 AS prepend。RFC 7947 针对路由服务器给出不同建议：默认不要把服务器自己的 ASN 加进 AS_PATH，也不要随意改动路径。多出一个 AS 可能触发过滤、改变路径长度或影响下游决策。

对 NEXT_HOP，要求更为明确。因为服务器不转发流量，所以必须把原值传给客户。甲宣布路由，乙就应直接把包送到甲的 peering LAN 地址，而不是送到控制面中介。

其他属性也遵循相似原则：除非 IXP 明确公布的本地策略需要处理，路由服务器通常应保留收到的已知和未知属性。透明性的目的，是避免中介偷偷重写参与者的决策输入。

但透明不等于不作为。服务器仍可拒绝错误前缀，依据 IRR 或 RPKI 数据校验，解释用于分发控制的 Community，选择候选路径，并为乙建立专属视图。它的影响不会自动写入 AS_PATH，却真实决定乙能否看到该路由。

所以证据需要两本账。路由属性保存供控制和转发使用的路径事实；服务器运行记录保存“谁输入、哪条规则、为谁选择、实际输出”的经纪事实。拿其中一本冒充全部历史，都会造成错误归因。

首 AS 例外只能开一扇小门

普通 eBGP 接收端常检查 AS_PATH 最左端是否等于邻居 ASN。这在双边 peering 或 transit 关系中能发现有意义的错误。透明路由服务器却有意打破这种相等关系：UPDATE 由服务器发送，路径左端仍是原宣布者。

RFC 7947 因而要求实现允许关闭这项检查，并建议按邻居控制。安全性不在“关”或“开”两个字，而在作用域。运营者应从 IXP 权威资料确认服务器 ASN、地址和 AFI/SAFI，只在对应邻居对象上设置例外。

如果保留通用检查，会出现会话健康但所有有效路由被丢弃的假象。如果在全局模板中关闭，今后新增的 transit 和双边邻居也会失去本来有价值的一致性检查。

这项例外不代表客户交出最后决定权。客户仍需检查自己的 ASN 是否出现在路径里，执行前缀和来源策略、maximum-prefix、必要的 RPKI 或 IRR 约束，并独立决定哪条候选进入 Loc-RIB。路由服务器负责制作报价单，客户负责是否成交。

同一张最佳路径不能代表所有客户

路由服务器的价值之一，是允许宣布者控制路由发给谁。RFC 7948 列出 Community、路由注册数据和客户可访问策略库等方式。现实中的 IXP Manager、AMS-IX 和 LINX 文档也给出标准 Community 或 Large Community 的具体控制语义。

这些标签本身不是全球统一命令。它们只有在某个 IXP 公布的契约中，才表示“发给某 AS”“不发给某 AS”或“发给所有成员”。配置里出现标签，只能证明请求被表达；某个客户的 Adj-RIB-Out 才能证明请求被执行。

路径隐藏发生在选择顺序上。服务器收到同一前缀的两条路径，先在公共视角中选中甲。乙的策略随后排除甲。如果系统只把已选路径在出口删掉，乙便什么也收不到，尽管另一条路径符合乙的要求。

单看每一步都像正确：公共最佳路径有效，乙的拒绝规则也有效，空输出严格遵守过滤。错误在于用公共视角回答乙的个别问题。

RFC 7947 把逐客户 Loc-RIB 视为可移植的缓解方式：先应用客户约束，再从其允许的候选中选择。实现可以共享公共状态并仅保存差异，也可以用 diverse paths 或 ADD-PATH 提供多条路径。对 ADD-PATH，文档建议路由服务器面向客户只发送多路径，而不从客户接收其非活动候选，避免污染经纪输入。

FRRouting 当前文档描述了逐客户 Loc-RIB；AMS-IX 公布使用 BIRD 的 secondary 以避免 path hiding。名称和声明不是最终证据。测试必须构造两条候选，禁止公共首选，再查看备选是否真实进入特定客户的 Adj-RIB-In。

原样 NEXT_HOP 把校验责任集中到入口

保留下一跳让数据包绕过服务器，也带来劫持面。甲可以在宣布自己前缀时，把丙的交换网地址写成 NEXT_HOP。如果服务器照转，许多客户会把流量推向丙。

RFC 7948 建议服务器核对下一跳与宣布客户的接口地址，跨 AS 不一致时丢弃。同一 AS 拥有多个接入路由器时，可以在明确条件下允许例外。IXP Manager 文档展示了类似规则，并把它放在路径、前缀、IRR 和 RPKI 校验链中。

该检查适合放在服务器，是因为此处仍掌握“哪个会话送来这条路”的原始身份。等数百个参与者的路由聚合到乙的一条会话后，乙很难逐条重建谁有权填写哪个下一跳。

不过，授权正确不等于运行时可达。ARP/NDP、MAC 学习和交换网转发仍可能失败。控制面验证必须与参与者之间的直接数据面探针并列存在，不能用“能 ping 路由服务器”代替。

冗余的单位是可见结果

RFC 7948 建议在同一交换域部署多台路由服务器，也允许使用不同 BGP 实现和操作系统。实现多样性可以降低单一缺陷同时击中所有实例的概率。

但是，两台机器、两个进程或两条会话都不自动等于两份相同服务。服务器可能使用不同的策略生成版本、IRR 快照、RPKI 状态、收敛时点，或不同的逐客户选择算法。

总前缀数是过于粗糙的指标。两张表都含十万条路，并不保证某一 NLRI 的 AS_PATH、NEXT_HOP、MED、Community 和验证标记一致。真正的比对以客户为单位，为每个前缀计算相关属性指纹，并解释每个预期差异。

策略意图还必须能关联到正在运行的实例。配置生成号、数据快照标识和部署时间应出现在审计记录中。否则“两个服务器配置相同”只是无法复核的陈述。

从 UPDATE 到数据包的八段证据

一条路由至少需要以下记录相接：

  1. 甲的 Adj-RIB-Out 或链路抓包，证明原始广告；
  2. 路由服务器 Adj-RIB-In，证明服务器实际收到什么；
  3. 入口校验日志，解释接受或拒绝；
  4. 面向乙的选择视图和策略版本，解释候选如何决出；
  5. 服务器对乙的 Adj-RIB-Out，证明透明属性实际输出；
  6. 乙的 Adj-RIB-In，证明 UPDATE 穿过会话；
  7. 乙的最佳路径、FIB 和 ARP/NDP 状态，证明下一跳被选择并解析；
  8. 计数器、探针或抓包，证明数据包直接到达甲。

服务器主表不能替代乙的视图，公开 looking glass 也未必显示被拒候选。期望配置不能证明运行版本，某一时刻的 FIB 不能还原短暂收敛故障。每段记录都需要时间戳和身份，才能拼成因果顺序。

责任也沿此链分开。甲为宣布内容负责；路由服务器运营者为入口校验和逐客户契约执行负责；乙为本地导入和选择负责；IXP 为共享二层交付负责。任何一方都不能拿另一方的绿灯替自己结案。

用矛盾做上线测试

上线先从 IXP 权威资料锁定两台服务器的 ASN、地址、地址族、能力和 Community 契约。首 AS 例外只绑定这些邻居，其他约束维持原状。

随后用探针前缀逐段记录：原始 AS_PATH 和 NEXT_HOP、服务器校验、乙的专属视图、服务器输出、乙的接收、FIB 与包路径。预期结果不是“看起来像普通 eBGP”，而是路径左端仍属于宣布者、NEXT_HOP 仍是宣布者接口、服务器 ASN 没有为迎合检查而加入。

正向测试之后必须测试拒绝：只发乙不发丙，再反向；提供两条路径并禁止公共首选；填入另一个 AS 的下一跳并要求入口拒绝；IPv4 与 IPv6 分别执行。两台服务器逐属性比较，任何无法解释的差异都会暂停扩大导入范围。

回滚要保存客户侧和服务器侧的旧策略版本。恢复一条配置并不保证旧 UPDATE 已被撤销，可能还需 route refresh、策略重新评估或受控会话动作。动作范围应按影响选择，不应借机重启无关服务。

来源与边界

协议依据来自 RFC 7947，并与基础 BGP 规范 RFC 4271 对读。RFC 7948 提供冗余、泄漏、二层故障与 NEXT_HOP 劫持等运维建议。RFC 7911 和 RFC 6774 是多路径缓解方案的技术来源。

FRRouting、BIRD 与 IXP Manager 文档用于说明当前实现和自动化表面；AMS-IX 与 LINX 官方页面提供现实部署例子。它们不证明任何未具名 IXP 的实时状态，开篇场景也仅为合成实验。