<!-- title: 罗杰斯全国断网26小时复盘 -->

# 一条ACL过滤器放倒全国网：罗杰斯断网26小时完整复盘

## 概述

2022年7月8日凌晨4:43（美东时间），加拿大运营商Rogers的一名工程师在IP承载网割接中删除了分布路由器上的一条ACL策略过滤器。仅仅15分钟后，全部核心路由器被路由信息“淹死”，加拿大史上最大断网事故爆发：超过1200万个人和企业用户的移动、固网、911报警、银联卡支付（Interac）服务同时中断，全业务恢复耗时26小时17分。2024年公开的CRTC委托Xona Partners评估报告，首次完整披露了从触发、定位到恢复的全过程。本文回答三个问题：一条配置如何垮掉一个全国性Tier 1网络？为什么根因定位花了约14个小时？四年过去，这次事故给全行业的整改清单兑现了多少？

## 一、事故经过：一次“清理配置”引发的塌方

Rogers的无线网（2G/3G/4G/5G）和固网（DOCSIS cable与光纤）共享一张融合IP核心网，这是全球Tier 1运营商的常见架构。事故前几周，Rogers正在执行一个**七阶段IP核心网升级工程**，出事的正是第六阶段：为了完成升级，需要在分布路由器上删除一条ACL策略过滤器，目的是“清理配置文件”。

时间线如下（均为美东时间EDT，依据CRTC/Xona报告附录1）：

| 时间 | 累计时长 | 事件 |
| --- | --- | --- |
| 7月8日 04:43 | 0:00 | 第一台受影响分布路由器提交变更，删除ACL策略过滤器（触发点） |
| 7月8日 04:44 | 0:01 | Kentik观测到Rogers（AS812）流量骤降至接近零 |
| 7月8日 04:58 | 0:15 | 分布路由器向所有核心路由器洪泛路由，核心路由器内存超限、停止处理流量，全国业务中断 |
| 7月8日 08:39 | 3:56 | Rogers才通知911网络提供商（Bell、Telus、SaskTel），请求转告PSAP接警中心 |
| 7月8日 08:54 | 4:11 | 首次通过Twitter向客户发布故障通告 |
| 7月8日 11:19 | 6:36 | 通报CRTC监管机构和公共预警系统运营方Pelmorex |
| 7月8日 23:43 | 19:00 | 政企VPN接入恢复 |
| 7月9日 07:00 | 26:17 | 全国各区域业务基本恢复 |
| 7月9日 10:51 | 30:08 | 通知911网络提供商网络已恢复 |
| 7月9日 16:25 | 36:42 | 故障以来首次成功向手机下发Pelmorex公共预警短信 |

受影响面覆盖Rogers自有品牌（Rogers、Fido、Chatr）全部移动和宽带用户，以及依靠其网络的部分转售ISP、漫游伙伴、联邦/省/市三级政府、医院、能源交通企业和Interac金融清算网络——刷卡、e-转账在全加拿大范围内大面积瘫痪。

```mermaid
flowchart TD
    A["第六阶段割接：删除分布路由器ACL过滤器"] -->|触发| B["云端DNS地址被允许直接注入OSPF"]
    B --> C["BGP全表重分布进OSPF"]
    C --> D["海量LSA洪泛至核心层"]
    D --> E["核心路由器CPU与内存耗尽"]
    E --> F["核心路由器集体宕机，全网无路由"]
    F --> G["移动、固网、911、公共预警全断"]
    F --> H["网管网依附生产网一起瘫痪"]
    H --> I["只能派员赴站点现场排障，根因定位耗时约14小时"]
    F --> J["恢复期千万终端集中重连"]
    J --> K["对MME限流，防范信令风暴"]
```

## 二、根因：BGP全表倒灌OSPF，核心路由器被“撑死”

这是本次事故最值得IP承载网工程师咀嚼的部分。Rogers核心网内部用OSPF/IS-IS作为IGP，对外用BGP与其他AS交换路由。那条被删除的ACL过滤器，本来承担的职责正是**阻止BGP路由重分布进OSPF**。过滤器一删，配置模板的默认行为是允许把互联网BGP全表（Rogers正常情况下对外宣告约970条IPv4/IPv6前缀，但学习到的全表规模远大于此）重分布进OSPF——OSPF作为链路状态协议，瞬间被海量LSA灌爆，核心路由器CPU和内存耗尽，几分钟内全部宕机。

这里有一个广泛流传的误读需要纠正。事故初期舆论普遍归因于“BGP路由被撤销”，Kentik的深度分析对此明确证伪：

- 正常情况下AS812对外宣告约970条前缀，故障期间数百条分批撤销（08:44、08:50、08:54、08:59、09:10、09:25 UTC分多批发生），但**始终有约240条IPv4和120条IPv6路由在全局路由表中存活**；
- 这些仍然存活的路由却几乎不承载任何流量，说明问题不在外部可达性（BGP），而在**网络内部（IGP层面）已经瘫痪**——BGP撤销只是症状，不是病因；
- 少量流量经Bell、Telus、Beanfield等竞争对手网络绕行存活，而无线用户“手机无信号”也印证了故障深入到移动核心网依赖的内部路由。

Kentik的这句话值得写在每张割接卡上：“如果你错误地命令路由器撤销BGP路由，而路由器照做了，那不是BGP的错。”

更致命的是**防护缺失**。Xona报告指出，行业针对BGP策略错误早已形成成熟最佳实践：核心路由器配置过载保护上限、限制分布路由器注入OSPF的路由数量、对BGP重分布策略命令做人工+自动双重审计、支持配置自动回滚。事故前Rogers的核心路由器**没有配置任何路由过载保护**——事后整改的第一条，就是给核心路由器加上BGP→OSPF重分布条数上限和OSPF数据库条目上限。两条配置，本可拦住这场灾难。

## 三、放大器：为什么一条配置能垮掉全国网

单一配置错误在成熟网络里本应被层层拦截。复盘这份报告，至少有五个系统性的“放大器”把一次局部变更变成了全国灾难：

**1. 风险等级被算法降级。** 七阶段工程最初评估为“高风险”，但因为前五个阶段都顺利完成，风险算法按“历史成功率”把第六阶段自动降为“低风险”——于是免除了额外审批和实验室测试。而行业标准恰恰要求：涉及BGP策略的配置变更必须高风险对待、必须先做实验室验证。**用“上次没出事”为“这次降门槛”背书，是变更管理里最隐蔽的陷阱。**

**2. 网管网依附生产网。** Rogers的网管网络依赖自家IP核心网承载，核心网一瘫，工程师远程登录全部失效，NOC和关键站点也没有第三方运营商的备份专线，只能派人开车去现场登车排障，大幅拉长了恢复时间。

**3. 内部通信全军覆没。** 员工之间沟通依赖自家手机和宽带，网络一断，应急指挥体系失联，只能从竞争对手那里搞来他网SIM卡、派人送到各个站点——事故发生约5小时后才有足够数量的他网卡到位。事故发生47分钟后值班经理才拉起电话会议。

**4. 同一割接窗口塞了多项变更。** 当天维护窗口内执行了多项配置变更，故障发生后工程师无法判断该回滚哪张变更单，最初把排查焦点错误锁定在核心路由器上，而不是触发源分布路由器。**约14小时后才定位到根因**，期间连宕机路由器的错误日志都拿不到。

**5. 融合核心网的爆炸半径。** 无线+固线共用一张IP核心，日常是成本最优解，故障时就是全国单点。报告认为这不算“设计缺陷”而是行业普遍的设计取舍，但 consequence 是残酷的：核心网一断，LTE/5G移动核心（MME/HSS）完全失去承载，无线侧RAN虽活着但手机全部脱网，2G/3G电路域反而因IP核心间歇性恢复而接通了一部分911呼叫。911体系与公网共用路径，没有独立的应急旁路。报告还澄清，此次故障与多厂商设备互操作性无关；标准允许多种实现，具体行为以各厂家官方文档为准。

## 四、恢复：14小时定位后的“教科书式”回血

定位到根因后，Rogers的恢复动作反而可圈可点。核心动作是对**MME做限流**，让千万台终端分批、渐进式地重新注册入网——这是Rogers从2021年4月一次故障中换来的教训：网络恢复瞬间，海量终端并发附着/重注册会触发信令风暴，把刚爬起来的核心网再次打瘫。依靠预先限流，7月8日夜间起业务分区域渐进恢复，深夜恢复移动优先（Rogers无线用户超过1000万，优先恢复是为了让最多的人能打通911），7月9日07:00全国业务基本恢复，恢复全程未再发生二次雪崩。

外部通信同样狼狈：首次客户通告发生在故障后4小时11分（Twitter），通知911网络提供商用了3小时56分，通知监管和预警体系用了6小时36分——而事后发布的报告特意对比：美国FCC在2022年11月的911可靠性新规中，已要求故障发现后**30分钟内**必须通知911特殊设施部门。整个过程Rogers甚至没有主动告知公众“断网期间如何打通911”（例如拔出SIM卡搜索他网）。

## 五、整改清单与监管结论：26亿加元买来的教训

事故后Rogers的整改，Xona报告逐项给了评估，总体结论是“令人满意（satisfactory）”，同时明确定性：**这不是架构设计缺陷，而是“配置错误+流程失效”的组合**。关键动作包括：

| 整改项 | 具体措施 | 投入/进展 |
| --- | --- | --- |
| 路由过载保护 | 核心路由器加BGP→OSPF重分布上限、OSPF数据库条目上限 | 已落地，最关键的一条 |
| 无线/固线核心网分离 | 为无线网新建独立IP核心，固网沿用现有核心 | 2.61亿加元，仍在推进 |
| 独立网管网 | 新建物理+逻辑独立的网管IP网（RCMIN），支持带内+带外管理 | 已落地 |
| 关键站点备份链路 | NOC及关键站点引入第三方ISP互联网出口，评估卫星备份 | 已落地 |
| 变更管理 | 新风险评估算法、核心配置双人评审、变更类型分级、单窗口变更数量上限、实验室测试 | 已落地 |
| 应急管理 | 告警自动分级抑制、核心路由器自动回滚、全员配发他网SIM卡、桌面演练 | 部分落地 |
| 灾难漫游 | 与Bell、Telus、SaskTel、Eastlink、Videotron/Freedom签署应急漫游协议 | 已签约，终端侧场景仍待验证 |
| 三年投资计划 | 网络扩建与加固 | 111.66亿加元 |

行业层面，2022年9月加拿大12家运营商在CSTAC框架下签署《电信可靠性谅解备忘录》，约定应急漫游、互相支援和重大故障通报机制；3GPP从R17起也把灾难漫游（disaster roaming）纳入标准。但Xona报告泼了冷水：应急漫游协议在“RAN活着、核心网瘫了”这种场景下，手机能否自动搜索并注册到他网完成911呼叫，**至今缺少端到端的实测验证**——协议签了不等于能用。

另一个耐人寻味的细节：Rogers为2021年4月那次故障做过详尽的根因分析报告，整改也确实加固了移动网——**但同样的流程改进没有延伸到IP核心网**，一年后在同一类问题上栽了更大的跟头。2026年8月仍有行业媒体在讨论，这次事故如何让“IP核心网路由管控”成为运营商问责的固定科目。

## 六、给网络工程师的七条可落地教训

1. **任何BGP↔IGP重分布都是高危操作**，必须过载保护上限（如OSPF外部LSA/前缀数量上限）兜底，不允许“裸奔”上生产网。
2. **警惕“低风险”降级逻辑**：变更风险评估看的是变更内容的固有风险，不是执行者的历史成功率。路由策略类变更一律走最高审批+实验室验证。
3. **单窗口多变更等于事故后无法回滚**：一个维护窗口尽量只做一张变更单，回滚预案要能一键回退到唯一基线。
4. **网管网必须物理/逻辑独立于生产网**，NOC和关键站点必须有他网备份链路，否则故障时你会连自己的设备都摸不到。
5. **给核心岗配发他网SIM卡并演练**：沟通中断的时间，就是故障时长被拉长的时间。
6. **恢复比故障更需要设计**：MME限流、分区域渐进放号、告警分级抑制，都要在故障前写进预案并演练过。
7. **911/应急呼叫路径要有独立生命线**：核对自家网络在“核心网瘫、无线活”场景下，终端能否自动漫游到他网完成紧急呼叫——3GPP R17+的灾难漫游标准值得对齐。

## 结论

罗杰斯断网的直接肇因是一条ACL过滤器的删除，但真正压垮全国网的，是被算法降级的风险评估、依附生产网的网管系统、失联的应急通信和缺失的过载保护。对一线工程师而言，这起事故最有价值的启示恰恰是它的“平凡”：没有天灾、没有黑客、没有硬件批量故障，只有一个看似无害的配置清理动作，落在了一张没有防御纵深、没有带外生命线的网络上。把过载保护、独立网管网、他网备份链路、应急漫游演练这四件事做实，成本远低于2.61亿加元的核心网分离——但必须在下一次凌晨4:43的割接之前。

## 参考来源

1. [Assessment of Rogers Networks for Resiliency and Reliability Following the 8 July 2022 Outage（CRTC委托Xona Partners评估报告）](https://crtc.gc.ca/eng/publications/reports/xonarp2023.htm) — 事故时间线、根因、整改措施的一手权威来源
2. [A deeper dive into the Rogers outage（Kentik Blog）](https://www.kentik.com/blog/a-deeper-dive-into-the-rogers-outage/) — 基于NetFlow与BGP数据证实“BGP撤销是症状非病因”
3. [Human error caused 2022 Rogers outage, system deficiencies made it worse（CBC News）](https://www.cbc.ca/news/politics/rogers-outage-human-error-system-deficiencies-1.7255641) — 2024年报告发布时的独立新闻报道
4. [Rogers July 2022 Outage Assessment Report（Xona Partners完整版PDF，加拿大政府出版库）](https://publications.gc.ca/collections/collection_2024/crtc/BC92-130-1-2024-eng.pdf) — 报告正式出版版本
5. [Rogers' 2022 outage made IP-core route controls an accountability（BTW Media, 2026-08）](https://btw.media/en/rogers-2022-ip-core-route-control-accountability) — 事故四年后行业对IP核心网路由管控问责的延续讨论

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。