摘要

  • 2012 年 11 月 6 日约 02:24 UTC，Cloudflare 发现部分互联网路径无法访问 Google 服务。其公布的一条路径依次经过 AS4436、PCCW/AS3491、Moratel/AS23947，最后到达合法的 Google 源 AS15169 [1]。
  • Cloudflare 将其描述为约 27 分钟的有限中断，并估计可能影响全球互联网人口的 3% 至 5%，香港周边影响更明显。这是 Cloudflare 的估算，不是独立的全网普查 [1]。
  • RFC 7908 后来把 Moratel-PCCW 事件列为第四类路由泄漏案例：从横向对等方学到的前缀被通告给转接提供商，超出了原定传播范围 [2]。
  • Cloudflare 最初判断错误通告很可能源于操作失误；后续更新则记录了 Moratel 的说法：异常由意外硬件故障造成，并非恶意行为 [1]。公开证据不足以还原内部故障链的全部细节。
  • 问责边界同时覆盖出口和入口。Moratel 需要阻止未授权路由离开相关会话；PCCW 需要判断客户通告是否来自允许的客户关系，而不是把从其他关系学到的路径继续传播。

公开记录能证明什么

Cloudflare 称，其员工在约 02:24 UTC 注意到 Google 服务离线。最初的症状像是 DNS 故障，因为从其网络甚至无法到达 Google 公共解析器 8.8.8.8。随后，路径追踪显示流量经过印度尼西亚的 Moratel 地址。对于从加州前往 Google 的流量，这是一条异常绕行，调查因此转向 BGP 控制平面 [1]。

Cloudflare 公布的 Google 前缀路径包含 AS4436、AS3491、AS23947 和 AS15169。末端的 AS15169 仍是 Google 的合法源。问题并不是一个陌生网络简单冒充 Google 起源，而是路径中间出现了不符合关系预期的传播。一条终点身份正确的路由，仍可能把流量吸引到没有被授权或没有准备承载它的网络。

Cloudflare 表示，它联系了 Moratel 的网络工程人员。异常通告在约 02:50 UTC 被纠正，约三分钟后路由恢复正常 [1]。时间短并不意味着没有运营影响。目的服务器可以保持健康，而远端用户仍因域间路径错误而看到服务不可达。应用、DNS 和支持团队可能在自己的系统中排查，而实际故障位于它们无法直接控制的网络关系上。

对影响范围必须保持克制。Cloudflare 是重要的现场观察者，但它看不到每一个用户、网络和 Google 产品。3% 至 5% 的数字必须保留来源归属，不能写成全网确认值。对根因也一样：初始文章提出了可能的错误操作，更新则转述 Moratel 的硬件故障说明。没有路由器日志、硬件告警、配置历史和内部时间线，外部观察者无法判断硬件、软件、配置、故障切换或多项因素中哪一项首先破坏了策略。

为什么这是第四类泄漏

BGP 用于自治系统之间交换可达性。每个自治系统由 ASN 标识，并执行自己的路由策略。一条通告包含 IP 前缀、AS_PATH 和其他属性。路由器决定接受什么、优选什么，以及向下一个邻居重新通告什么。

这些决定同时表达商业和运营关系。客户通常向提供商购买互联网转接；对等网络通常交换彼此及各自客户的路由，而不是互相提供完整转接。因此，一条路由在接收它的对等会话上可能有效，但在向上游提供商导出时却应被禁止。

RFC 7908 将路由泄漏定义为路由通告超出预期范围的传播。第四类描述的是一个自治系统把从横向对等方学到的路由通告给自己的转接提供商。该 RFC 明确把 Moratel-PCCW 泄漏 Google 前缀列为案例 [2]。

这也解释了为何只做源验证不够。AS15169 仍位于路径末端，源身份可能完全正确。真正需要验证的是传播关系：AS23947 是否被允许把该路径导出给 AS3491，AS3491 又是否应把它当作客户路由接受。正确起源不等于正确路径。

出口侧的证据责任

导出路由的运营商应能还原具体 BGP 会话、会话角色、收到的路由、本地选中的路由，以及实际向邻居发出的路由。证据应区分自有前缀、获授权的客户路由、从对等方学到的路由和从提供商学到的路由。

如果硬件故障触发了异常，事后报告还应解释该故障如何改变路由策略。设备重启是否加载了不完整配置？备用路径是否使用了更宽松的策略？收敛期间是否临时通告了不应外发的表项？过滤器是否在故障状态中被绕过？“硬件故障”只能说明触发类别，不能解释为何出口会以开放方式失效。

有效证据必须把意图和运行状态连接起来。配置差异很重要，但还需要 Adj-RIB-Out 或等效的已通告路由记录、相关社区属性、设备事件、精确时间戳、变更责任人和撤回顺序。只有这些记录能说明修复关闭了泄漏通道，而不只是移除了眼前症状。

上游接受侧的证据责任

Cloudflare 将 PCCW 描述为 Moratel 的上游，并称 PCCW 信任并传播了 Moratel 发来的路由 [1]。当前 RDAP 把 AS3491 标识为 PCCWG-APAC-HK，并关联到 PCCW Global (HK) Limited [6]。这能支持当前身份连续性，但不能代替对 2012 年商业关系和会话策略的完整重建。

上游网络不是被动管道。它决定接受哪些客户通告、如何分类，以及向哪些邻居继续传播。它应保存获授权前缀和源、预期客户锥、允许的路径模式、最大路由数、异常阈值和例外审批。如果客户确实需要携带大量第三方路由，过滤会更复杂；复杂性要求更准确的授权账本和更频繁的核对，而不是取消过滤责任。

大型上游会放大局部错误。客户发出第一条错误路由，并不意味着上游可以用“客户发来的”结束复盘。上游提供的产品就是受控传播。它应能证明何时收到、为何接受、如何优选，以及向哪些网络再次通告了该路径。

注册记录与运行现实

APNIC 当前 RDAP 将 AS23947 标识为 MORATELINDONAP-AS-ID，并关联到 PT. Mora Telematika Indonesia [5]。AS3491 的 RDAP 将其标识为 PCCWG-APAC-HK，并关联到 PCCW Global (HK) Limited [6]。这些记录为号码资源身份、联系和运营连续性提供基础。

它们并不能显示 02:24 UTC 时路由器执行了什么。注册记录可以说明谁运营 ASN，却不能说明某个会话加载了哪份策略或外发了哪些路由。这正是本文的 Heng.lu 表面：注册机构是账本和记录者，不是运行网络的替代品。问责必须把资源身份、预期关系和真实运行状态核对在一起。

RIPEstat 对 8.8.8.0/24 的历史查询显示，在所查询日期内 AS15169 作为源具有可见性 [4]。但返回数据粒度为八小时，无法证明持续数十分钟的异常路径。本文不把它当作泄漏路径证据；路径事实来自 Cloudflare 的同期观察，事件类型来自 RFC 7908 的后续分类。

应当默认关闭的控制

第一，每条外部 BGP 会话都应有明确的导入和导出策略。缺失策略不应等同于接受或通告整张表。从对等方学到的路由，不应默认允许向提供商外发。

第二，配置必须由可审计的关系账本生成。账本应记录邻居 ASN、角色、授权前缀或源、路由数量限制、变更人、审批和例外到期时间。自动化不仅要下发策略，还要验证设备上的实际状态是否与批准记录一致。

第三，运营商应持续比较实际外发路由和预期集合。第三方源突然出现、路由数量激增、AS 路径违反会话角色，或社区属性与预期冲突，都应触发隔离。在边界清楚的情况下，系统应自动拒绝，而不是等待人工确认后再传播。

第四，关系可以被更明确地编码。事件发生多年后发布的 RFC 9234 定义了 BGP Roles 和 Only-to-Customer 属性，可帮助设备识别与角色不一致的传播 [3]。它们是今天的控制背景，不是 Moratel 或 PCCW 在 2012 年已部署这些机制的证据。

第五，独立路由观察不可缺少。外部收集器和其他网络可能先看到路由越界。该信号应与运营商自己的 Adj-RIB-In、本地决策和 Adj-RIB-Out 对齐，而不能替代内部证据。

可验证的公开结案

一份有用的结案应先给出 UTC 时间线：首次用户症状、首次内部告警、首次确认异常路由、运营商之间的联系、停止通告、外部观察到撤回，以及稳定恢复。观察时间和诊断时间不能混为一谈。

随后应说明失败的策略类别，而不必公开敏感配置：是否把对等方路由导出给转接，策略是缺失、陈旧还是被绕过，上游客户过滤为何覆盖过宽。对于内部触发不确定的部分，应明确保留不确定性。

最后，修复必须可测试。批准的关系意图、生成的策略、部署配置哈希、对等异常路由的负向测试、告警阈值、回滚责任人和外部撤回验证，共同构成持久修复证据。“服务恢复”结束紧急状态；“同一路径会被拒绝”才结束问责缺口。

来源

  1. https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/
  2. https://www.rfc-editor.org/rfc/rfc7908.txt
  3. https://www.rfc-editor.org/rfc/rfc9234.txt
  4. https://stat.ripe.net/data/routing-history/data.json?resource=8.8.8.0/24&starttime=2012-11-06T00:00:00&endtime=2012-11-07T00:00:00
  5. https://rdap.apnic.net/autnum/23947
  6. https://rdap.arin.net/registry/autnum/3491