摘要

  • CRTC 报告把故障时间界定为 7 月 8 日 04:58 EDT 至 7 月 9 日 07:00，并称超过 1,200 万移动和固网客户失去服务 [1]。
  • 七阶段核心升级进行到第六阶段时，工作人员删除 ACL 策略过滤；完整 BGP 表被重分发进 OSPF，核心路由器 CPU 与内存耗尽 [1]。
  • 前几阶段成功后，第六阶段风险从“高”降为“低”，因此不再要求额外审查、更高层批准或实验室测试 [1]。
  • Rogers 管理网络依赖故障中的 IP 核心，关键站点也没有其他运营商提供的独立管理连接，诊断因此延误 [1]。
  • 可信闭环必须证明路由数量上限、配置差异语义审查、自动回滚、带外管理，以及各关键服务的负向复现测试。

一行配置打开了整张路由表

Rogers 在事故前数周一直执行一项七阶段 IP 核心升级。CRTC 评估把触发点定位在第六阶段：分发路由器配置中的策略过滤被删除 [1]。

这项变更跨越了协议边界。BGP 用于自治系统之间的可达性和策略，可以承载庞大的互联网路由表；OSPF 主要向同一运营域内的路由器分发内部状态。把经过选择的小部分路由重分发到内部协议可能有合理用途，但把不受约束的完整 BGP 表送入 OSPF，会让大量核心设备处理原本不属于该域的状态。

过滤在 04:43 EDT 被删除。两分钟内，核心网关开始失败；到 04:58，事故时间线记录分发路由器向核心发送了超出处理能力的路由。CPU 和内存被耗尽，移动通信、家庭电话、互联网、企业固网和 9-1-1 连接中断。服务直到次日早晨才逐步恢复 [1]。

Rogers 最初的公开说明更概括。7 月 8 日，首席执行官承认移动和固网同时故障并承担责任 [4]。7 月 9 日，公司表示核心维护后发生网络系统故障，一些路由器异常；团队隔离相关设备并重定向流量 [5]。这些材料记录当时的公开认知，后来的 CRTC 评估则决定技术机制的事实边界。

冗余设备复制了同一暴露面

多台路由器并不自动形成韧性。若每台设备都接收同一份超量状态，冗余只会复制失败。报告称，过滤消失后，标准配置允许 BGP 路由进入 OSPF。它指出与事故有关的四项缺口：核心路由器没有足够的过载保护，没有限制分发路由器送入 OSPF 的 BGP 路由数量，缺少对策略命令的人工与自动审计，也缺少自动回滚 [1]。

明确的重分发契约应说明哪些路由可以跨越协议、业务理由、最大数量、保留属性、接收设备和超限动作。过滤并非无关紧要的配置清理，而是两个状态系统之间的可执行边界。

真正的独立性不由设备、站点或厂商数量决定，而由一份无效状态能否同时到达它们决定。硬性路由上限、传播前验证或自动回滚，必须在共同资源耗尽之前中断链条。若所谓金丝雀设备会立刻把危险状态发布给整个核心，它就没有缩小爆炸半径。

风险算法奖励了已经完成的阶段

这项七阶段计划最初被评为高风险。因为前几阶段成功，Rogers 的算法把第六阶段降为低风险，包括删除过滤的变更。低风险意味着不必增加审查、不必提高批准层级，也不必在实验室验证 [1]。

前一阶段成功不能证明下一阶段等价。后续步骤可能触及不同策略分支、设备范围或故障域。删除一行配置的文本差异很小，却可能放开巨大状态空间。风险判定必须理解当前差异的语义：删除过滤、跨协议重分发、影响共同核心，本身就应触发高等级审查。

可靠变更记录应把工单同变更前后字节、机器可读的路由意图、实验室结果、预期路由数、部署范围、观察窗口、停止阈值、回滚动作和负责人绑定。自动验证应在生产传播前拒绝超出声明包络的路由增长。

共同核心放大了全国后果

移动与固网接入共用一个 IP 核心。报告并未把这种 Tier 1 运营商常见架构本身称为设计缺陷；但它同时认定，共同核心让事故范围极端，因为一个控制故障同时移除了两类接入 [1]。这两项结论不能拆开使用。

融合可以降低重复投入、提高资源利用率，也会把语音、移动数据、家庭互联网、企业、紧急呼叫、公共预警、监控和内部通信放在同一个路由决策后面。关键不是断言融合必然错误，而是确定哪些服务必须在单一控制故障下继续存在，并用演练证明独立故障域。

CRTC 摘要称，Rogers 后来决定把移动与固网 IP 核心分离；报告发布时这项工作尚未完成 [2]。两个核心只有在策略、发布流程、管理接入和测试也不共享同一危险机制时，才真正降低相关性。

9-1-1 和公共预警也受影响。Rogers 在故障开始 3 小时 56 分后的 08:39 通知 9-1-1 网络提供者，08:54 才首次面向客户发布网络级说明 [1]。CRTC 7 月 12 日函件批评早期没有向公众提供替代紧急呼叫方式 [3]。报告对部分精确数字作了遮蔽，文章不应自行补全。

管理网络随被管理网络一同失效

Rogers 的远程管理依赖生产 IP 核心。核心失效后，异地工程师无法访问关键网元；网络运营中心和重要远端站点也没有其他服务商提供的管理冗余。工作人员不得不前往现场物理接入，根因分析和恢复因此放慢 [1]。

事故人员之间的通信同样依赖 Rogers 自有服务。报告称第三方 SIM 数量有限，错误日志起初无法取得，团队约 14 小时后才锁定根因。同一维护窗口还包含多项变更，使得应回滚哪张工单更难判断 [1]。

管理独立性必须同时覆盖物理路径、逻辑网络、身份认证、本地控制台、日志保留和人员通信。证明方式不是展示架构图，而是在生产核心完全不可用的演练中，仍能登录设备、读取证据、协调响应、执行可逆变更并验证结果。

RFC 6192 从一般工程角度说明路由器控制平面需要识别合法流量，并对其他流量过滤或限速 [8]。它不诊断 Rogers 事故，也不定义 BGP 到 OSPF 的重分发策略，但它强调转发容量与控制容量是不同资源，控制平面必须在负载下保持稳定。

修复措施必须生成运行证据

CRTC 记录了事故后的多项措施：阻止路由数据洪泛的核心保护，物理和逻辑分离的管理网络，第三方备份连接，配置验证工具，新风险算法，更多实验室测试，自动回滚改进，明确事故职责和独立通信手段 [1][2]。评估认为这些措施组合足以处理根因并改善韧性 [2]。

控制声明还需要执行证据。路由安全要展示配置上限、BGP 与 OSPF 实测数量、受控超限被拒绝，以及核心 CPU/内存仍在边界内。变更安全要展示准确差异、独立批准、实验室、隔离金丝雀和失败断言触发的回滚。

管理安全要在生产核心隔离时证明替代运营商路径、独立认证、日志和通信可用。业务连续性则需外部验证移动注册、语音、短信、数据、固网、企业、9-1-1、公共预警和代表性交易。路由恢复不等于电话接通；路由器绿色也不等于预警到达终端。

ARIN 当前记录把 AS812 标识为 ROGERS-COMMUNICATIONS，并列出 Rogers Communications Canada Inc. 为注册主体 [6]；PeeringDB 当前把 AS812 公开为 Rogers Cable [7]。这些记录证明公开身份，不重建 2022 年私有核心。Heng.lu 原则在此很清楚：注册表是账本，运行代码和实际路由决定通信是否继续。每一项行政批准都必须同带时间戳的运行观察对账。

来源

  1. https://crtc.gc.ca/eng/publications/reports/xonarp2023.htm
  2. https://crtc.gc.ca/eng/publications/reports/xona2024.htm
  3. https://crtc.gc.ca/eng/archive/2022/lt220712.htm
  4. https://about.rogers.com/news-ideas/a-message-from-tony-staffieri-president-and-ceo-at-rogers/
  5. https://about.rogers.com/news-ideas/a-message-from-rogers-president-and-ceo/
  6. https://rdap.arin.net/registry/autnum/812
  7. https://www.peeringdb.com/api/net?asn=812
  8. https://www.rfc-editor.org/rfc/rfc6192.html