摘要

  • MIX 在 2025 年 6 月 26 日的说明中写道，合理规划的运营商应通过预留充足转接容量和分散对等互联等方式吸收 IX 路径失效的影响 [1]。
  • MIX 同时指出，频繁不稳定会给路由收敛和流量重收敛带来风险；因此，问题不只是拓扑上是否存在单点，还包括大量路由同时变化时的运行结果 [1]。
  • MIX 当前的路由服务器文档列出 ASN 61968、基于 IRR 的前缀清单、AS_PATH 检查、拒绝 RPKI INVALID 路由，以及供参与者控制传播范围的 BGP community [2]。
  • 这些控制负责路由准入与分发，不负责创造备用传输容量，也不能单独证明业务在重收敛期间保持可用。
  • 问责证据必须把预期设计与实际撤回、替代路径选择、流量迁移、剩余容量和应用结果连在同一时间线上。

MIX 的表述究竟意味着什么

MIX 并未声称交换中心永远不会中断。它的核心观点是：准备充分的网络不应把一个对等互联局域网当作全部互联网可达性的唯一来源。文中给出的两个具体手段是，为上游转接保留超额容量，以及采用多样化的对等互联策略 [1]。这意味着连续性责任既在交换中心内部，也在每个参与网络内部。

IX 提供共享互联环境，但成员仍是独立自治系统。它们自行决定上游、PNI、其他交换中心、local preference、community 和容量。路由表中存在第二条路径，并不能证明它会及时成为最佳路径，也不能证明所有必要前缀会被接受，或迁移后的流量不会压满备用链路。

MIX 对频繁中断的提醒更值得审计。它指出，大规模环境中的路由收敛和流量重收敛会产生连锁影响 [1]。许多会话可能同时改变，平时只承担少量溢出流量的转接链路会突然承受相关性很高的负载。单链路测试通过，不等于这种共同变化也能安全通过。

拓扑备份不等于连续性结果

连续性应被记录为两个运行状态之间的可验证转换。变化发生前，运营商需要保存外部 BGP 会话清单、邻居角色、预期路由集合、优先级、community、最大前缀限制和可用容量，并明确哪一组链路将在 IX 路径消失后承担流量。

变化过程中，需要记录会话状态、撤回时间、替代通告、最佳路径选择和流量移动。变化结束后，还要核验丢包、时延、拥塞、路由抖动和应用成功率。没有这些数据，“流量已经切换”只是一段机制说明，不是结果证明。

所谓多样性也可能共享底层依赖。两条链路可能经过同一台路由器、同一供电域、同一光纤路由或同一控制进程。容量规划也可能使用相同的低估假设。因此，故障演练必须覆盖共同依赖和同时迁移，而不是只拔掉一根空闲链路。

必须区分交换 fabric 与路由服务器

MIX 的路由服务器用于简化多边对等互联。官方文档显示该服务使用 ASN 61968，并依据主要 IRR 数据库生成参与者可通告前缀清单。路径首个 ASN 必须与对等 ASN 一致，私有或无效 ASN 等异常会被拒绝，RPKI 验证为 INVALID 的路由也会被拒绝 [2]。

参与者可以通过 community 控制路由向哪些客户端发布。数据流量不会经过路由服务器转发，而是在对等局域网邻居之间直接交换；路由服务器 ASN 也不会出现在 AS_PATH 中 [2]。RFC 7947 描述了这种多边路由服务器模式 [4]。

这些边界不能混淆。IRR、RPKI 和路径检查约束的是路由分发。它们不能维持物理交换 fabric，也不能替参与者购买备用转接，更不能治理所有双边会话。审计至少要分别检查共享交换平面、路由服务器控制平面和成员自身的双边或上游路由。

交换中心应提供的证据

MIX 应能重建交换机、内部链路、成员端口和路由服务器进程在变化窗口内的状态。对 fabric 来说，有价值的记录包括接口错误、拓扑变化、ARP 或邻居发现行为、广播与组播速率、控制平面保护和受影响端口范围。

对路由服务器来说，需要会话状态、接收与拒绝路由数量、策略版本、IRR/RPKI 数据新鲜度、community 处理和 BGP 更新速率。内部监控还应与外部路由观察和成员报告对齐，因为管理面显示正常时，远端仍可能看到部分不可达或路径不稳定。

公开复盘不必泄露敏感配置，但应说明影响的是哪一个服务面、起止边界、失效的控制类别、参与者影响范围、持久修复以及用于证明同类条件会被安全阻断的负向测试。

参与者应提供的证据

参与者必须证明 IX 状态变化是否传导成客户故障。仅截图显示备用 BGP 会话为 Established 不够。路由记录应说明哪些 IX 路径消失，哪一条转接、PNI 或其他 IX 路径成为最佳路径，选择耗时多久，以及哪些前缀没有替代路径。Adj-RIB-In、本地决策和对外通告记录可以区分“没有备份”与“有备份但策略未选中”。

流量记录应说明每个互联点承接了多少负载、剩余余量、丢包和时延如何变化。模型要考虑多个成员同时重收敛。即使本地端口未满，上游更深处仍可能拥塞。

最后还需要外部 DNS 与应用探针。BGP 已经收敛不代表业务完成恢复。状态防火墙、返回路径或流量工程规则仍可能阻断交易。用户结果才是最终指标。

路由安全与可用性不是同一个目标

MIX 文档中的 RPKI INVALID 拒绝是重要准入控制 [2]。IRR 清单和路径检查提供了其他约束。RFC 7454 给出 BGP 安全实践，RFC 9234 则引入 BGP Roles 与 Only-to-Customer [5][6]。

但来源合法的路由仍可能容量不足、传播关系不当或因传输故障而消失。反过来，过期的注册数据也可能挡住合法的应急路径。正确做法不是在故障时放宽一切过滤，而是平时维护授权账本，并同时演练应该接受和应该拒绝的路由。

注册记录是账本，不是运行结果

PeeringDB 当前把 AS16004 与 MIX S.r.L. - Milan Internet eXchange 关联 [3]。这种身份连续性有助于联系、配置和核验关系，却不能说明某个数据包是否被转发，也不能说明哪条路由被选择。

这正是本文的 Heng.lu 表面：注册机构和目录是账本与记录者，不是替代运行网络的主权保证。问责结论来自身份、预期策略、部署配置与实际路由的对账。四者出现差异时，即使用户尚未投诉，也应视为运行事件。

可审计的重收敛证据包

一个完整证据包至少包括五部分：预期拓扑与会话角色；触发与处置时间线；变化前中后的路由；流量与服务结果；修复、回滚和重复演练。证据应保留不确定性，不能把未知的 fabric、路由服务器或成员策略问题强行归因给某一方。

MIX 的说明给出了合理设计目标：准备充分的成员不应把单一 IX 变成绝对依赖 [1]。能否做到，要靠交换中心与参与者用一致时间戳和会话标识拼接证据。冗余不是链路数量，而是在可接受损失内完成的一次可验证状态转换。

来源

  1. https://www.mix-it.net/en/the-peering-lan-is-not-inherently-a-critical-point-of-failure/
  2. https://www.mix-it.net/en/route-server/
  3. https://www.peeringdb.com/api/net?asn=16004
  4. https://www.rfc-editor.org/rfc/rfc7947.html
  5. https://www.rfc-editor.org/rfc/rfc7454.html
  6. https://www.rfc-editor.org/rfc/rfc9234.html