## 概述 2022年7月8日凌晨4点45分前后，加拿大最大移动运营商Rogers在一次例行网络维护中，因为一根跳线让核心分布式路由器“失明”，随后引发路由风暴，全国性断网超过12小时：上千万无线用户失联、全国银行借记卡刷卡瘫痪、多地911报警电话打不出去。本文以[Rogers官方新闻室的7月系列声明](https://about.rogers.com/news-ideas/)、[CRTC与ISED的2022-232号联合审查公告](https://crtc.gc.ca/eng/archive/2022/2022-232.htm)以及[Wikipedia事件条目](https://en.wikipedia.org/wiki/2022_Rogers_Communications_outage)汇编的多方报道为锚，完整复盘：故障是怎么滚起来的、为什么最后是两家对手公司救的场、恢复期为什么又险些翻车，以及它给核心网运维留下的四条硬启示。 ## 目录 - 一、断网那天，加拿大失去了什么 - 二、时间线：一根跳线引发的24小时 - 三、根因解剖：路由风暴是怎么滚起来的 - 四、救场的是对手：切断私有互联 - 五、第二波故障：恢复期的回连风暴 - 六、追责与整改：911分离与联合审查 - 七、给运维人的四条硬启示 ## 一、断网那天，加拿大失去了什么 先说清楚Rogers在加拿大是什么体量。加拿大人口不到4000万，电信市场高度集中，Bell、Rogers、Telus三家瓜分了绝大部分移动用户，其中Rogers无线用户超过1100万，约占全国移动市场三成（财报公开口径），家庭宽带在多个人口大省市占第一。这不是“某一家运营商停摆”，而是“全国每三个人里有一个人的手机没信号”。 更麻烦的是，现代经济对电信网的依赖远不止打电话。当天早上，加拿大人发现的是一整条连锁反应： - **911打不出去。**多地警方连夜发通告，提醒市民紧急呼叫可能无法接通，部分辖区建议改走非紧急热线或就近求助——对于一个发达国家，这是最刺眼的一条。 - **全国刷卡瘫痪。**加拿大人日常用的Interac借记卡交易网络，部分链路运行在Rogers的电路上，断网后商场POS机、ATM大面积无法交易，影响的是全国所有银行的客户，而不只是Rogers自己的用户。 - **政府与边检停摆。**边境服务、就业保险、税务等大量依赖电话与在线系统的政务服务中断，恰逢周五，影响被放大。 - **互联网“塌了四分之一”。**Cloudflare Radar当日的监测曲线显示，加拿大全国互联网流量出现断崖式下跌——一家运营商掉线，一个发达国家的流量曲线直接削掉一大块，这在全球范围内都极其罕见。 还有一个背景必须交代：事发时Rogers正在推进对第四大运营商Shaw约260亿加元（含债务口径）的收购。一场全国断网，恰好砸在这个“市场已经太集中”的敏感话题上，这决定了后面追责的烈度。 ## 二、时间线：一根跳线引发的24小时 下表是按多方公开信息（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都在同一时刻疯狂重算、互相冲击控制卡时，网络不是“慢下来了”，而是集体失去了“我是谁、我在哪、邻居是谁”的记忆。这类共模故障的可怕之处在于：冗余设计全部失效——你有一百台备份路由器，但它们跑着同样的软件、执行着同样的收敛逻辑，于是一百台一起倒。 ```mermaid 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当天的恢复之所以拖得很长，与这波回连洪峰有直接关系。这也是为什么老运维常说：割接预案写到“业务恢复”还没写完，要写到“恢复稳定”才算完。 ## 六、追责与整改：911分离与联合审查 事故的收尾动作，比事故本身更值得细看。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个月的整改承诺和一场持续数年的监管重构。对运维人来说，这个故事最冷的一层意思是：**毁掉一张网的，从来不需要什么惊天动地的大事，只需要一个小到没人觉得值得走变更流程的动作。** ## 参考来源 1. [Rogers News & Ideas 官方新闻室](https://about.rogers.com/news-ideas/) — 2022年7月8日、9日故障通报及7月22日CEO声明（初步根因、5天补偿、18个月911物理分离承诺）均发布于此，为本文官方口径主轴。 2. [CRTC 2022-232：CRTC与ISED对Rogers断网的联合审查公告](https://crtc.gc.ca/eng/archive/2022/2022-232.htm) — 监管侧审查范围与后续整改议程的官方入口，站内可检索 Rogers outage review 系列文件。 3. [Wikipedia：2022 Rogers Communications outage](https://en.wikipedia.org/wiki/2022_Rogers_Communications_outage) — 事件时间线、影响面与多方报道汇编，含Bell/Telus切断私有互联等细节的媒体出处。 4. [Cloudflare Radar](https://radar.cloudflare.com/) — 断网当日加拿大全国流量骤降的第三方监测数据来源。 5. [CERT/CC Vulnerability Notes](https://www.kb.cert.org/vuls/) — 恢复期大规模终端回连风暴的技术分析入口。 --- > 本文由「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 等场景全覆盖。