摘要

  • 2021 年 10 月的中断发生在一次反 DDoS 维护期间，但 DDoS 活动只是推动维护的背景，现有事实并未把攻击本身认定为停机原因。
  • OVHcloud 表示，一条涉及 BGP 向 OSPF 重分发的命令使完整互联网路由表进入 IGP，填满 OSPF 表并使路由器内存和处理器过载，最终导致 IPv4 路由不可用，而 IPv6 仍保持可达。
  • 这次变更已经经过 CAB、MOP 和同级复核，因此问责重点不是声称“无人审核”，而是检验语义验证、影响半径限制、运行状态观测与回退能力是否真正有效。
  • 恢复过程包含不同里程碑：配置问题约在 09:20 CET 出现，故障路由器于 10:18 关闭，首批服务在 10:20 恢复，技术危机到 10:57 才宣告结束。
  • 证据支持一次影响广泛的 IPv4 可达性故障，却不能证明精确的客户或服务数量、数据丢失、火灾、设施损毁、完整财务损失，或把“复制粘贴”当作已经坐实的根因。

安全动机不能替代故障原因

OVHcloud 在 2021 年 10 月 13 日实施的是一次计划内生产网络变更。公司称，当时 DDoS 攻击强度有所上升，维护目的在于加强防护。这个背景解释了为何要改变网络，却没有把攻击流量放进停机的直接因果链。现有描述从配置变更开始，经由路由重分发和控制面资源耗尽，最后以物理隔离设备结束。

区分“为什么要维护”和“什么造成停机”，是准确问责的第一步。如果把安全维护期间发生的故障统称为网络攻击，责任就会被推向一个并未被认定为直接原因的外部对手。如果只用“人为失误”概括，又会把系统性防线失效压缩成对个人动作的猜测。公开信息没有给出具体工程师、精确命令或每个决策人的认知状态，无法支持个人归责。

更有用的问题是：在安全压力存在时，组织有没有明确变更可产生的最大路由暴露；有没有让错误状态在进入核心路由域前被拒绝；有没有在客户受影响之前发现实际状态偏离；有没有一条不依赖故障设备健康状况的恢复路径。安全紧迫性可以决定何时行动，却不能取消这些连续性条件。

这也是为何此次事件不是一则泛化的云服务宕机故事。删除 BGP 到 OSPF 的机制后，问责命题就失去了技术支点。故障发生在路由控制边界，服务影响来自可达性丧失，恢复则依赖把造成错误收敛的设备从网络中移除。路由状态的准确性与运营连续性处在事件中心。

BGP 与 OSPF 的边界放大了命令后果

BGP 与 OSPF 服务于不同范围。BGP 处理自治系统之间的可达信息，可以承载规模庞大的互联网前缀集合；OSPF 则在一个路由域内计算路径。把 BGP 路由重分发给 OSPF，不只是改变一种配置表达，而是让一类信息进入容量、传播和收敛假设不同的控制面。

OVHcloud 的说明把问题定位在这条边界上。一台路由器没有正确解释相关命令，完整互联网路由表随后被通告进入 IGP。OSPF 表被填满，路由器 RAM 与 CPU 过载，BGP 与 OSPF 之间又形成收敛循环，最终使 IPv4 路由无法正常工作。

这条链路把“命令有问题”转化为可以验证的网络状态：进入 OSPF 的前缀数量异常，链路状态数据库膨胀，资源使用率上升，路由收敛反复发生，IPv4 端到端探测失败。真正需要防守的不是一行文本，而是这行文本可能生成并传播的路由集合。

因此，审核命令语法并不足够。变更前需要定义允许通过的前缀、数量上限、属性变化、目标路由域和拒绝条件；变更中需要把实测结果与这份边界持续比较；偏差发生时，需要由独立限制自动阻止继续扩散。若所有保护都存在于正在被修改的同一台设备上，那么设备一旦过载，保护和恢复能力可能同时消失。

公开材料没有说明设备型号、厂商、软件版本、精确命令、解析器行为或完整拓扑，也没有给出实际进入 IGP 的精确路由数量。因此，不能把事件归结为某家厂商的具体缺陷。能够确定的是，重分发边界没有把一次错误解释的后果限制在可承受范围内。

IPv4 失效而 IPv6 可达，揭示了“部分可用”的陷阱

此次事故一个关键事实是 IPv4 与 IPv6 的表现不同。IPv4 路由变得不可用，IPv6 却仍能到达。这意味着“整个网络完全消失”并不准确；但对主要依赖 IPv4 的客户而言，业务体验确实是大面积不可达。可用性既不是一个简单的全有或全无状态，也不能由单一探针代表。

如果监测只通过 IPv6 访问一个端点，系统可能显示绿色，却漏掉多数客户正在经历的 IPv4 故障。如果监测点位于服务商自己的网络里，也可能看不到外部路径已经断裂。反过来，IPv4 无法到达并不证明服务器、存储或数据已经损毁。资产仍可能正常运行，只是路由层无法把流量送达。

独立报道观察到 OVHcloud 的服务器和客户网站不可访问，公司自己的公开网站出现错误，状态页也无法使用。法国媒体还列举了受影响的公共与商业网站，并报道有数千个站点受到波及。这些观察足以说明依赖范围广，却不是完整审计清单，不能据此声称一个精确客户数、服务数或国家数。

同样不能把这次路由事件与 2021 年 3 月斯特拉斯堡数据中心火灾混为一谈。10 月事故的事实不支持火灾、机房物理毁坏或客户数据丢失。它的已知影响机制是路由可达性失效。借用另一场事故的损毁图景，会让技术归因从控制面故障滑向没有证据的物理灾害。

从 09:20 到 10:57，恢复并非一个时间点

详细时间线显示，计划变更于 09:05 CET 启动。09:18，团队进行了 BGP 隔离和配置操作。09:20 出现网络配置问题，09:21 发现路由器性能异常并上报。检测发生得很快，但检测本身没有立即阻断错误状态。

到 09:30，软件回退已经失败，团队选择物理隔离。这十分钟揭示了恢复设计的薄弱处。控制面资源被大量路由占用时，设备可能没有足够能力处理撤回、重新计算和新的管理命令。原本用于恢复的路径与故障设备共享资源，因而在最需要它的时候变得不可靠。

故障路由器于 10:18 被关闭。10:20，网络收敛后首批服务恢复。OVHcloud 到 10:57 才把技术危机标记为结束。关闭设备、首批服务回归和技术稳定是三种不同状态。把它们合并成单一“停机时长”，会掩盖恢复分阶段发生的事实。

当天较早的一次运营更新使用了更粗略的时间，例如 09:12 开始干预、10:15 完成隔离。事后详细报告提供了更适合分析的精确时间线。危机期间的初步时间与事后重建存在差异并不罕见，但引用时必须知道自己使用的是哪一组数据，不能拼接成看似精确却来源混杂的叙述。

恢复里程碑也应从客户视角验证。设备被移除不等于所有路径都稳定，首个服务返回不等于所有依赖都恢复。路由邻接、表规模、资源压力、IPv4 外部探测、状态通信与代表性客户服务应分别达到退出条件，技术危机才有充分依据结束。

CAB、MOP 与同级复核真实存在

OVHcloud 表示，变更已经走过变更咨询委员会、操作方法和同级复核。因而，说这次操作“未经审核”会直接违背已知事实。更值得追问的是，这些控制在变更前究竟证明了什么，以及哪些运行结果仍没有被约束。

CAB 可以确认目标、窗口、参与方与风险说明；MOP 可以排列操作步骤和回退动作；同级复核可以发现明显错误。这些做法都很有价值，但它们不会自动证明路由器将以预期方式解释命令，也不会保证重分发数量受到硬限制，更不会保证设备过载时仍能执行回退。

文档控制与运行证据并非二选一。理想做法是把二者相连：方案列出允许路由集合与最大变化，仿真验证命令效果，生产系统提供实时差异，独立策略执行上限，明确触发器赋予人员停止权。这样，批准的是一段可观测、可中止的状态迁移，而不是一组只能依赖信任的操作文字。

此次事故体现了“运行状态优先”的现实。组织层面已经完成审核，但网络真正接收的是完整互联网路由表。流程记录可以证明意图和责任分工，却不能让一个超出边界的路由集合变得安全。连续性最终取决于设备实际安装、传播和收敛的内容。

回退必须在资源受压时仍然可用

“回退”可以指输入反向命令、恢复旧配置、撤销路由会话、切断重分发关系，或物理关闭设备。这些动作的依赖、速度和影响都不同。在正常实验环境里可行的反向命令，到了 CPU 与内存过载的设备上可能无法及时执行。

OVHcloud 的软件回退没有成功，工程师最后物理隔离并关机。这个结果没有解释软件回退失败的全部原因，却证明了独立操作路径的重要性。若管理流量、控制命令和故障传播共用同一网络，操作员可能在最需要干预时失去接触设备的能力。

一个可信恢复方案需要预先规定升级路径。例如，路由数量在限定时间内不下降时停止继续尝试；主管理面失效时转向带外访问；设备无法处理撤回时隔离邻接或切断电源；每一步都由具名角色授权。若必须等到完全确定根因才允许隔离，错误状态可能已经扩散到更难逆转的程度。

演练还必须包含困难条件：注入受控但过量的路由，让资源接近上限，削弱主管理路径，并要求团队在继续回退和物理隔离之间做决定。只验证一条正确命令在空闲设备上执行，无法证明事故条件下的恢复能力。

状态页也落在同一个影响半径里

报道显示，OVHcloud 的公开网站和状态页在事件中也无法正常访问。这不仅是通信问题，也是架构问题。服务故障时，客户需要可靠信息判断是否切流、等待或启用自己的应急方案；如果状态渠道共享同一条故障路由，它会在需求最高时一起消失。

独立状态渠道应在 DNS、托管、分发网络、管理登录和发布机制上与主要故障域分离。把页面复制到同一网络中的另一台服务器，可能增加设备冗余，却没有消除控制面共同依赖。相同原则也适用于带外管理和外部监测：名义上的第二条路径，只有不依赖失效组件时才真正独立。

通信内容应区分“错误状态已隔离”“首批服务恢复”“网络稳定”和“事件结束”。还应分别说明 IPv4 与 IPv6。这样的透明度不会淡化故障，反而能让客户基于真实边界作出决定，并减少第一丝恢复迹象被误解为全面正常。

公开事实没有解决的几项问题

外界不知道精确命令、路由数量、设备数量、厂商与版本，也不知道所有决策日志。资料没有把责任落到某名工程师，也没有证明某个人在某分钟已经掌握哪些信息。因此，公平的分析不能虚构个人过错或特定厂商缺陷。

部分报道提到一则后来删除的管理层信息，并提出复制粘贴错误的说法。后来的详细事故说明没有把这一理论确认为最终根因。可以确定的是命令解释、BGP 到 OSPF 重分发、完整互联网表进入 IGP、控制面过载和 IPv4 失效；更具体的输入方式只能保持为未经证实的推测。

影响规模也没有一个权威总数。许多网站不可访问是有观察支持的，但精确客户、服务、地域和经济损失并未公布。也没有数据丢失、服务器毁坏、火灾或设施故障的证据。没有总数不意味着没有严重影响，只意味着不能把媒体例子相加后包装成完整损失。

这些限制反而让结论更清晰：一次经过正式控制的计划变更仍然产生了超出边界的路由状态，耗尽控制面资源，抵抗软件回退，并要求物理隔离。问责不应停在“完善检查表”，而应要求展示路由语义验证、传播硬限制、独立访问、停止权和基于服务的恢复证据。现有资料没有证明这些改进今天是否持续有效。

来源