<!-- title: 删错一个配置，半个国家离线 -->

凌晨四点四十五分，多伦多还睡着。加拿大最大运营商 Rogers 的核心网里，一个七阶段大改造正进行到第六步——工程师删掉了分布层路由器上的一张配置模板。几十分钟后，全国1200多万用户的手机同时变成砖头，刷卡机集体哑火，911 打不通，连红绿灯都趴了窝。这不是地震，不是黑客，是一条路由过滤器。本文基于 Rogers 致监管机构的信函、Cloudflare 的全网测量数据和加拿大政府的处置记录，把这个被反复引用的经典断网案例拆开揉碎，讲清楚三件事：雪崩是怎么从一个配置动作滚起来的；为什么恢复花了近两天；以及加拿大监管为此立了哪些新规矩——对中国工程师的变更管理和重保体系又有什么镜鉴。

## 目录

- 事故概览：一个国家的离线日
- 目击记录：Cloudflare 眼中的 BGP 雪崩
- 根因链条：一个被删掉的配置模板
- 为什么修了将近两天
- 911 打不通：比断网更重的一击
- 影响面：从借记卡到红绿灯
- 代价与问责：1.42 亿加元与一份谅解备忘录
- 五条带血的教训
- 结语：下一次雪崩从哪来
- 参考来源

## 事故概览：一个国家的离线日

2022年7月8日，周五。Rogers 是加拿大三巨头之首，移动、宽带、有线电视一把抓，其位于多伦多的核心网同时承载着自研品牌 Fido、Chatr 以及大量租用其网络的虚拟运营商和批发宽带商（如 TekSavvy）。当天凌晨4点半到4点45分之间（不同来源口径略有差异），全网服务开始坍塌。

先摆几个经交叉验证的硬数字：

- **超过1200万用户**失联（Rogers 在致 CRTC 的信函中确认）；
- 据网络监测机构 Netblocks 测算，**约四分之一的加拿大互联网连接中断**；
- 全国 **Interac 借记卡网络瘫痪**——注意，这是全国性支付清算系统跑在 Rogers 的承载网上，无论商家用的是哪家宽带，只要清算链路走 Rogers，就刷不了卡；
- 断网持续到当天深夜开始缓慢恢复，Cloudflare 测量显示**约17小时后流量才回到实质回升通道**，部分用户的残余故障拖到了7月11日——也就是事故后的第四天。

一天之内，一个发达国家的金融清算、政府服务（Service Canada、税务局、护照 office）、医疗预约、公共交通系统被一张运营商的网拖下水。这正是这个案例过去四年被全球运营商反复复盘的原因：它把“核心网变更风险”这个老话题，用国家级的代价重新讲了一遍。

## 目击记录：Cloudflare 眼中的 BGP 雪崩

事故发生时，外界最先看到的不是 Rogers 的公告，而是 Cloudflare 的测量曲线。Cloudflare 在事故当天发布的分析文章，是理解这次故障外部形态的最佳目击证词——以下数据全部来自该文，是可独立验证的测量事实，不是 Rogers 的自述。

Rogers 在互联网上的自治域是 AS812。Cloudflare Radar 显示，**08:45 UTC（多伦多时间凌晨4点45分）前后，AS812 的流量几乎完全消失**。更早的08:15 UTC，BGP 更新消息出现尖峰并在08:45达到顶点——随后是大规模的**IP 前缀撤销（withdrawal）**。

用运营商的话翻译一下：Rogers 的核心路由器之间先发生了剧烈的路由抖动，然后核心设备把对外宣告的全部网段撤了回去。在 BGP 的世界里，撤销宣告等于对全互联网说“我没了”。其他网络找不到 Rogers，Rogers 的用户自然哪也去不了。

接下来的曲线更像一部灾难片：

| 时间（UTC） | 观测到的动作 | 含义 |
|---|---|---|
| 08:15 | BGP 更新尖峰开始 | 核心网内部路由在抖 |
| 08:45 | 前缀批量撤销，流量归零 | 正式雪崩，对外“失踪” |
| 14:30 | 尝试重新宣告前缀 | 第一次止血，流量缓慢爬升 |
| 15:45 | 再次批量撤销 | 止血失败，二次坍塌 |
| 18:15 | 流量短暂回弹 | 只回到平常的约3%，持续半小时后再度跌落 |
| 21:45 | 又一次宣告尝试 | 再次坍塌 |
| 次日 00:15 起 | 流量实质性回升 | 一小时后恢复到前日同期的17.5% |
| 次日 08:40 | 恢复至前日同期的76% | 重伤脱险，未痊愈 |

Cloudflare 的判读一针见血：Rogers 核心网的内部会话在反复翻动（flapping），每次会话翻动都产生一批撤销与重新宣告——**这不是外部攻击，是网内自己在自己心脏上跳闸**。加拿大公共安全部随后也确认排除网络攻击。

对干过传输、数通的读者，这个形态再熟悉不过：典型的路由风暴振荡，起振之后每次重新收敛都可能再次触发过载，网络在“上线—过载—下线”的循环里打摆子。难点从来不是找到病灶，而是怎么在病灶还发着烧的时候把药喂进去。

## 根因链条：一个被删掉的配置模板

雪崩的外部形态清楚了，那第一块骨牌是怎么倒的？Rogers 事后在致 CRTC 的信函中给出了官方解释（以下转述以维基百科条目对信函的引述及 Cloudflare 测量为据）：

事故发生在 Rogers 核心IP网现代化改造的**第七阶段计划中的第六步**——一个典型的长期割接工程。维护窗口内，工程师在**分布层路由器上删除了一条路由过滤配置**。这条过滤器被删后，分布层到核心层的路由可达性发生剧变：**所有可能的互联网路径全部涌向核心路由器**，流量与路由表规模瞬间超出核心设备的处理能力，核心网设备出现异常并大规模下线自保。祸不单行：核心网瘫痪连带切断了 Rogers 内部的 VPN 和管理系统通道——工程师连自己的核心网节点都够不着了，排障队伍的组织本身就是一场战斗。

Rogers 后来发布的官方技术复盘（公司层面数十页的报告，并配合高管在加拿大国会作证，据公开报道）补充了更细的链条：被操作的对象是分布层的**紧凑路由引擎（CRF）设备上的一组配置模板**，删除导致这批设备与分配网失联；重新激活恢复时，设备携带过期的定时器信息重新上线，过期路由信息涌入核心，触发连锁保护性关机。换言之：**第一刀是一个配置动作，第二刀是恢复动作本身**——把配置挂回去的那一刻，反而引爆了全网。

把整条因果链画出来，就是教科书级的级联失效：

```mermaid
flowchart TD
    A["七年期改造工程<br/>进行到第六阶段"] --> B["维护窗口内删除<br/>分布层路由过滤模板"]
    B --> C["路由可达性剧变<br/>全网路径涌向核心层"]
    C --> D["核心路由器过载<br/>进程异常"]
    D --> E["保护机制触发<br/>核心设备批量关机"]
    E --> F["BGP会话翻动<br/>全网前缀撤销"]
    F --> G["无线有线全断<br/>911与支付清算瘫梹"]
    G --> H["带内管理网同断<br/>排障队伍失联核心网"]
    H --> I["多次上线又坍塌<br/>恢复耗时近两天"]
```

这里有一个所有核心网工程师都该背下来的细节：**触发点在分布层，倒下的是核心层**。分布层的配置变更之所以能掀翻核心，靠的是“路由泄漏 + 转发路径收敛”这个放大器。过滤器和路由策略类配置，看似是控制面的小动作，实际决定的是整个网络的拓扑认知——这类变更的风险等级，永远不该按“只是删条过滤”来定级。

## 为什么修了将近两天

值得单独一章的，是恢复过程之艰难。从凌晨4点45分雪崩，到次日早上流量恢复七成六，中间隔着近28小时；若算上零星用户彻底恢复，接近四天。难在哪？三个结构性原因，每一个都有普遍意义。

**第一，恢复动作会再次触发故障。** Cloudflare 的曲线显示，Rogers 在当天14:30、21:45 UTC 两次尝试把前缀重新宣告出去，两次都在短时间内再次坍塌——15:45 UTC 还出现了第二轮批量撤销。核心设备还在“发烧”，此时把流量灌回去，过载保护机制又一次动作，网又塌了。这就是为什么这类事故的恢复必须小步引流、分批回流，而不能一键回滚——回滚的路径和故障的路径是同一条路。

**第二，带内管理网跟着主网一起死了。** 核心网瘫了，连着核心网的内部 VPN 和运维通道也断了。工程师手里有工具，却没有路走到设备跟前。Rogers 靠两样东西重建了指挥链路：一是2015年起与友商建立的互备协议——部分员工持有**异网应急 SIM 卡**（这在当时只是应对小范围故障的惯例，没人想到会用在全国性事故上）；二是让工程师**赶到集中办公点**重建接入。一个能建国家级网络的公司，排障的第一小时花在了“让自己上网”上。

**第三，想借鸡生蛋，借不动。** 清晨6点，CTO 联络了 Bell 和 Telus 的技术高层通报情况并提醒防范网络攻击，两家友商当场表态愿意支援。但 Rogers 评估后放弃了把用户切到友商网络的想法：一是用户数据库（HSS/HLR 类网元）自己都访问不了，鉴权数据拿不出来；二是1000多万用户瞬间涌入，Bell 和 Telus 自己也会被压垮。**漫游互备听起来很美，前提是自己的签约数据和对方网络的冗余容量都真实存在**——这两条，事故前没人认真验过。

对国内同行的映射很直接：我们的核心网割接普遍有“变更窗口+双人复核+回退预案”三件套，但问三个问题——回退路径本身做过演练吗？带外管理网和主网有没有物理级隔离？应急预案里有没有“指挥链自身失联”的场景？这三个问题，Rogers 在2022年7月8日那天，答案全是“没有”。

## 911 打不通：比断网更重的一击

断网造成的经济损失可以折算，911 打不通的代价无法折算。事故期间，Rogers 网上的手机无法拨打911紧急电话。CBC 随后报道了一起事件：安大略省哈密尔顿一名男子在姐姐病危时反复拨打911无人接听，其姐姐最终离世——报道称无法确认若电话接通结局是否不同，但这个细节让整个事故的问责级别骤然升级。

更深一层的问题在架构上：Rogers 不只是自家用户的911承载方，**大量其他运营商和 VoIP 供应商的911呼叫也经 Rogers 的网络转接**。一张网打盹，全行业的应急生命线跟着断。而当时加拿大并没有强制性的运营商间911互备协议——你家网断了，你家的用户在911面前就是孤儿，友商网络再空闲也不会自动兜底。

这直接催生了后来最重量级的整改（下节详述）：监管强制要求所有运营商之间建立911网络冗余协议。对工程师，这一节只有一句话要划重点：**应急呼叫链路的可用性指标，必须独立于普通业务，且必须验证“跨网兜底”这条路径是活的**——纸面协议不等于打通测试，互通联调没做过，关键时刻就是空号。

## 影响面：从借记卡到红绿灯

这次事故最震撼公众的一点，是把“运营商网络是国家关键基础设施”这个抽象命题变成了具体的瘫痪清单（以下来自《环球邮报》等多家媒体事故当天的盘点汇总）：

| 受影响领域 | 具体表现 |
|---|---|
| 支付清算 | Interac 全国借记卡交易中断， regardless 商家自身用哪家宽带，部分店铺直接关门 |
| 政府服务 | Service Canada、税务局（CRA）、护照办公系统部分中断 |
| 金融安全 | ATM 取款受影响，Interac eTransfer 转账停摆 |
| 城市运行 | 多伦多约四分之一交通信号灯依赖 Rogers 蜂窝网做配时联动；市政楼宇消防喷淋告警监控失灵；公共停车缴费、公共单车瘫痪 |
| 医疗 | Niagara 医疗系统放疗患者的预约被迫改期，急救转运预案启动 |
| 民生商业 | 小企业主损失数百到数千加元不等（CFIB 调查）；The Weeknd 当晚在 Rogers Centre 的演唱会因场地系统瘫痪延期 |
| 运营商自身 | 同日内部邮件要求门店撤下“加拿大最可靠5G网络”宣传物料 |

这个清单在行业内的价值，是给“一张网的失效半径”提供了一个罕见完整的实测样本：**故障半径远大于用户半径**。Rogers 的用户是1200万，但被这张网绊倒的系统服务于全体加拿大人。当清算网络、政务系统、消防监控把承载层寄托在单一运营商身上时，运营商的每一次核心网变更多久做一次灰度，就成了全社会的事。

## 代价与问责：1.42 亿加元与一份谅解备忘录

算账与追责，两面都要看。

经济账：据彭博社报道测算，断网期间对加拿大经济的拖累约 **1.42亿加元**；Rogers 给全部用户补偿五天服务费，媒体估算这笔补偿在2800万至7000万加元之间；魁北克省高等法院随后出现集体诉讼，代表用户索赔每人400加元。8月下旬，Rogers 公布三年期100亿加元网络投资计划，其中**2.61亿加元专门用于将无线与有线核心网物理分离**——把鸡蛋分进两个篮子，这是这次事故买到的最贵的架构课。此外，7月21日，CTO Jorge Fernandes 被替换，由 Ron McKenzie 接任。

监管账，动作比罚款重得多。7月11日——断网后的第一个工作日——联邦创新科技与工业部长商鹏飞（François-Philippe Champagne）召集 Rogers、Bell、Telus、Shaw、Vidéotron、SaskTel、Eastlink 七家运营商 CEO 开会，宣布三条强制要求：**运营商之间必须建立断网互助机制（mutual assistance）；必须为友商受灾用户提供紧急漫游；必须建立面向公众的故障通报机制**——限期60天落实协议。2022年9月，各运营商向 ISED 提交了《电信可靠性谅解备忘录》（MOU）。CRTC 同步立案调查，并在2024年7月发布了针对 Rogers 网络韧性与可靠性的评估执行摘要——距事故整整两年，监管的跟进一直没停。

还有一个绕不开的背景：事故发生时，Rogers 正在推进200多亿加元收购 Shaw 的交易。断网次日，交易达成概率被交易员从88%下修到62%；反对者把这次事故作为加拿大电信寡头集中度风险的活证据。三个月后政府有条件放行交易，但历史会记住这个细节——**一次核心网事故，直接参与了一场国家级并购的定价**。

```mermaid
timeline
    title 事故之后：从雪崩到新规
    7月8日凌晨 : 全国断网开始
    7月8日晨 : 部长级会议筹备启动
    7月11日 : 七家CEO被召集 : 三条强制新规公布
    7月21日 : CTO被替换
    8月25日 : 261亿加元计划含核心网物理分离
    9月 : 电信可靠性谅解备忘录提交
    2023年 : 收购Shaw有条件放行
    2024年7月 : CRTC发布网络韧性评估摘要
```

## 五条带血的教训

复盘至此，把工程师真正能用上的东西拎出来。以下五条，前四条是事实教训的引申，第五条是笔者的行业观点，分开摆。

**第一，路由策略类变更，风险定级要按“拓扑变更”算，不能按“配置行数”算。** 删一条过滤器、改一条 route-policy，动的是全网设备对拓扑的认知。凡涉及路由可达性的变更，必须做失效域分析：这个模板删了之后，谁的路径会变？变完之后最坏路径是什么？第七阶段改造走到第六步才出事，说明前五步都安全通过——**灰度通过不等于第六步安全，每一次变更都是独立的赌局**。

**第二，保护机制要同时设计“防触发”和“可恢复”。** 核心设备过载自保本身没错，错的是没人演练过“保护动作发生后怎么走出来”。自保触发的恢复路径，要和业务恢复路径分开设计：快速重启、平滑重启、状态保持机制能不能让设备带病重新收敛而不是重新过载？这需要在实验网里真正触发一次保护机制来验证，而不是等生产网替你验证。

**第三，带外管理网必须做到物理级独立。** Rogers 的教训是带内管理通道与主网同生共死。带外管理网的传输路径、供电、DNS 依赖都要独立评审，并且每年做一次“主网全瘫时管理网还活着”的实战演练。国内很多网络有带外网，但带外网的上联借用主网光缆纤芯的情况并不罕见——这种设计在纸面架构图上看不出来，挖开管道才看得出来。

**第四，跨网兜底要“实测在线”，不能“协议在档”。** 应急 SIM、漫游协议、911 互备，落成文字只是第一步。Rogers 当天没有用户的鉴权数据、友商没有冗余容量，纸面协议全线失效。兜底机制要定期实打实验证：借网注册能不能成、911 跨网呼叫能不能通、承载容量压力测试做没做。监管现在把互助写成了强制义务，工程师要把它写成周期性测试用例。

**第五（笔者观点），国家关键业务对单一承载网的依赖，是比任何技术缺陷都贵的单点。** Interac 的清算流量、多伦多的红绿灯、消防监控，全押在一家运营商的网上——技术层面每个系统可能都有自己的高可用，但高可用的地基是同一个坑。这次事故之后，加拿大把“互助+紧急漫游+通报机制”写成制度，本质是承认：**基础设施的韧性无法靠任何单一运营商的自省达成，必须靠跨网冗余的制度化**。对我国“双平面、双路由、异地多活”的实践，这算是一个来自北美的同题印证：物理分离（Rogers 花2.61亿加元做的事）永远优先于逻辑冗余。

## 结语：下一次雪崩从哪来

回头再看那条时间线：凌晨4点45分雪崩，上午定位是内部升级，下午两次止血失败，深夜才摸到实质回升的门槛。没有黑客，没有天灾，只有一个维护窗口里的一行配置。这类事故最让人后背发凉的地方在于：**它的全部要素——割接窗口、灰度推进、配置模板、过载保护——每一家运营商的每一个深夜都在上演**。Rogers 与其他运营商之间，隔着的不是技术代差，只是一个还没轮到的概率。

加拿大用1.42亿加元的经济损失、一次无法挽回的911呼叫和一套全国性新规，替全行业把这个学费交了。对每一个明天夜里要进割接窗口的工程师，这次复盘的收尾只有一个请求：把你的回退预案再读一遍，然后问自己——回退这条路，故障发生时它还活着吗？

## 参考来源

1. [2022 Rogers Communications outage - Wikipedia](https://en.wikipedia.org/wiki/2022_Rogers_Communications_outage) — 事故全景条目，含 Rogers 致 CRTC 信函要点、监管处置时间线及30余条媒体引注，本文核心事实的主要交叉验证源
2. [Cloudflare's view of the Rogers Communications outage in Canada](https://blog.cloudflare.com/cloudflares-view-of-the-rogers-communications-outage-in-canada/) — Cloudflare Radar 对 AS812 的 BGP 实测记录，本文全部流量曲线数据与“核心网翻动”判读的出处
3. [Rogers Communications - Wikipedia](https://en.wikipedia.org/wiki/Rogers_Communications) — 2021/2022两次断网章节、Shaw 收购背景及监管新规上下文

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

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
