2022年7月8日凌晨4点45分前后，加拿大最大移动运营商Rogers在一次例行网络维护中，因为一根跳线让核心分布式路由器“失明”，随后引发路由风暴，全国性断网超过12小时：上千万无线用户失联、全国银行借记卡刷卡瘫痪、多地911报警电话打不出去。本文以Rogers官方新闻室的7月系列声明、CRTC与ISED的2022-232号联合审查公告以及Wikipedia事件条目汇编的多方报道为锚，完整复盘：故障是怎么滚起来的、为什么最后是两家对手公司救的场、恢复期为什么又险些翻车，以及它给核心网运维留下的四条硬启示。
先说清楚Rogers在加拿大是什么体量。加拿大人口不到4000万，电信市场高度集中，Bell、Rogers、Telus三家瓜分了绝大部分移动用户，其中Rogers无线用户超过1100万，约占全国移动市场三成（财报公开口径），家庭宽带在多个人口大省市占第一。这不是“某一家运营商停摆”，而是“全国每三个人里有一个人的手机没信号”。
更麻烦的是，现代经济对电信网的依赖远不止打电话。当天早上，加拿大人发现的是一整条连锁反应：
还有一个背景必须交代：事发时Rogers正在推进对第四大运营商Shaw约260亿加元（含债务口径）的收购。一场全国断网，恰好砸在这个“市场已经太集中”的敏感话题上，这决定了后面追责的烈度。
下表是按多方公开信息（Rogers官方声明、Wikipedia条目汇编的媒体报道、监管文件）还原的时间线，个别时刻为媒体报道口径，仅供参考：
| 时间（当地时间，ET） | 事件 |
|---|---|
| 7月8日 凌晨4:45前后 | 例行维护作业中，一根跳线导致核心分布式路由器“失明”，网内路由开始紊乱 |
| 7月8日 早晨 | 路由信息与BGP对外宣告大面积丢失，无线与宽带全国性中断；多地警方提醒911可能无法接通 |
| 7月8日 上午至午后 | Rogers确认为核心网故障；应其请求，Bell与Telus临时断开与Rogers的私有互联链路，路由风暴停止跨网蔓延 |
| 7月8日 下午至夜间 | 网内路由逐步重建，部分移动与宽带业务恢复 |
| 7月9日 | CEO托尼·斯塔菲耶里公开致歉，称绝大多数系统已恢复，全网巩固持续数日 |
| 7月22日 | 官方公布初步根因“一根维护线”，承诺自动补偿5天月费、18个月内将无线911网络物理分离 |
| 2022年8月起 | CRTC与ISED启动联合审查（2022-232），网间互助、强制事故通报、911可靠性进入监管议程 |
注意两个数字的反差：故障触发只用了一瞬间，而移动业务大面积恢复花了一天以上，全网彻底稳定用了好几天。后面会讲到，恢复期本身还差点酿成第二次事故。
这一节先把“事实分层”讲清楚，哪些是官方确认的，哪些是第三方技术分析的共识，哪些是作者判断——复盘事故最忌讳把推断当结论。
第一层：官方确认的事实。Rogers在7月22日的官方声明中给出的初步根因是：一根位于分布式路由器（Distribution Router，DR）上的维护跳线（maintenance wire），导致设备对网络“失去可见性”，并“为更大范围的故障创造了条件”。换句话说，官方口径只到“跳线→设备失明”这一层。官方同时表示最终结论以第三方独立审查为准。
第二层：第三方技术分析的共识。设备失明之后发生了什么，Rogers官方没有逐字披露，但Cloudflare的BGP观测、CERT/CC以及多家行业技术分析给出了高度一致的叙述链条：DR失明触发大规模路由重算，路由更新像洪峰一样冲击全网其他DR的控制平面；多台DR的控制卡被冲垮、崩溃重启；核心路由信息大面积丢失；最终Rogers与外部对等点的BGP会话中断，对外路由宣告整体撤回——从全球路由表的角度看，Rogers“从互联网上消失了”。
用运维的话翻译一遍：这不是一次硬件烧毁式的故障，而是一次“控制面雪崩”。物理层的一根跳线是火种，路由协议的收敛机制是助燃剂，全网同构同版本的核心路由器是干柴。当所有DR都在同一时刻疯狂重算、互相冲击控制卡时，网络不是“慢下来了”，而是集体失去了“我是谁、我在哪、邻居是谁”的记忆。这类共模故障的可怕之处在于：冗余设计全部失效——你有一百台备份路由器，但它们跑着同样的软件、执行着同样的收敛逻辑，于是一百台一起倒。
flowchart TD
A["例行维护中插入一根跳线"]
B["核心分布式路由器失明"]
C["触发全网路由重算"]
D["路由更新洪泛冲击控制面"]
E["多台路由器控制卡崩溃重启"]
F["核心路由信息大面积丢失"]
G["BGP对外宣告整体撤回"]
H["Rogers从互联网上消失"]
A --> B
B --> C
C --> D
D --> E
E --> F
F --> G
G --> H
H --> I["风暴或经私有互联外溢"]
I --> J["对手切断与Rogers的直连"]
J --> K["网内重建路由与会话"]
K --> L["服务开始恢复"]
L --> M["数百万终端同时回连"]
M --> N["二次拥塞：分批放闸"]
第三层：作者判断。官方“设备失明后为何会引发全网控制面雪崩”的具体内部机制（是否存在配置回滚异常、过滤策略缺失等），公开材料并未逐项确认，以上链条属于多家第三方分析交叉后的行业共识，不是官方逐字结论。读者引用时建议保留这个区分。
这次事故里最戏剧性、也最有行业价值的一幕是：最后帮Rogers止血的，是它的两个死对头。
Rogers与Bell、Telus之间，除了公共对等之外，还有大量双边私有互联直连。路由风暴期间，路由抖动有可能经由这些互联向邻居网络传染——邻居的路由器陪着Rogers一起收敛、一起过载。而此时Rogers网内已经自顾不暇，很难在自家止血。
于是出现了一个在商业上匪夷所思、在工程上完全正确的操作：应Rogers请求，Bell和Telus临时断开了与Rogers的私有互联链路。这相当于先“物理隔离病人”，让风暴无法跨网传播，Rogers得以在自己的网内安静地重建路由和会话。事后这一操作被多次公开确认，并成为加拿大监管讨论网间应急机制的原型案例。
这一幕值得所有运营商记住：平日里，私有互联是降时延、省中转费的商务安排；灾难时刻，它既是故障的传播路径，也是隔离的开关。切换权在哪、谁有权拉闸、拉闸的判据是什么，必须事前写进网间协议和应急手册——不能指望事故当天早上，几家公司的NOZ（网络运营中心）临时打电话拍板。加拿大监管后续推动的“重大事故期间运营商互助与漫游义务”，本质上就是把这次临时的人肉协作，制度化成常备机制。
如果说路由风暴是第一次事故，那么恢复期的“回连风暴”差点成为第二次。
路由重建后，数百万台光猫、家宽CPE和手机终端同时尝试回连：DHCP请求、认证请求、开机附着、会话重建在极短时间内形成新的洪峰，部分刚恢复的区域“恢复了又掉”。CERT/CC事后发布的分析专门讨论了这个现象：大规模终端同时回连本身构成一种恢复期风暴，并建议终端与网络侧实现回连退避机制（随机化延迟、分批接入）。
这里有一个运维界经常低估的规律：故障的恢复过程，本身就是一个流量模型完全不同的新故障场景。稳态运行时，几百万终端的上线请求是均匀摊开在24小时里的；全网恢复时，同样的请求量被压缩到几十分钟内砸过来，DHCP、AAA、PCRF/策略控制、开机附着流程都要顶住平时数十倍的瞬时压力。
正确的做法是分批放闸：按区域、按业务、按优先级错峰恢复，对认证与会话建立限流，先把911和语音捞起来，再逐步放开数据。Rogers当天的恢复之所以拖得很长，与这波回连洪峰有直接关系。这也是为什么老运维常说：割接预案写到“业务恢复”还没写完，要写到“恢复稳定”才算完。
事故的收尾动作，比事故本身更值得细看。7月22日，Rogers官方公布了初步根因，并给出三项承诺：
| 整改动作 | 内容 | 依据 |
|---|---|---|
| 用户补偿 | 消费者与小企业客户自动抵扣5天月费，无需主动申请 | Rogers 7月22日官方声明 |
| 911分离 | 18个月内将无线911网络与商业网络物理分离 | 同上 |
| 第三方审查 | 委托第三方对网络架构、变更流程做全面独立复核 | 同上 |
监管层面，CRTC与工业部（ISED）随后启动联合审查，审查范围直指这次事故暴露的结构性问题：网间互联的应急机制、重大事故期间运营商之间的互助与漫游、事故强制通报、以及911网络的可靠性。这些议题在之后几年陆续转化为监管程序和政策讨论——换句话说，这次断网成了加拿大电信监管的一个分水岭事件。
商业层面的连锁反应同样剧烈。收购Shaw的交易在事发时正待批，渥太华借机强硬施压，创新部长尚帕涅公开要求Rogers给出整改与降费承诺。最终该交易在2023年4月附条件完成——Rogers按要求把Freedom Mobile出售给魁北克的Vidéotron。断网事故没有直接否掉交易，但它把“网络集中度=国家单点风险”这个命题，钉进了加拿大公共政策讨论的正中央。
回头看，这次事故最深远的影响不是赔了5天话费，而是三件事被永久改变：911从“逻辑冗余”升级为“物理分离”的强制要求；网间应急协作从“商业默契”走向“监管义务”；重大事故通报从“自愿”走向“强制”。
最后，把这些年看得见摸得着的教训收拢成四条，供核心网和承载网的同行对照自查：
第一，物理层也是变更，跳线也要过变更单。很多人对变更管理的理解停留在“软件版本、配置脚本、参数模板”，但这次事故的火种是一根物理跳线。高危区域内的任何物理作业——跳线、尾纤、板卡插拔、电源操作——都应纳入MOP（作业方案），作业前后核对告警快照和路由表快照。“就动一根线”是事故报告里出现频率最高的一句话。
第二，控制面要设计成“炸不塌”，而不是“不炸”。路由风暴抑制、SPF节流、控制卡过载保护、协议报文限速，这些机制的价值不是防止故障发生，而是保证故障发生时雪崩收敛在最小故障域。同时，同构同版本的核心设备要做灰度与错峰升级——当所有节点跑一样的软件、做一样的反应时，你的“冗余”只是同一个故障的N份拷贝。标准允许多种实现，具体保护机制的行为以各厂家官方文档为准，但“故障域要隔离”这个设计目标是普适的。
第三，把“全量回连”写进应急演练剧本。大多数团队的应急预案只演练“怎么修”，不演练“修好之后怎么放”。全网恢复时的终端回连洪峰，会冲击DHCP、认证、附着这些平时毫无压力的环节。演练里要加上：分几个批次放闸、每批次多大比例、911和语音的优先级怎么保证、限流阈值定在哪。恢复期的事故比原发事故更丢人，因为你在众目睽睽之下二次翻车。
第四，关键生命线要物理分离，网间协作要提前埋好。911这类业务，逻辑冗余是不够的——这次事故证明，当全网控制面雪崩时，逻辑上“独立”的子系统会跟着一起死。物理分离不是过度设计，是生命线的底线成本。同理，与互联对端的应急联络机制、切断判据、应急漫游安排，要事前写进协议并定期演练。这次Bell和Telus能救场，是因为恰好有人能在电话里把事情讲清楚；下次未必有这样的运气。
一次全国断网，起因只是一根跳线；代价是半天的国家停摆、5天的月费、18个月的整改承诺和一场持续数年的监管重构。对运维人来说，这个故事最冷的一层意思是：毁掉一张网的，从来不需要什么惊天动地的大事，只需要一个小到没人觉得值得走变更流程的动作。
本文由「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 等场景全覆盖。