OVHcloud 2021 年骨干网中断：BGP 到 OSPF 的隔离为何是一场问责考验

摘要

OVHcloud 表示，2021 年 10 月 13 日 09:05 UTC，网络团队开始修改位于弗吉尼亚州 Vint Hill 的一台路由器，目的是增强网络抵御分布式拒绝服务攻击的能力。
09:18，团队将该路由器从 BGP 中隔离并更新配置；09:20，OVHcloud 称一个涉及 BGP 到 OSPF 重分发的命令解释问题，使完整互联网路由表进入 OSPF。
公司报告称，随后的 OSPF 不稳定给骨干路由器的 CPU 和内存带来压力，造成全球 IPv4 影响，而 IPv6 仍可访问。
远程回滚没有成功。现场人员最终通过物理断开并关闭 Vint Hill 路由器来建立有效隔离边界，骨干网随后分阶段重新收敛。
广泛恢复被报告于 10:57 UTC 完成，但真正的恢复验收不能只依据配置成功或告警消失，还必须核对预期策略、实际安装路由和外部 IPv4、IPv6 可达性。
这不是一次 DDoS 攻击、网络攻击、BGP 劫持或典型的域间路由泄漏，而是运营商在自身骨干网变更过程中发生的内部协议边界失控。
问责重点不应停留在谁输入了哪条命令，而应落在系统是否能够在激活前限制可重分发路由的集合、数量、方向和传播范围，并在状态越界时自动停止。
远程回滚失效表明，独立路由的带外管理、控制台访问、电源控制以及经过演练的物理隔离程序，本身就是骨干网问责体系的一部分。

一起边界明确的骨干网事件

这起事件必须被准确限定在 2021 年 10 月 13 日 OVHcloud 的全球 IPv4 网络事故。它不应与同年 3 月斯特拉斯堡数据中心火灾、客户遭遇的 DDoS、此后发生的其他 OVHcloud 服务中断或无关路由事件混合讨论。

OVHcloud 的公开说明把事故起点放在一次由其网络团队实施的骨干网变更上。工作地点是美国弗吉尼亚州 Vint Hill，目标是增强网络对分布式拒绝服务攻击的抵抗能力。这个目标解释了为什么团队正在更改路由配置，却不意味着当时网络正遭受 DDoS。公开记录也没有表明攻击者进入路由器、篡改配置或控制路由状态。

因此，将事故称为“网络攻击”会改变因果边界；称为“BGP 劫持”会暗示未经授权的路由起源或路径操纵；称为典型“路由泄漏”则容易让人以为错误路由在自治系统之间沿 BGP 传播。OVHcloud 描述的核心机制不同：互联网规模的 BGP 路由状态被引入内部 OSPF 域。它首先是一次运营商内部的路由重分发和变更控制失败。

这种区分并非措辞上的谨慎而已。事故类型决定需要检查什么证据。若是攻击，重点会包括入侵路径、身份凭证和恶意控制；若是域间泄漏，重点会包括错误通告的前缀、自治系统路径和外部传播；而在本案中，首要问题是内部协议域之间的边界为何允许一个配置变化把不受控制的路由集合注入 OSPF，以及为什么远程恢复路径无法及时撤销该状态。

从 09:05 到 10:57 UTC 的公开时间线

OVHcloud 表示，维护工作于 2021 年 10 月 13 日 09:05 UTC 开始。其陈述的目的，是加强网络抵御 DDoS 的能力。公开资料没有披露变更的完整审批记录、候选配置、设备厂商、软件版本或全部命令，因此不能从维护目标反推出具体实现。

09:18，团队将 Vint Hill 路由器从 BGP 中隔离，并更新其配置。这一步值得精确理解。“从 BGP 中隔离”并不等同于关闭设备，也不保证路由器与 OSPF、管理平面或其他内部邻接关系同时断开。公开时间线告诉我们操作顺序，却不足以重建该路由器当时的全部会话、接口、路由策略和拓扑角色。

09:20，OVHcloud 称，一个涉及 BGP 路由向 OSPF 重分发的命令解释问题，导致完整互联网路由表进入 OSPF。此处最可靠的事实边界，是公司报告了命令解释问题、重分发方向以及进入 OSPF 的路由集合规模性质。公开资料没有给出确切路由条目数、命令语法、路由器品牌、外部路由的具体类型或生成的链路状态通告数量。

随后，OVHcloud 报告 OSPF 出现不稳定，骨干路由器受到 CPU 与内存压力影响。全球 IPv4 连通性遭受冲击，而 IPv6 仍可访问。公开记录支持把资源压力与异常路由状态联系起来，但并不足以为每一台设备确定完全相同的失效过程。某些路由器可能承受了状态处理、泛洪、最短路径计算、路由安装或反复收敛中的一种或多种压力；若没有设备遥测与日志，就不应把其中任何一个 plausible mechanism 写成已证实的唯一机制。

团队尝试远程回滚，但没有成功。最终，人员在现场物理断开并关闭 Vint Hill 路由器。此后，网络通过分阶段重新收敛恢复，OVHcloud 报告广泛服务于 10:57 UTC 恢复。这里的关键不是“断电比软件更可靠”这样过度宽泛的结论，而是：当被修改的路由状态同时破坏了远程控制路径时，物理隔离成为能够独立于故障控制面的恢复手段。

时间线表明，从异常状态被引入到广泛恢复之间，问题并非单一设备重启即可描述。异常路由需要停止传播，受影响设备需要释放或替换错误状态，邻接关系与路由计算需要稳定，路由信息库和转发表需要重新形成，外部数据包转发也必须恢复。恢复是一个分阶段的状态重建过程，而不是一条配置命令返回成功的瞬间。

BGP 与 OSPF：两个不同的控制域

BGP 与 OSPF 都处理网络可达性，但它们不是可以随意互换的两种路由格式。

BGP 用于在自治系统之间交换可达性信息，也可在大型网络内部承载外部路由及相关策略。它的设计强调路径属性、策略选择、路由传播控制以及对互联网规模前缀集合的处理。运营商可以根据前缀、自治系统路径、团体属性和其他政策信息决定接受、拒绝、优先或输出哪些路由。

OSPF 是内部网关协议。它通过链路状态信息让同一管理域中的路由器形成拓扑视图，并据此计算内部路径。OSPF 也能表达外部路由，但这并不意味着它应无条件承载完整互联网路由表。外部状态一旦进入 OSPF，可能参与一个具有不同泛洪、数据库同步、计算和收敛假设的控制域。

两者之间不存在“既然都是路由，所以复制过去也无妨”的安全默认值。BGP 中的一条路由在语法上有效，不代表它适合进入 OSPF；单条路由可被正确编码，也不代表数以互联网规模计的同类状态可以安全进入内部链路状态域。安全性取决于集合而非单条记录，取决于传播范围而非命令是否被设备接受，也取决于接收设备群体的资源和收敛能力。

RFC 4271 描述 BGP 的基本行为；RFC 2328 描述 OSPFv2，包括外部路由机制；RFC 5340 则规定 OSPFv3。RFC 1745 更直接地把 BGP 信息导入 OSPF视为需要策略控制的行为。这些标准能够解释协议边界，却不能证明 OVHcloud 私有网络在 2021 年采用了哪一种具体拓扑、过滤器或实现。

路由重分发是一种高权限状态转换

“重分发”一词容易被当作路由器上的普通功能。更准确的理解是：它授权一个协议域中的状态进入另一个协议域，并在新域中获得传播和影响能力。这是一种高权限状态转换。

任何此类转换在激活前，至少应回答四个问题。

第一，哪些路由有资格进入？资格条件不应只是“出现在 BGP 中”。它可以受到地址族、前缀集合、来源、标签、路由属性、用途或明确白名单约束。默认允许全部候选、再期待人工发现异常，会把边界控制变成事后观察。

第二，最多允许多少路由进入？路由数量必须成为可执行的不变量，而不只是容量规划文档中的估计。若预期只有少量基础设施前缀，系统不应允许数量突然扩张到互联网规模。超过阈值时，安全动作应是拒绝激活、停止重分发或撤回候选变更，而不是继续注入后等待 CPU 告警。

第三，方向是否明确？从 OSPF 到 BGP 与从 BGP 到 OSPF 是不同的风险面；IPv4 与 IPv6 也应分别约束。配置和验收证据必须明确指出方向、地址族以及允许通过边界的对象，不能只记录一个含义宽泛的“启用重分发”。

第四，传播范围有多大？即使候选路由集合被错误扩大，事故能否被限制在一台金丝雀设备、一个非转发环境、一个 OSPF 区域或一个可迅速撤销的设备组中，决定了错误会成为局部异常还是骨干网事件。一次配置若从首台设备直接作用于全球关键路径，就把验证窗口压缩到了真实用户流量之中。

因此，批准意图不等于安全状态。变更单可以准确描述目标，操作者可以按步骤执行，设备也可以返回配置成功，但运行中的路由状态仍可能违背意图。问责必须一直延伸到实际运行结果。

命令成功不能证明网络安全

路由设备接受一条命令，最多证明该命令符合当时的软件解析和配置规则。它不证明操作者与设备对命令的理解一致，也不证明生成的配置只匹配预期路由，更不证明新的控制面状态能在资源边界内稳定运行。

可靠证据链应从批准的变更意图开始，但不能在那里结束。批准记录应说明要改变什么、为什么改变、预期影响哪些协议和地址族、可接受的路由数量是多少，以及什么条件要求停止。

下一层证据是渲染后的设备配置。集中式配置模板、自动化变量和设备最终接收的文本之间可能存在差异。必须检查最终渲染结果，而不是只检查模板。若设备支持候选配置、提交确认或差异预览，这些能力可以降低风险，但同样不能替代实时状态验证。

再下一层是设备确认与实际协议状态。系统需要观察 BGP 会话、接收和选出的路由、OSPF 邻接关系、链路状态数据库、外部路由数量以及状态变化速率。预期只有有限路由跨越协议边界时，OSPF 外部状态的异常增长本身就应触发中止。

随后还要查看路由信息库和转发信息库。RIB 表明控制面选中了哪些路由；FIB 表明哪些转发项实际进入数据面。两者可能在收敛期间暂时不一致，也可能因资源限制、编程延迟或下一跳解析问题产生差异。只观察协议邻接“已建立”，无法证明数据包正在走预期路径。

最后需要外部可达性证据。来自独立网络位置的 IPv4 与 IPv6 探测，应验证路由通告、路径和实际服务访问。内部仪表盘显示绿色，并不能自动证明全球用户已经恢复；外部探测成功也不能独自证明内部策略已经回到预期状态。两类证据必须相互印证。

状态数量为何会改变故障性质

路由系统的危险不只来自错误内容，也来自状态基数。十条错误路由和完整互联网路由表虽然都可能被称作“错误重分发”，但它们对链路状态数据库、路由计算、内存、CPU、消息队列和转发表安装的压力完全不同。

当大量外部路由进入 OSPF 时，路由器可能需要生成、接收、存储和处理大量外部状态。相关信息还可能在协议定义的范围内传播，使其他路由器同步更新链路状态数据库。状态变化若持续发生，设备可能反复计算或处理更新，控制面资源进一步被占用。

这是一种可能的技术解释框架，而不是对 OVHcloud 每台设备行为的重建。公开资料确认了完整互联网表进入 OSPF、OSPF 不稳定以及 CPU 和内存压力，但没有提供精确的 LSA 类型、数量、每台设备的处理队列、计算次数或内存分配情况。没有这些资料，就不能断言某个单一内部过程是全部影响的直接原因。

不过，公共证据足以支持一项更稳健的结论：数量限制必须在状态进入目标协议域之前执行。等到 CPU 或内存超过阈值才处理，意味着异常状态可能已经传播。更安全的设计会同时设置资格过滤、最大条目数、变化速率限制和自动撤回条件，让不同控制层相互补强。

数量限制还需要与预期基线结合。如果某项合法功能通常只重分发几十个基础设施前缀，那么阈值就应围绕该用途设置，而不是靠近设备理论容量。设备“最多可以装下多少路由”与“本次策略允许多少路由跨界”是两个问题；前者属于容量，后者属于授权。

泛洪、收敛与资源压力

OSPF 的链路状态方法依赖域内路由器对相关状态形成一致认识。新的外部路由状态需要传播和处理。当状态数量或变化速度突然超出设计预期时，问题可能沿多个方向放大：链路状态数据库增长、邻接同步耗时增加、控制消息竞争资源、路由计算或外部路由处理负担上升、RIB 更新积压，以及 FIB 编程延迟。

BGP 与 OSPF 对状态的组织和传播方式不同，所以协议边界上的错误不是简单的数据复制。BGP 路由可能携带丰富的路径与策略属性；当其被转换为 OSPF 可表达的外部路由时，部分上下文会发生变化。目标域接收到的是能够在内部传播的新状态，而不是原 BGP 政策的完整等价物。

这正是重分发需要谨慎的另一个原因：信息转换不仅增加状态，还可能丢失原协议中用于决策或追踪的语义。运营商必须提前定义哪些属性被保留、哪些被映射、如何标记来源、如何防止路由反馈，以及怎样确认进入目标域的路由仍符合政策。

本案不应被描述为已经证实存在路由反馈、特定 LSA 风暴或某种厂商缺陷。公开记录没有提供这些细节。合理的分析方式，是列出与已知现象相符的机制类别，再明确指出要区分它们需要哪些日志、计数器和状态快照。

IPv4 全球影响与 IPv6 持续可访问

OVHcloud 报告全球 IPv4 受到影响，同时 IPv6 仍可访问。这是事故中最有价值的边界证据之一，因为它说明故障没有以完全相同的方式吞没所有地址族。

IPv6 连通性的保留，可以说明至少某些路由、转发或服务依赖没有与受影响的 IPv4 路径完全同命运。它可能反映控制面、策略、会话、路由表、设备角色或服务入口中的部分分离。它也为运营商和客户提供了一个重要观察点：在 IPv4 受损时，IPv6 是否仍能承担管理、诊断或服务访问功能。

但“IPv6 仍可访问”不能直接证明完整架构独立。两个地址族仍可能共享机框、线路、电源、控制处理器、配置系统、管理网络、监控平台和人员流程。若共享组件失败，部分分离可能不足以保护另一个地址族。反过来，即使共同运行在同一设备上，不同协议实例、策略与路由状态也可能形成有意义的故障隔离。

可信的事故分析需要进一步问：IPv4 和 IPv6 的 BGP 会话是否分开？内部路由是否使用不同协议实例或不同策略？管理平面依赖哪个地址族？监控探针是否能够在一个地址族失效时继续报告另一个？关键服务是否真正监听并可通过 IPv6 到达？这些问题不能由公开资料全部回答，但它们定义了应当提供的证据。

因此，IPv6 连续可访问是“部分分离”的证据，不是“完全独立”的证明。成熟的问责表述既不忽略它对限制影响范围的意义，也不把它夸大成整体冗余设计已经通过验证。

远程回滚为什么是问责边界

变更管理经常把“可回滚”写成一个是或否的属性。但在网络基础设施中，回滚的存在不等于回滚可达，更不等于回滚独立。

若操作员必须通过正在修改的同一网络到达设备，那么控制面不稳定可能同时切断修复路径。即使回滚命令已经准备好，管理会话也可能无法建立，设备可能忙于处理异常状态，或者远程连接在配置恢复完成前再次中断。公开资料没有说明 OVHcloud 远程回滚失败的具体技术原因，因此不能把其中任何一种可能性写成既定事实。

可以确认的是，远程回滚没有奏效，而物理断开和关机成为有效隔离手段。这使恢复架构成为问责问题：运营商在授权高风险变更之前，是否证明自己拥有不依赖被修改平面的控制路径？

独立恢复路径可以包括具有独立路由的带外管理网络、串行控制台、远程电源控制、现场人员访问以及预先定义的物理隔离步骤。这里的“独立”不能只靠逻辑名称判断。如果所谓带外网络共享同一故障路由域、同一设备、同一电源或同一上游路径，它在关键时刻可能仍然与主网络共同失效。

控制台和电源能力也需要在维护前验证。凭证是否有效、跳板路径是否可达、设备是否能从管理网络访问、远程电源控制是否对应正确设备、现场联系人是否明确、隔离后会影响哪些邻接和流量，这些都应有可审计记录。没有演练的紧急方案，只是书面可能性。

物理隔离不是失败后的尴尬附注，而是证明恢复能力的最后边界。它应当经过设计、记录和演练，同时尽量避免让现场人员在缺乏准确设备身份和影响信息的情况下临时判断。

金丝雀、候选配置与自动中止

高风险路由变更需要缩小第一步的影响范围。金丝雀发布的意义，不只是先挑一台设备执行，而是让首个执行单元具备代表性、可观察性和可撤销性。

合适的金丝雀需要明确流量角色、协议邻接、路由规模和故障隔离边界。若首台设备承担全局关键职能，或其状态变化会立即向整个骨干传播，它就不是安全的有限试验。金丝雀阶段必须保留足够时间观察路由数量、状态变化、邻接稳定性、CPU、内存和外部可达性，不能只等待配置命令返回。

候选配置应在激活前生成可读差异，展示最终设备语义。验证不应只查配置文本是否包含预期语句，还应计算其匹配集合：哪些 BGP 路由会符合条件、可能产生多少 OSPF 外部路由、将向哪些邻接和区域传播，以及是否存在返回原协议域的反馈路径。

自动中止条件要在变更前定义，而不是事故发生时临时决定。例如，OSPF 外部路由数量超过预期上限、LSDB 增长率异常、邻接抖动、CPU 或内存超出安全范围、RIB 与 FIB 差异扩大、IPv4 或 IPv6 外部探测失败，都可以成为停止或撤回信号。

阈值需要结合设备和角色设定，不能从本案公开资料推导出一个通用数字。重要的是让系统在越界时倾向于保持原状态或撤销候选状态，而不是继续扩散后等待人工确认。

RFC 3137 与 RFC 6987 描述 OSPF stub-router 机制，可用于降低维护期间设备作为转发路径的吸引力；RFC 5880 描述 BFD，可提供快速故障检测。它们属于可考虑的控制词汇，却不能证明 OVHcloud 当时部署了这些机制，也不能证明任何一种机制单独足以阻止本次事件。路由器即使不承载普通转发，也仍可能传播错误控制面状态；快速检测到故障，也不等同于阻止错误路由被创建。

从 RIB 到 FIB：必须观察真实运行状态

网络变更的核心证据不是操作员想让设备做什么，而是设备实际做了什么。

在 BGP 侧，应记录邻居状态、接收路由数量、策略前后的合格集合、选中路径、输出通告数量以及地址族差异。重分发开启前，系统应能计算预期输入集合，并将实际结果与其比较。

在 OSPF 侧，应观察邻接关系、链路状态数据库规模、外部路由数量、状态更新速率和区域传播范围。若目标是导入一个小型明确集合，外部状态数量就应保持在狭窄范围。完整互联网表级别的增长不应等到网络整体不稳定后才被识别。

RIB 提供设备已经选择的控制面结果。它能回答路由是否被安装为候选、下一跳是否解析、管理距离或偏好如何影响选择等问题。FIB 则接近实际转发行为，能够显示转发硬件或软件最终编程的条目。两者都需要核对，因为配置正确、协议正常和转发正常不是同一个状态。

CPU 与内存遥测必须与路由事件关联，而不能只看事后平均值。需要保留变更前基线、变更期间峰值、增长速率、进程或功能维度的消耗，以及恢复后的回落情况。时间戳一致性十分重要，否则难以判断资源压力是异常路由的结果、并发因素还是恢复过程的一部分。

还需要外部路由观察。外部网络能够看到哪些前缀仍被通告、路径是否变化、IPv4 与 IPv6 是否分别可达。外部观测不能揭示全部内部状态，但能防止运营商仅凭内部控制面恢复就过早宣布用户路径正常。

恢复不等于配置回到原样

恢复至少包含三层一致性。

第一层是意图：变更后的正式策略究竟是什么？发生事故后，是完全恢复旧策略，还是采用了一个临时安全策略？哪一版本被批准为当前状态？如果这层不清晰，后续设备状态就缺少比较基准。

第二层是安装状态：BGP、OSPF、LSDB、RIB 与 FIB 是否与该策略一致？异常外部路由是否已从所有相关节点撤除？邻接是否稳定？CPU 和内存是否回到安全区间？只检查事故路由器本身不够，因为错误状态可能已经进入其他设备。

第三层是外部结果：来自不同网络和地区的 IPv4、IPv6 探测是否恢复？路由通告和服务访问是否正常？客户仍见到的异常是控制面残留、缓存、应用恢复延迟，还是与本次事件无关？

只有预期策略、安装路由状态与外部可达性三者一致，恢复才适合关闭。三者中的任何两个都不足够。策略和设备状态一致但外部不可达，说明数据面或依赖仍有问题；设备状态与外部探测暂时正常但策略记录不清，会为下一次变更留下配置漂移；策略和外部结果看似正常但内部仍残留异常状态，则可能隐藏新的收敛风险。

广泛恢复时间同样不应被误读为每位客户、每个前缀和每项服务在同一秒恢复。OVHcloud 报告 10:57 UTC 广泛恢复，这可以作为事件级时间点，但不能据此推断所有客户影响持续时间或损失。

面向客户的证据责任

全球云骨干网承载的不只是运营商自己的管理流量。客户可能通过它访问计算、存储、托管、连接和网络服务。因此，事故沟通需要让客户理解哪些依赖受到影响，而不泄露会增加安全风险的敏感拓扑细节。

最低限度的公开说明应准确描述事件类型、开始与恢复时间、受影响地址族、主要控制面机制、恢复手段以及仍然未知的范围。OVHcloud 公布了变更地点、时间线、BGP 到 OSPF 的相互作用、远程回滚失败、物理隔离以及 IPv4 与 IPv6 的区别，这些信息构成了有意义的事实基础。

但客户还需要能够把运营商说明与自己的证据对齐。企业应保留外部探测、路由监控、连接日志、服务错误率和地址族分别统计的数据。仅凭运营商状态页，客户无法确定自己的每条依赖何时失效或恢复；仅凭应用报错，客户也不一定能区分网络不可达、DNS、身份系统或应用本身的问题。

客户损失不能从全球事故的存在自动推导。公开资料没有列出客户身份、逐项损失或经过验证的经济影响。分析应要求可核验的客户级证据，而不是把可能的业务中断写成已确认金额。

运营商的问责也不等于预先断定疏忽、违法或法律责任。公开材料不足以判断决策归属、人员配置、内部批准链、监管结论或法律标准是否满足。网络问责在这里指向可验证的控制和证据：谁有权限触发何种状态转换，系统如何限制它，越界如何被检测，恢复路径是否独立，以及事故后是否能证明网络回到了预期状态。

一份面向骨干变更的问责清单

在执行涉及协议边界的变更前，运营商应能给出以下问题的可核验证据：

变更对象是否唯一明确？ 设备、接口、协议实例、区域、地址族和路由策略应被准确识别，避免模板变量或设备选择错误。
允许的路由集合是什么？ 应存在明确前缀或属性条件，不应把“所有 BGP 路由”作为隐含默认值。
最大基数是多少？ 必须为接收、产生和重分发的路由数量设置与用途相符的上限。
方向是否锁定？ BGP 到 OSPF、OSPF 到 BGP、IPv4 和 IPv6应分别表达，不允许模糊的双向或跨地址族效果。
传播范围是否受限？ 首次激活应落在可隔离的金丝雀或有限设备组，而不是立即进入全球关键路径。
渲染配置是否经过核对？ 审批对象应是最终设备语义，不只是抽象模板或人工描述。
运行状态由什么验证？ BGP、OSPF、LSDB、RIB、FIB、邻接、CPU 和内存都应有变更前基线与变更后预期。
自动中止条件是什么？ 路由数量、增长率、邻接抖动、资源压力或外部可达性越界时，应停止或撤回。
管理路径是否独立？ 带外网络、控制台和电源控制必须在维护前实际验证。
物理隔离是否可执行？ 现场人员、设备身份、断开步骤和影响边界应提前确定并演练。
外部证据是否覆盖双栈？ IPv4 和 IPv6 应分别从独立位置探测，不能用一个地址族代表另一个。
恢复关闭标准是什么？ 预期政策、安装状态和外部可达性必须一致，并保留时间戳证据。

这份清单不是对 OVHcloud 未披露控制的猜测，也不是断言其中每项在 2021 年均不存在。它是从公开事件边界出发形成的实务标准：如果一个变更具有把互联网规模状态带入内部协议域的能力，那么运营商应在激活前证明这种状态转换受到可执行约束。