**概述**：2022年7月8日清晨，加拿大最大运营商之一Rogers突发全国性断网，超过1200万用户的手机、家宽同时失联，全国借记卡支付和ATM瘫痪近一个工作日，部分911急救呼叫失败。CRTC（加拿大广播电视及电信委员会）事后发布了一份罕见详尽的官方技术报告（Telecom Decision CRTC 2022-292），把根因、扩散路径、恢复过程中的每一个坑都摆在了台面上。本文以这份官方报告为主线，结合Cloudflare工程师的BGP数据复盘，拆解一次深夜核心网维护是如何清空整张路由表、又如何在恢复期被注册洪峰二次击穿的。对干了十几年核心网的人来说，这份报告几乎是一份免费的全景教学案例。 ## 目录 - 一、那个早晨，加拿大被按下暂停键 - 二、官方报告的时间线：从清晨4:45说起 - 三、根因解剖：一次维护如何清空整张路由表 - 四、二次灾害：数百万终端的重注册洪峰 - 五、病灶清单：官方报告点名的问题 - 六、处置与整改：监管的六个月限期 - 七、写给核心网运维人的五条启示 - 结语 ## 一、那个早晨，加拿大被按下暂停键 2022年7月8日，加东时间清晨4点45分前后，Rogers网络里的核心路由器开始成片失联。天亮之后，加拿大人才意识到发生了什么：手机没有信号、家里没有宽带、商户的POS机刷不了卡、ATM吐不出钱。 Rogers是加拿大三巨头之一，无线用户超过1100万，家宽用户数百万，合计受影响用户据CRTC报告口径超过1200万。更麻烦的是，Rogers不只是“一家运营商”——加拿大全国性的借记卡清算网络Interac，大量银行把它作为主用传输承载在Rogers网上。Rogers一倒，全国超市、加油站、便利店瞬间退回到现金时代，很多店面直接挂出“只收现金”或干脆歇业。加拿大边境服务局的部分口岸系统、一些警局的通信、政府的部分服务热线也受到波及。 当天是周五。加拿大人在社交媒体上的第一反应不是愤怒，而是错愕——“一个发达国家，怎么会因为一家运营商的故障，全国支付停摆？”这种错愕，恰恰说明了问题：单张电信网的故障，顺着支付清算这条线，穿透到了整个国家的经济毛细血管。这也是CRTC后来把这份报告写得如此不留情面的根本原因。 作为在核心网一线干过多年割接的人，我看到这条新闻时的第一反应是：凌晨维护、全国全断、恢复拖了一整天——这三个特征凑在一起，几乎可以断定是核心网层面的全局性故障，而不是某个区域的无线侧问题。CRTC后来的报告证实了这个判断，而且细节比想象中更触目惊心。 ## 二、官方报告的时间线：从清晨4:45说起 先把官方口径的时间线整理成表（时间为加东时间，依据CRTC报告与当时媒体的公开报道整理，不同业务恢复时间有差异）： | 时间 | 事件 | | --- | --- | | 7月7日夜间 | Rogers按计划在核心IP网开展维护变更，工作持续到深夜 | | 7月8日 凌晨4:45前后 | 变更引发核心路由器异常离线，路由撤销向全网扩散，断网开始 | | 清晨6点起 | 用户大规模发现手机无服务、家宽断网，社交平台开始刷屏 | | 上午 | 全国借记卡交易、ATM大面积失灵，商户被迫停业或只收现金；Rogers内部监控与管理系统同样失联，故障定位极其困难 | | 白天 | Rogers尝试逐段恢复，但网络回通后注册请求洪峰反复压垮注册系统，被迫限流放行 | | 傍晚 | 中断十余小时后，借记卡与ATM功能率先恢复，无线业务开始分批回归 | | 7月9日 上午 | 网络整体恢复，部分用户的长尾问题延续到当天下午 | | 随后数周 | 联邦政府与CRTC介入，启动正式调查，8月CRTC要求全国大型运营商提交网络韧性报告 | 有两个细节值得单独说。第一，Rogers自己的“眼睛”也瞎了：内部监控、工单、通信工具大量运行在自家网络上，断网之后运维团队一度只能靠带外手段和“人肉”方式摸排，这大大拖慢了定位速度。第二，Rogers在事故初期对外表示911紧急呼叫不受影响，随后不得不承认部分911呼叫确实失败或受影响——这个细节后来被CRTC写进了报告，也成为整改的核心条款之一。 ## 三、根因解剖：一次维护如何清空整张路由表 CRTC报告给出的根因链条并不复杂，复杂的是它为什么能扩散到全国。 故障起点是7月7日深夜核心IP网的维护变更。变更过程中，部分核心网络设备异常离线，设备上承载的路由信息随之丢失。在正常的分域架构里，这种丢失会被限制在一个故障域内；但CRTC在调查中发现，Rogers的全国IP核心网是一张高度集中、缺乏分域隔离的网络——不同网络区域之间没有设置有效的隔离手段，路由撤销信息沿着BGP会话层层向外传播，最终把整张核心网的路由表“清空”。 用一个机房里常见的比喻：这就像一栋大楼里没有防火分区，某个楼层起火后，浓烟顺着贯穿的通风管道灌满全楼。路由撤销的传播就是那股浓烟——每一台收到撤销的路由器都忠实地转发给邻居，几秒钟内，全国的核心网安静了下来。 Cloudflare的工程师团队（bgp.tools创始人Andree Toonk等人）事后从全球BGP观测数据的角度做了独立复盘：断网开始后，Rogers向全球互联网宣告的数万个路由前缀在极短时间内全部消失，从全球路由表看，这家运营商像被从互联网上“整体拔掉”了一样；断网期间，加拿大其他运营商（如Telus、Cogeco等）承接了溢出的流量，而Rogers自身递归DNS失效也把用户的DNS查询推向了公共解析服务。这份第三方数据与CRTC报告的结论互相印证：不是“部分区域劣化”，而是核心网整体静默。 下面这张图把整个连锁反应串起来： ```mermaid flowchart TD A["7月7日深夜
核心IP网维护窗口"] --> B["设备变更异常
部分核心路由器离线"] B --> C["路由信息丢失
BGP撤销全网扩散"] C --> D["核心网无分域隔离
撤销一路畅通"] D --> E["全国IP核心静默
无线与家宽全断"] E --> F["凌晨4点45分
全国性断网开始"] F --> G["网络逐段回通
终端并发重连"] G --> H["注册系统过载
反复崩溃"] H --> I["限流放行
分批恢复注册"] I --> J["周五晚业务回归
周六基本收尾"] ``` 这里要强调一个对一线工程师最有冲击力的结论：**把全网放倒的不是变更本身，而是变更发生在一块没有隔离的核心板上**。同样的设备异常，如果发生在被防火墙和策略隔离出一个故障域里，最坏结果是一批区域用户劣化，而不是一个国家的支付系统停摆。 ## 四、二次灾害：数百万终端的重注册洪峰 如果说根因是“架构问题”，那么恢复阶段的灾难则纯粹是“容量问题”，而且这个环节把事故从15小时拖成了接近一天。 机制是这样的：IP核心网静默期间，数百万台手机、CPE失去了与网络的注册上下文。当传输恢复的那一刻，这些终端带着各自的重试定时器同时发起重新注册——对核心网注册系统（HSS/HLR这一层的用户数据与鉴权体系）来说，这相当于平时几小时的话务在几秒钟内砸下来。注册系统过载崩溃，重启，然后面对的是积压了更多、定时器更密集的新一轮洪峰，再次崩溃。Rogers最终只能采取限流放行的策略：控制每秒允许注册的终端数量，让网络像泄洪一样分批接纳用户——这也意味着越靠后的用户，等待恢复的时间越长。 ```mermaid sequenceDiagram participant U as 终端 participant N as 接入网 participant C as 核心注册系统 U->>N: 传输恢复，终端并发重连 N->>C: 注册请求洪峰 C-->>C: 过载崩溃重启 Note over N,C: 重启再遇洪峰，循环恶化 N->>C: 限流后分批放行 C-->>U: 注册成功，业务恢复 ``` 干过移动核心网的人对这个模式都不陌生。KDDI在2022年7月初的事故、Optus在2023年11月的事故里，“大规模断网—并发重注册—注册系统连环崩溃—限流拖长恢复”几乎是同一个剧本的三次重演。区别只在于触发点：KDDI是割接中用户数据损坏，Optus是路由域配置问题，Rogers是路由撤销全网扩散。三次事故共同指向同一个短板：**运营商对“恢复时刻”的容量规划，远不如对“正常运行时刻”那么重视**。买设备冗余的时候，算的是峰值话务模型，从来没人算过“全网终端同时重注册”的话务模型——因为它在正常运行里永远不会出现，只在最糟糕的那一天出现。 ## 五、病灶清单：官方报告点名的问题 CRTC报告最有价值的地方，是它没有停在“根因是配置变更”这种层面，而是把系统性病灶一条条列了出来。归纳起来有这么几层： **第一层：核心网没有分域隔离。**这是最核心的发现。报告明确指出，Rogers的IP核心网各区域之间缺乏隔离手段，单点异常可以不受阻拦地扩散到全网。讽刺的是，这类隔离改造在行业内属于“人人都知道该做、但排期永远排不上优先级”的工程——因为它不直接产生收入，不出故障时没人看得见价值。 **第二层：注册系统缺乏应对洪峰的冗余。**恢复正常话务的容量是够的，但应对“全网重注册风暴”的容量严重不足，且没有自动的过载保护与逐段放行机制，导致恢复过程被洪峰反复打断。 **第三层：管理与监控面承载在业务网上。**Rogers的内部监控、管理系统大量依赖自家网络，事故中运维团队“自瞎”，定位和指挥都受阻。带外管理（Out-of-Band）这条机房铁律，在运营商级网络里同样成立。 **第四层：关键社会职能单点依赖一家运营商。**全国借记卡清算把主用路由压在一张商用电信网上，911紧急呼叫的第三方保障路径不落实。事故证明，这些“社会级单点”不能靠SLA承诺来兜底，必须有制度化的多运营商冗余。 把病灶和后来的整改要求对照着看更清楚（依据CRTC通报，具体落实以官方后续文件为准）： | 官方报告指出的病灶 | 对应整改方向（限期内落实并报告） | | --- | --- | | 核心网各区域缺乏隔离 | 以防火墙与策略手段实现核心网分域隔离 | | 注册系统无洪峰冗余 | 建设冗余容量与过载保护、恢复限流预案 | | 911依赖本网、部分呼叫失败 | 与第三方运营商建立紧急呼叫连续性保障安排 | | 监控/管理系统承载于本网 | 强化带外管理与独立的故障监测能力 | | 支付清算单点依赖 | 监管推动金融侧审视多运营商冗余（加拿大银行监管机构亦要求银行自查电信依赖） | ## 六、处置与整改：监管的六个月限期 事故之后的处置分三条线展开。 **用户补偿这条线最快。**Rogers宣布自动向受影响用户提供5天服务费补偿，据Rogers方面测算总额约1.5亿加元。值得注意的是补偿是“自动执行”的——不需要用户申请，这在加拿大运营商史上并不多见，某种程度上反映了事故的严重程度和企业形象止损的迫切性。 **监管这条线最重。**CRTC在2022年10月12日发布正式调查报告（Telecom Decision CRTC 2022-292），除了公开技术细节，还要求Rogers在6个月内落实上述整改并提交报告，包括核心网隔离、911第三方保障安排等硬性条款。同时，CRTC把整改要求扩展到了全行业：要求全国大型运营商限期提交各自网络的韧性评估报告。换句话说，Rogers一次事故，变成了全体加拿大运营商的一次“强制体检”。监管机构还要求Rogers高管出席公开质询，就事故与整改接受议员和公众的追问。 **资本与产业这条线最深远。**事故发生时，Rogers正在推进对Shaw的并购审批，全国断网引发的舆论风暴直接改变了审批的政治环境。联邦政府最终为放行附加了严苛条件，据当时公开报道，包括若未履行网络投资等承诺将面临最高10亿加元的罚则。一次断网事故成为并购审批的筹码，这在电信行业史上也是极具标志性的案例——**网络质量第一次以如此直接的方式，变成了一家公司资本运作的资产负债表科目**。 ## 七、写给核心网运维人的五条启示 复盘这场事故，结合我自己这些年做割接和故障复盘的经验，我认为有五条是真正值得带回自己网络里的： **第一，变更评审要算“最大撤销域”，而不是只算“影响网元清单”。**每次割接前我们都会填影响范围表，但多数模板问的是“动哪些设备”，很少问“这次变更最坏能让多少路由被撤销、多少注册上下文丢失、它们能扩散到哪里”。把“爆炸半径”作为变更评审的一等公民，是这次事故最直接的教训。 **第二，故障域隔离是买不来的保单，只能靠设计。**分域隔离的价值平时是零，出事时是全部。如果你的核心网还存在“一个平面打穿全网”的路径，那么Rogers的今天就是理论上你的明天。标准允许多种实现方式，具体架构以各厂家官方文档为准，但“控制面故障域要有边界”这件事没有商量余地。 **第三，给“恢复时刻”单独做一份容量规划。**重注册洪峰、信令风暴这类话务只在故障恢复时出现，却是决定事故时长的主要变量。预案里应明确：恢复时的限流策略、放行顺序（先急救与关键行业、后普通用户）、以及限流期间的对外通报口径。Rogers被迫现场发明限流方案，说明这套东西不能等出事再想。 **第四，管理面必须带外，监控必须第三方。**监控跑在业务网上，等于让保险丝和电线共用一根导体。哪怕预算只够做一件事，也应该先做带外管理通道和一个独立于本网的拨测体系——这次事故里，它直接决定了运维团队是“盲人摸象”还是“看着监控降级运行”。 **第五，关键业务的多运营商冗余要写成制度，而不是写成SLA。**Interac和911的教训是：承载“社会级职能”的业务，主备路由必须落在物理上独立的运营商网络上，并且要定期演练。靠商务合同里的SLA条款兜底，在真正的全国性故障面前一文不值。 ## 结语 四年过去，Rogers断网依然是核心网架构课上最好的反面教材——不是因为它的技术有多特殊，而是因为CRTC把一份足够详尽的官方技术报告摆在了阳光下，让全球同行都能免费上一课。对一线工程师来说，这类公开复盘的含金量远高于任何架构白皮书：它告诉你理论上的“最坏情况”，在现实里真的会发生，而且会发生得比你想的更连贯、更彻底。下一次在你签字确认那个深夜的割接方案之前，不妨先问自己一个问题：如果这次变更清空了整张路由表，我的网络里，有什么东西能拦住它？ ## 参考来源 1. [Telecom Decision CRTC 2022-292 — Rogers 2022年7月8日断网官方调查报告](https://crtc.gc.ca/eng/decisions/2022/2022-292.htm) — 加拿大监管机构CRTC发布的正式调查决定，本文时间线、根因认定与整改要求的权威依据 2. [Understanding how the Rogers outage impacted Canadian Internet — Cloudflare Blog](https://blog.cloudflare.com/understanding-how-the-rogers-outage-impacted-canadian-internet/) — Cloudflare工程师Andree Toonk团队基于全球BGP观测数据的独立技术复盘 3. [2022 Rogers outage — Wikipedia](https://en.wikipedia.org/wiki/2022_Rogers_outage) — 事故过程、影响面与后续处置的综合梳理，用于交叉核对时间线 4. [Rogers Newsroom](https://about.rogers.com/news-ideas/) — Rogers官方新闻中心，事故期间的用户补偿与整改承诺通报汇总 --- > 本文由「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 等场景全覆盖。