摘要

  • Breizh-IX 称其路由服务器每晚用 bgpq4 严格模式重建前缀表，核验 RIR 的 ROA，并尊重 PeeringDB 的“Never via route servers”设置。其 RIPE 93 提案还要求检查路由数量与成员是否愿意由服务器再次通告。
  • PeeringDB 把这一设置称为供交换中心使用的提示。成员在资料页作出的选择，需要交换中心读取、写入策略并验证策略确已运行。

一张合格名单，还差一份转发委托

交换中心拿到成员的 AS-SET，展开其中的自治系统，再从路由登记库找前缀。一切对上，软件就有理由把某条通告纳入过滤表。但要把这条通告发给其他成员，还隔着一道门：原成员是否希望服务器代它转发？路由对象可以描述前缀与起源，不能替运营者指定收件人。

Breizh-IX 的 Evann Dreumont 与 Alarig Le Lay 在 RIPE 93 原始议程摘要里把问题拆为三项。其一，IRR 中的路由应属于客户的 AS-SET；其二，通告数量要合理，嵌套的 AS-SET 可能意外带入庞大的路由集合；其三，客户要愿意通过路由服务器再次通告。这场演讲安排在 10 月 28 日。摘要介绍了他们设计的 RS-API 代理方案，没有给出公开部署数量或错误率。把方案写成已经证实的治理成效，会越过证据。

路由服务器的便利说明了这道门的重要性。RFC 7947把它定义为多个 BGP 参与者之间的中介：成员不用为每个对端单独建立会话，服务器便可代为分发路由信息。一条错误纳入的通告，影响范围由服务器的客户策略决定。登记库中的对象与成员对分发范围的授权分别由不同的人维护；把两个信号混为一谈，省掉的是确认步骤，不是风险。

勾选框离运行中的策略还有多远

Breizh-IX 自己的网站列出当前的控制措施。这个总部在雷恩、由志愿者运营的非营利交换中心说，它每晚以 bgpq4 的严格模式生成前缀列表，没有 route 对象的前缀会被拒绝；服务器检查 RIR RPKI 的 ROA 与 OTC 属性，第二台还检查 ASPA。网站还明确称遵守 PeeringDB 的“Never via route servers”字段。这是运营者对现行做法的陈述，不能代替逐条路由审计，但比会议标题给出的信息具体得多。

PeeringDB 官方常见问题把字段的 API 名写为 info_never_via_route_servers，同时称它是给交换中心的提示。资料库可以保存成员的选择，却不能远程修改任何交换中心的 BGP 配置。PeeringDB 要求网络确认所连接的交换中心会定期检查并尊重这一设置。于是责任分成三段：成员修改资料，数据库公开状态，交换中心在运行策略里兑现它。

最容易被忽略的是时间。成员上午撤回经路由服务器通告的意愿，交换中心的路由对象列表晚上才重新生成；这两套数据未必用同一时钟。公开材料没有记录 Breizh-IX 各服务器读取 PeeringDB 字段、写入策略和实际生效的逐次时间，因此本文不把时差当成该中心已经发生的事故。真正有用的证据，是一次具体修改对应的抓取时间、配置版本和后续出站通告。成员需要知道“不再经服务器通告”从哪一刻起算。

数量检查也需要可追溯的理由。一个 AS-SET 递归指向另一个集合，软件能够准确展开，结果却可能大得离谱。给它一个任意高的 max-prefix 阈值，同样不能证明名单合理。RS-API 摘要指出这些记录和实际路由需交叉核对，人工逐户更新难以扩展。将来的工具若能显示“哪一层嵌套使列表膨胀、谁批准了阈值、何时回滚”，才算把自动化变成可问责的操作。

给每次转发留下决策收据

一张合格的收据应同时写明 AS-SET 与 route 对象的版本、展开后的前缀数量、适用阈值、PeeringDB 标志的抓取时间、最终加载到哪台服务器，以及通告发送给哪些对端。路由被拒时，成员能定位是登记、数量还是转发意愿出了问题；路由被接受时，也能看见服务器凭什么替自己说话。

剩下的核心问题是缺项时的默认规则。PeeringDB 暂时不可用、资料太旧、登记数据与成员设置冲突，服务器会怎样做？已核对的公开材料没有说明 RS-API 的冲突处理规则。公布默认值及变更记录，就能把判断从“信任过滤器”推进到“核对谁作了哪一个决定”。

来源