摘要

  • 2017 年 8 月 25 日，日本互联网可达性异常的核心，不是单点云服务宕机，而是 BGP 出口、入口和继续导出控制同时进入同一条传播链：Google 错误导出了从对等方学习到的路由，Verizon 接受并向外传播，包含更具体前缀的路径在最长前缀匹配下吸引了流量。
  • 公开材料显示，Google 称配置错误在八分钟内得到更正，Internet Society 将泄漏持续时间描述为少于十分钟；但 NTT Communications 记录的 OCN 不稳定窗口为日本时间 12:22 至 12:45，KDDI 对部分互联网接入用户给出的恢复尾部则延伸至 16:47。问责分析必须把配置更正、路由撤回与收敛、接入网稳定、客户可感知恢复分开处理。

一场被边界限定的路由事件

2017 年 8 月 25 日的日本可达性异常，最容易被误写成“Google 导致日本互联网中断”。这种说法对问责没有帮助，因为它把需要审计的控制点压扁了。更精确的边界是：Google 在 BGP 中向 Verizon 广告了一大组原本从对等关系学习到的路由，Verizon 接受这些路由并继续向外传播，包含更具体前缀的公告改变了互联网上若干路径的吸引力，日本网络出现明显的可达性下降和客户侧不稳定。这个边界不包括 2018 年 MainOne 与 Google 相关的路由泄漏，不包括 2019 年 Google Cloud 控制面事件，也不包括 2021 年 Meta 的 BGP 事故；它只讨论 2017 年 8 月 25 日 Google 至 Verizon 的传播链及其在日本的可达性后果。

BGP 的危险之处在于，它把商业关系、技术策略和实时转发表压缩进同一套控制面。一个网络是否应该把某条路由发给另一个网络，通常取决于客户、对等、转接等关系边界；而一个路由器是否实际接受、选择和继续导出某条路由，则取决于运行中的策略和配置。2017 年这次事件的问责价值，正在于这两层之间的差异。即使号码资源登记记录仍然准确，即使某个前缀的合法持有人没有变化，只要运行中的路由策略接受了不该被当作转接路径传播的公告，数据包就会跟随当时被选中的路径，而不是跟随登记数据库里关于资源归属的静态事实。

因此，本文的核心问题不是“谁拥有这些前缀”，也不是“谁在法律上应当为所有日本用户负责”。核心问题是：在 Google 产生或导出异常路由、Verizon 接受并继续传播、下游网络看到更具体路径并改变选择、用户可达性被破坏这一链条中，各方是否有足够具体、可执行、可验证的出口过滤、入口过滤、最大前缀限制、路由监控、回滚授权和恢复证明。问责不应停留在道歉或后验描述，而应落在能够阻止、缩短或解释传播的控制面证据上。

时间线不能被压缩成一个“八分钟故障”

公开时间线至少有五只时钟。第一只是 Google 内部配置错误被发现和更正的时钟。日本媒体保存的 Google 说明称，相关配置错误在八分钟内得到修正。第二只是外部可见泄漏本身的时钟。Internet Society 的事件分析把泄漏持续时间描述为少于十分钟。第三只是 BGP 撤回和全网收敛的时钟：异常公告停止产生之后，已被接受、传播和安装的路径还需要被撤回、替代并在不同网络中完成收敛。第四只是日本运营商接入网络稳定的时钟。NTT Communications 的公告记录，因互联网上发生大规模路由变化，OCN 连接在日本时间 12:22 至 12:45 出现不稳定，同时其公告强调 OCN 设备本身没有异常。第五只是客户可感知恢复时钟。KDDI 的公告对部分互联网接入用户记录了更长的影响窗口，并给出至 16:47 的恢复尾部。

这五只时钟不能合并。把 Google 的八分钟配置更正说成“所有影响八分钟内结束”，会掩盖路由撤回、收敛和接入侧恢复。反过来，把 KDDI 对部分用户的更长恢复窗口说成“Google 持续泄漏到 16:47”，也会混淆控制面起因和客户侧恢复。更合理的说法是：发起错误和更正可能发生在一个短窗口内，公开路由泄漏在外部分析中被描述为少于十分钟，但日本运营商观察到的服务不稳定与客户恢复在不同网络中持续更久。这个分离对问责非常关键，因为预防控制、检测控制、撤回控制、客户沟通控制和恢复验证控制不属于同一责任点。

为什么公开前缀数量不同

这起事件的公开分析中，前缀数量并不总是一致。Internet Society 的叙述使用约 135,000 条路由或前缀的量级来描述 Google 泄漏的规模；Doug Madory 在 CircleID 的分析则讨论了超过 160,000 个 BGP 前缀的量级，并结合路径和日本可达性观察解释影响。不同数字并不必然互相矛盾，因为它们可能统计的是不同对象：某一观察点收到的公告、被 Google 错误导出的前缀、被 Verizon 继续传播到某些视角的路径、包含更具体拆分的路由、或对某些网络产生可达性影响的集合。

这也是为什么文章不能把 135,000、160,000 或其他报道数字合成一个“官方总数”。BGP 是从多个观察点看见的分布式状态。RouteViews、BGPStream 和其他公开监测系统能帮助还原参与采集点可见的公告和 AS 路径，但它们不是每个私有对等会话、每个拒绝动作、每台路由器本地 RIB/FIB 或每一条实际数据包路径的完整记录。一个采集器没有看到某条路由，不证明没有网络收到；一个采集器看到了某条路由，也不证明每个网络都安装了它，或每个应用都失败了。数量差异应被当作证据边界，而不是当作谁“夸大”或“缩小”事故的简单争论。

对问责而言，前缀数量的价值不在于形成一个漂亮的总数，而在于显示控制规模。几十万量级的异常路由公告穿过一个大型网络边界，说明只依赖人工变更信心和事后人工解释是不够的。出口策略应当知道哪些路由可以发给特定对等方，入口策略应当知道哪些路由不应从该关系接受，最大前缀限制应当在异常规模出现时给出硬阈值或强告警，路由监测应当在异常传播开始后迅速把责任人、会话和前缀集合绑定起来。

Google 的出口控制与八分钟更正

在公开链条中，最早的可审计控制点位于 Google。Internet Society 的分析称，Google 错误泄漏了从对等方学习到的前缀，使自身在行为上像是在为这些目的地提供转接，而不只是交换自身和客户相关流量。这个事实边界很重要：它不是说 Google 有恶意，也不是说 Google 有意劫持流量；它说的是运行中的出口策略让不应通过该关系导出的路由离开了 Google 的边界。

Google 后来对互联网路由安全的公开材料强调了 IRR、RPKI 验证、MANRS 承诺和路由安全改进。Google Interconnect 文档也说明了 BGP 过滤预期和对等侧安全要求。这些材料可以作为后续控制栈的比较，但不能被倒推成 2017 年当日的完整配置证明，也不能替代当时的变更记录。真正能回答 2017 年责任问题的材料，应当包括当日触发错误的配置或软件路径、变更审批记录、候选配置与路由表的预演结果、Google 向 Verizon 会话的出口策略、异常前缀报警、撤回动作、回滚授权和事后验证。

八分钟更正应被准确放置在这个控制面内。它说明 Google 声称配置错误在短时间内得到修正，也说明检测和回滚并非无限期失效。但八分钟不能证明出口策略在事前足够防护，也不能证明下游所有网络在八分钟内恢复。更严谨的评价是：快速更正降低了控制面错误的持续注入时间；然而，异常路由已经越过网络边界并被继续传播时，后续撤回、收敛和客户恢复需要另行证明。配置更正是责任链中的一段，不是完整关闭事故的证据。

Verizon 的入口、转接过滤与继续传播

公共分析把传播链的第二个关键控制点指向 Verizon。事件不是只有 Google 广告异常路由；要产生更广影响，另一个大型网络边界还必须接受并继续传播这些路由。公开材料描述 Google 将路由广告给 Verizon，Verizon 接受并向外传播。这个表述足以支撑入口和继续导出控制的问责分析，但不足以推断私人对等合同、内部 local preference、具体路由器命令，也不足以声称每一个 Verizon 对等方都接受了每一条路由。

Verizon 的控制问题是关系策略是否被机器执行。若一个网络从某个对等关系收到大量第三方目的地路由，并且这些路由在商业关系或技术关系上不应被当作转接可达性继续传播，那么入口过滤应当拒绝或至少隔离它们；如果入口没有挡住，继续导出策略也应当阻止把它们传播给更多邻居；如果策略无法直接判断，最大前缀阈值、异常 AS 路径检测、客户路由白名单、IRR 辅助过滤和路由监控应当迅速把会话置于风险状态。

RFC 7908 对路由泄漏的分类提供了有用语言：问题往往不是前缀所有权本身错误，而是路由在不符合关系意图的方向上被传播。RFC 7454 对运营过滤、最大前缀限制和会话安全给出实践建议。RFC 8212 后来强调 eBGP 默认要求显式导入和导出策略。RFC 9234 的 BGP Roles 和 Only-to-Customer 信号，则把关系意图进一步编码进协议行为。这些标准和机制有助于说明今天应如何构建控制栈，但不能作为 2017 年当日的追责捷径。正确的比较方式是：如果当时存在更严格的显式默认拒绝、关系感知过滤和异常前缀限制，传播窗口可能被缩短或阻断；但是否实际会阻断，仍取决于当时配置、会话关系、前缀集合和监测执行。

更具体前缀为何改变流量

这起事件之所以影响可达性，并不只是因为“很多路由被发错”。更关键的是，泄漏中包含去聚合的更具体前缀。BGP 与 IP 转发中的最长前缀匹配意味着，当网络同时看到一个较短前缀和一个覆盖其中地址空间的更具体前缀时，数据包通常会被送向更具体前缀指示的下一跳。这样，即使原始资源登记和较短前缀路径仍然存在，更具体公告也能在转发层面吸引流量。

这正是运行状态优先于静态登记的现实层。号码资源登记、ASN 信息和授权记录可以证明谁应当被视为资源持有人，可以形成审计账本，可以帮助构建过滤规则；但路由器最终按已接受、已选择、已安装的路由转发。如果 Google 并不是这些目的地的转接网络，流量被吸引到 Google 或经由 Google 相关路径后，就可能被丢弃、绕行或无法按原预期到达。Geekpage 的日本技术复盘将更具体路由和传播行为作为理解事故的重要部分；Doug Madory 的分析也把路径、前缀和日本影响联系起来。该技术机制不能在文章中被省略，因为一旦删掉更具体前缀和最长前缀匹配，事故就只剩下抽象的“配置错误”，无法解释为什么可达性会被大规模改变。

同样，不能把这种吸引流量直接称为“恶意劫持”。公开事实支持的是路由泄漏和关系策略失效，不支持主观恶意。BGP hijack、route leak、错误过滤和意外转接在效果上都可能让流量偏离正常路径，但它们的意图、控制点和改进措施并不相同。把事件称为恶意劫持会越过证据边界，也会让真正需要修复的出口、入口和传播控制被情绪化叙事替代。

日本运营商影响与客户恢复尾部

日本侧的证据应以运营商公告和当时报道为边界。NTT Communications 的公告称，互联网上发生的大规模路由变化导致 OCN 连接不稳定，并记录了 12:22 至 12:45 的窗口，同时说明 OCN 设备没有异常。这个表述对责任分析很有价值，因为它把影响指向外部路由状态变化，而不是把故障归因于 OCN 本地设备失效。日本媒体同日报道了相关通信障碍和 NTT 影响归因，为当时公众可见的时间线提供了背景。

KDDI 的公告则显示，部分互联网接入客户受到影响，并给出更长的恢复窗口，尾部至 16:47。这个时间不能被解释为 Google 一直在泄漏，也不能被忽略为“运营商自己的小问题”。它说明客户可感知恢复有自己的时钟，可能受到本地路由收敛、接入网络稳定、会话恢复、缓存、应用重试和客户设备状态等因素影响。KDDI 的公告没有列出所有服务、所有客户或所有损失；因此，只能说部分客户受到影响，不能写成日本全境、所有用户或所有业务完全中断。

BleepingComputer 和日本媒体报道提到更多日本公司、服务和用户感知问题。这些材料可用于说明事故在公众层面可见，但它们不能替代运营商级路由证据。严谨的写法应当分层：第一层是 BGP 传播和路径证据，说明异常路由如何进入可达性链条；第二层是运营商公告，说明特定网络在特定窗口内观察到不稳定；第三层是新闻报道和用户侧影响，说明事件的社会可见性。三层证据可以互相补强，但不能互相冒充。

撤回、收敛与恢复不是同一个动作

BGP 事件常被误判为“撤回即恢复”。事实上，异常路由停止被发出只是第一步。已经传播出去的路由需要被撤回，邻居需要接收更新，本地策略需要重新选择路径，转发表需要更新，依赖该路径的流量需要回到可达状态，应用层会话和客户体验还需要恢复。这些步骤中的任何一项都可能比原始配置更正更慢。

这次事件尤其适合说明这种差异。Google 的八分钟更正和 Internet Society 的少于十分钟泄漏描述，反映的是控制面错误注入的短窗口。NTT 的 12:22 至 12:45 反映的是 OCN 不稳定的运营窗口。KDDI 至 16:47 的窗口反映的是部分客户恢复尾部。若问责只盯着第一只时钟，就会错过下游网络的监测、沟通和恢复职责；若只盯着最后一只时钟，又会错把所有恢复尾部都归因于原始错误持续存在。正确的恢复报告应当列出：异常前缀生成停止时间、向邻居撤回时间、主要采集器不再观察到异常路径的时间、受影响运营商网络稳定时间、客户服务恢复时间，以及每一项证据来源。

这也是路由问责应当要求“恢复证据”的原因。说“问题已修复”不足够。需要证明哪些前缀被撤回，哪些邻居会话恢复正常，哪些采集器视角不再看到异常路径，哪些本地 RIB/FIB 恢复预期，哪些客户影响停止，哪些告警关闭，哪些补救配置已被持久化。没有这些证据，事后报告就容易把配置层面的修复当成服务层面的恢复。

登记记录与 RPKI 的作用边界

号码资源登记和 RPKI/ROA 在这起事件中很重要，但重要性不等于万能。登记记录说明 ASN、前缀和资源持有者之间的关系，是互联网号码资源问责的账本。ROA 对象表达某个前缀允许由哪个 AS 发起，可供 Route Origin Validation 使用。RFC 6811 定义的 ROV 能帮助识别与有效 ROA 冲突的起源；RFC 6482 则说明 ROA 的语义基础。这些机制对防止错误起源或未授权起源非常有价值。

但 2017 年这类路由泄漏的关键，不一定是起源 AS 被改成了非法起源。路由泄漏可以保留合法起源，却违反预期的关系传播范围。也就是说，前缀可以仍然属于正确持有人，起源也可能看起来合理，但路径中间的某个网络把它从不该转接的关系方向传播了出去。此时，仅靠 ROV 不能完整表达“这条路由是否应当从这个对等关系进入、是否应当向这些邻居导出”。因此，不能说 RPKI/ROV 单独就一定能阻止 2017 年事件。

这并不削弱登记和 RPKI 的价值。相反，它说明登记证据必须与运行策略结合。准确的 ASN、前缀、IRR、ROA 和联系信息，是构建过滤、报警和事后归责的输入；但它们需要被入口过滤、出口过滤、关系感知策略、最大前缀限制、路由监测和回滚流程执行。账本告诉你谁应被识别，运行代码决定流量如何走。网络问责必须同时审计两者：账本是否准确，运行策略是否按账本和关系意图执行。

路由采集器提供强证据，也有盲区

RouteViews 和 BGPStream 这样的公共路由数据系统，是重建这类事件的关键证据来源。它们能显示参与采集点观察到的公告、AS 路径、时间变化和撤回情况，使研究者能够把传播链从“某处出错”具体化为“某些前缀经由某些 AS 路径出现在某些视角中”。在这次事件中，公开分析正是借助这些数据和其他测量材料，描述 Google、Verizon、更多网络和日本影响之间的关系。

然而，采集器不是全知系统。它们无法看到每一条私有对等会话，无法知道某个网络拒绝了哪些路由，无法证明每台路由器的 local preference，无法给出内部配置命令，也无法直接显示所有数据包流向。它们通常记录控制面可见性，而不是完整业务损失。对问责来说，这个限制同样重要。采集器看到异常路径，足以触发对相关出口、入口和继续导出控制的审计；但要最终定责，还需要网络内部日志、变更记录、会话策略、报警记录、撤回时间和客户影响数据。

因此，本文不把公共路由证据说成完整真相，而把它当作可反驳、可补充的外部骨架。若未来出现当日配置记录、内部 RIB/FIB 快照或运营商遥测，证明传播链与公开观察有实质不同，结论应随之调整。可靠的网络问责不是坚持一份外部复盘永远正确，而是要求所有相关方把可验证证据放到同一条时间线上。

因果链：从出口错误到日本可达性

把上述证据合并后，较稳健的因果链是五步。第一，Google 创建或导出了异常路由公告，把从对等关系学习到的路由发给 Verizon。第二，Verizon 的入口和继续导出边界接受并传播了这些路由，使它们越过原本应被关系策略限制的范围。第三，泄漏中包含更具体前缀，在最长前缀匹配下吸引了本应走其他路径的流量。第四，Google 并不是这些目的地的转接网络，因此被吸引的流量可能被丢弃、错误转送或无法到达预期目的地。第五，随着配置更正、公告撤回和 BGP 收敛，路由状态逐步恢复，而日本运营商和客户侧体验在各自时间线上恢复。

这条链条的每一步都对应一个可审计控制。Google 的问题是出口控制、变更审查、异常路由生成检测和回滚。Verizon 的问题是入口过滤、关系策略、继续导出限制和最大前缀控制。下游网络的问题是路由监控、本地选择、异常流量识别、客户沟通和恢复验证。资源持有者的问题是登记和 ROA 等授权信息的准确性，但其能力不能扩展到阻止所有关系策略泄漏。测量组织的问题是公开数据的准确解释和盲区说明。终端用户没有控制跨域路由状态，不能因为依赖互联网而被分配预防责任。

这并不是说每一方承担相同责任。起因、传播、影响和恢复是不同责任层。Google 的短时间更正是重要缓解，但不能消除出口错误。Verizon 的继续传播是传播放大的关键，但公开材料不足以证明每一条路由、每一位客户或每个邻居的具体接受状态。日本运营商的公告提供影响证据，但不证明它们控制了上游泄漏。问责的目标应当是把责任映射到可控动作，而不是把事故归结为单一品牌或单一协议缺陷。