**概述：** 2022年7月8日（周五）凌晨，加拿大最大运营商罗杰斯（Rogers Communications）核心网因一次维护变更引发的连锁反应全面瘫痪，约1200万用户的手机、宽带同时失联，全国借记卡支付、政府热线、部分911呼叫受波及，业务中断约19小时，被称为“加拿大现代史上最严重通信事故”。本文基于罗杰斯官方事后说明与Cloudflare的BGP观测数据，完整复盘这条“一条路由过滤规则压垮一张全国网”的故障链：变更何时埋雷、为何两天后才引爆、恢复为何拖了近一天、监管如何重锤整改，以及给一线运维人的六条硬启示。 ## 目录 - 一、周五凌晨，三分之一的加拿大人“下线” - 二、官方定调：一条过滤器，如何放倒一张全国网 - 三、恢复为什么拖了19个小时 - 四、911告急与监管重拳：六项整改承诺 - 五、写给运维人的六条硬启示 - 六、结语 --- ## 一、周五凌晨，三分之一的加拿大人“下线” 2022年7月8日，美东时间凌晨4点45分前后，罗杰斯的监控大屏开始疯狂报障。短短几十分钟内，这家占加拿大无线市场约三分之一的运营商，其移动网、家宽、企业专线几乎同时失联——不是某个省、某个地市，而是全国。 对普通用户来说，这是相当魔幻的一天： - **手机没信号**：罗杰斯及其子品牌Fido、chatr的约1200万用户，手机变成“仅限紧急呼叫”，连紧急呼叫在很多场景下也呼叫失败； - **宽带与固话全断**：家宽用户光猫上 dying gasp 都没有——因为上游IP核心整个趴了； - **全国支付停摆**：加拿大借记卡清算体系 Interac 及 e-Transfer 依赖底层网络，事故期间全国商家的借记卡POS、ATM取现大面积瘫痪，有慈善机构的捐款热线当场失血； - **政务与民生系统受创**：Service Canada 的电话服务中断，部分政府机构的联系渠道失效，甚至有依托罗杰斯专线的小型机构业务全面停摆； - **911告急**：加拿大广播电视及电信委员会（CRTC）事后确认，收到了大量紧急呼叫受阻的报告。罗杰斯当时称已尽力把紧急呼叫分流到其他运营商网络，但从用户投诉看，部分呼叫未能及时接通。 对电信人来说，这次事故最扎眼的一点是：**这不是无线侧的局部故障，而是承载网核心的“心脏骤停”**。无线、家宽、政企、支付通道全挂在同一张IP核心上，核心一倒，全业务归零。同年7月初 KDDI 刚发生过214小时级的全国断网，两周后罗杰斯用另一种姿势证明：核心网的单点脆性，是全行业命题。 事故时间线整理如下（时间均为美东时间，依据罗杰斯官方说明与当时媒体的公开报道）： | 时间 | 事件 | |---|---| | 7月6日（周三）凌晨 | 计划内维护窗口，核心网路由器执行过滤器（network filter）相关变更 | | 7月8日（周五）04:45前后 | 核心路由器过载崩溃，BGP路由大规模撤销，全国业务断崖式中断 | | 7月8日白天 | 全国支付、政务、911受波及；罗杰斯对外口径混乱，舆论发酵 | | 7月8日晚间 | 开始分批、限流恢复业务，同步清退“幽灵”废弃路由设备 | | 7月9日（周六）上午 | 移动与宽带业务基本恢复，全程约19小时；支付类业务恢复更晚 | | 7月12日 | 工业、科学和经济发展部（ISED）部长尚帕涅约谈CEO斯塔菲里 | | 7月22日 | 罗杰斯公开说明根因，并公布六项整改承诺 | ```mermaid timeline title 罗杰斯断网与整改时间线 7月6日周三凌晨 : 维护窗口执行过滤器变更 7月8日周五凌晨 : 核心路由器过载崩溃 : 全国业务中断 7月8日白天 : 支付与政务系统受创 : 911呼叫受阻 7月8日晚间 : 分批限流恢复 : 同步清退废弃设备 7月9日周六上午 : 业务基本恢复 : 核心中断约19小时 7月12日 : 部长约谈CEO : 政府强势介入 7月22日 : 官方说明根因 : 公布六项整改承诺 ``` ## 二、官方定调：一条过滤器，如何放倒一张全国网 事故半个月后，[罗杰斯官方发布的事故说明](https://about.rogers.com/news-2/)给出了根因，大意是：7月6日凌晨的维护窗口中，运维人员在核心网路由器上执行了一条**网络过滤器（network filter）相关变更**。这类过滤器的作用本来是约束路由信息的分发范围——你可以粗略理解为 BGP 里用来圈定“哪些路由该进、哪些路由该传”的策略。变更之后，设备开始通过**共享的处理平面**分发远超设计容量的路由信息，业务流量也被挤压到本不该承担这个量级的路径上，核心路由器相继自陷故障，BGP 会话中断、路由撤销，全国 IP 核心失联。 [Cloudflare 的工程师团队在事故当天的博客复盘](https://blog.cloudflare.com/rogers-outage-dns-bgp-and-the-fragility-of-the-internet/)从外部视角印证了这一过程：他们通过 [Cloudflare Radar 对 AS577（罗杰斯自治域）的观测](https://radar.cloudflare.com/as577)看到，事故发生后罗杰斯的 BGP 路由被大规模撤销，从全球互联网的视角看，这个 ASN“消失”了；其 DNS 解析服务不可达，随后路由是**分批、逐步**重新宣告的，与罗杰斯分阶段恢复业务的节奏吻合。 把这条故障链拆开，每一环都值得背下来： ```mermaid flowchart TD A["周三凌晨维护窗口"] --> B["核心路由器过滤器变更"] B --> C["路由分发范围失控"] C --> D["共享处理平面被路由更新灌爆"] D --> E["业务流量挤占设备能力"] E --> F["核心路由器相继自陷故障"] F --> G["BGP会话中断并撤路由"] G --> H["全国IP核心失联"] H --> I["无线、宽带、支付全面瘫痪"] ``` 有三个细节，是我作为干了十几年核心网的运维老兵认为最值得咀嚼的： **第一，变更与故障隔了整整两天。** 变更发生在周三凌晨，崩溃发生在周五凌晨。为什么？过滤器被改松后，异常的路由分发是渐进累积的，像血管里的斑块慢慢长，直到某个临界点把共享处理平面彻底压垮。这意味着传统“变更后观察两小时就收工”的窗口完全罩不住这类故障——**变更的“延时引信”效应**，会让变更管理系统和告警关联系统双双失灵：周五凌晨没有任何变更记录，谁会想到去查周三那条过滤器？ **第二，压垮骆驼的是“平面”，不是“容量”。】 平时我们讲容量规划，盯的是转发平面的带宽和包转发率。但这次挂掉的是路由协议处理、管理面消息这些“后台工作”所依赖的共享资源。控制面风暴（路由翻动、路由表暴涨）从来不走业务带宽的账，等你从流量曲线发现异常，设备已经先躺了。过载保护、路由更新限速、控制面与转发面的资源隔离，平时看着是“浪费”，出事时就是命。 **第三，DNS 成了次生灾害放大器。** 核心一断，解析服务不可达，即便个别链路侥幸存活，依赖域名的业务也无法自救。这再次验证了那条老经验：故障时刻，DNS 和认证系统永远是最后恢复、最先被骂的环节。 ## 三、恢复为什么拖了19个小时 按理说，路由器重启、路由重新收敛，撑死几个小时。罗杰斯为什么修了将近一天？根据其官方说明和行业复盘，至少有三层原因： **1. “幽灵设备”反复捣乱。** 网上挂着一批**已停用但从未物理下线**的废弃路由器。核心网出事后，这批设备也卷入异常的路由交互，反复重新加入、反复把刚稳定下来的网络搅乱。罗杰斯最终是**边清退废弃设备、边恢复业务**，双线作战，进度自然快不起来。这是全行业通病——裁撤网元时“配置里 shutdown 一下”就算完事，物理链路还挂在网里，平时是隐患，出事时就是击鼓传花的雷。 **2. 不敢一把梭重连。** 全国性核心网恢复，最忌讳“全量瞬时回连”：几千万终端同时发起附着、注册、认证，请求风暴会瞬间打爆刚爬起来的系统，二次坍塌。分区域、分批次、限流放量是唯一正确的姿势，代价就是时间。 **3. 业务系统冷启动的连环等待。** 网络通了之后，HSS/PCRF 这类签约与策略数据的加载、计费系统对账、支付通道的对端重新握手，每一步都有依赖顺序。用户视角的“恢复”，从来不等价于工程师视角的“路由收敛完成”。 还有一层是组织层面的：事故初期罗杰斯对外口径摇摆，先说“计划内维护”，后承认系统性故障，CNMF（加拿大网络安全中心）也介入排查供应链可疑因素——虽然最终定调为纯技术事故，但舆论信心的损失进一步放大了事件影响。**重大故障中，统一的信息出口和分级通报机制，与抢修本身同等重要。** ## 四、911告急与监管重拳：六项整改承诺 真正让这次事故写入加拿大监管史册的，是它在紧急通信上的脆性。美国 FCC 的网络中断报告制度要求运营商按规定上报重大断网，加拿大原本缺乏同等刚性的机制，这次事故直接推动了改变。 7月12日，加拿大创新、科学和经济发展部（ISED）部长尚帕涅约谈罗杰斯 CEO，随后罗杰斯在7月22日的公开函件中承诺六项整改，被媒体完整披露： | 整改承诺 | 直击的病灶 | |---|---| | 无线网与有线电视/宽带网做物理与逻辑分离 | 两大业务共用一张IP核心，核心一倒全业务归零 | | 清退已停用但仍联网的废弃路由设备 | “幽灵设备”在恢复期反复制造不稳定 | | 部署自动隔离机制，阻断异常路由扩散 | 过滤器变更引发路由风暴时无自动熔断 | | 立即增强911网络冗余 | 紧急呼叫与生产网耦合，断网即断命 | | 建设实验室环境，重大变更先仿真再上网 | 周三变更、周五引爆，变更缺乏故障预演 | | 支持建立全行业强制性的事故复盘框架 | 行业缺乏刚性的事后审查与共享机制 | 监管的重锤不止于罗杰斯。事后，贝尔、TELUS 与罗杰斯三家被要求就应急场景下的网间漫游互助达成正式协议——再发生类似事故时，用户的手机应能自动漫游到对方网络上；CRTC 也就电信网络可靠性启动了相关监管程序。换句话说，**这次事故把“运营商之间只竞争不互助”的行业默认规则，推向了监管强制的应急协作**。对用户来说最直接的获得感是：罗杰斯为个人和小企业用户减免了5天服务费，据当时外媒测算，连同业务损失，代价在1.5亿加元量级——而加拿大全国为此付出的隐性成本（商业停摆、无法刷卡、急救受阻），远不止这个数。 ## 五、写给运维人的六条硬启示 复盘不能只停留在“知道了根因”。落到日常运维，我认为有六条是可以直接搬回自己网络里的： **1. 策略类变更，按“高危变更”管理。** ACL、路由过滤器、重分发策略这类变更，影响面是“全网路由视野”，而不是单台设备。罗杰斯那条过滤器如果先在实验环境仿真、先灰度到边缘节点、变更后持续观察48小时以上，历史可能改写。凡是能改变路由策略的变更，一律按核心网割接的规格对待。 **2. 给控制面留“防波堤”。** 路由更新限速、会话认证、路由合法性校验、过载时的自动熔断，这些机制的价值只有在风暴来临时才体现。检查你的核心路由器：路由表容量阈值告警开了吗？BGP 更新风暴有自动抑制吗？管理面流量和控制面流量有没有资源隔离？ **3. 废弃设备必须物理摘除。** “不再转发流量但还连着线、还开着电源”的设备，等于在核心网里埋了不定时炸弹。建立网元退役的硬流程：下线 = 摘线 + 断电 + 资产核销，三步缺一不可。拿这次事故去审一遍你自己的资产台账，大概率能翻出几台“僵尸”。 **4. 紧急呼叫与生产网隔离，并做跨网双归。** 911/112 这类生命线业务，必须在承载、路由、供电多个维度与公网业务隔离，并具备向其他运营商网络迂回的能力。检验标准很朴素：把你的核心网想象成整体宕机，问一句——急救电话还能不能通？答不上来就是隐患。 **5. 重建“变更-故障”的时间关联能力。** 周三变更、周五引爆的事故形态，要求故障分析工具必须能拉出“过去72小时所有变更”做关联，而不是只看“最近4小时”。变更记录的生命周期、告警与变更的自动关联，平时不起眼，大故障时决定排障方向对不对。 **6. 做一次“社会级单点依赖”审计。** 全国借记卡支付挂在一个运营商的网络上，政府热线、部分医疗机构也一样——这是罗杰斯事故暴露的比技术更深的问题：**关键社会服务对单一运营商的单点依赖**。运营商侧要做网络级容灾，行业侧要落实应急漫游互助，而依赖运营商的企业侧，至少应评估“主用运营商全瘫”场景下的降级预案。 ## 六、结语 罗杰斯断网的根因清单里，没有黑客、没有天灾、没有硬件缺陷，只有一条再普通不过的维护变更和一批理应早已消失的废弃设备。这正是它值得每一个运维人反复咀嚼的原因：**把一张国家级网络放倒的，往往不是惊天动地的攻击，而是日常流程里每一个“这次应该没事”**。KDDI 的拥塞、Optus 的防火墙、罗杰斯的过滤器，三次事故三种诱因，但底层的教训高度一致——核心网的韧性，是设计出来的、演练出来的、清退出来的，唯独不是希望出来的。 下一次凌晨的维护窗口，当你即将敲下那条过滤器命令时，不妨想想渥太华那个周五清晨：1200万人看着手机屏幕上一格信号都没有。 --- ## 参考来源 1. [Rogers outage: DNS, BGP and the fragility of the Internet — Cloudflare Blog（2022-07-08）](https://blog.cloudflare.com/rogers-outage-dns-bgp-and-the-fragility-of-the-internet/) — Cloudflare 工程师从 BGP 与 DNS 外部观测视角对罗杰斯断网的实时复盘，本文路由撤销过程的主要佐证来源 2. [Cloudflare Radar — AS577（Rogers Communications）](https://radar.cloudflare.com/as577) — 罗杰斯自治域的公开路由观测数据页，可查证事故期间路由宣告变化 3. [2022 Rogers Communications outage — Wikipedia](https://en.wikipedia.org/wiki/2022_Rogers_Communications_outage) — 事故全过程的百科式梳理，含时间线、用户规模与补偿措施的公开报道汇总 4. [Rogers 官方新闻室（about.rogers.com）](https://about.rogers.com/news-2/) — 罗杰斯断网期间多轮网络更新公告及7月22日根因说明与整改承诺的发布渠道 *注：文中根因描述依据罗杰斯2022年7月22日官方说明，外部观测数据引自 Cloudflare 博客；补偿金额等为当时外媒公开报道口径，具体财务数字以罗杰斯财报为准。* --- > 本文由「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 等场景全覆盖。