一条ACL过滤器放倒全国网：罗杰斯断网26小时完整复盘

概述

2022年7月8日凌晨4:43（美东时间），加拿大运营商Rogers的一名工程师在IP承载网割接中删除了分布路由器上的一条ACL策略过滤器。仅仅15分钟后，全部核心路由器被路由信息“淹死”，加拿大史上最大断网事故爆发：超过1200万个人和企业用户的移动、固网、911报警、银联卡支付（Interac）服务同时中断，全业务恢复耗时26小时17分。2024年公开的CRTC委托Xona Partners评估报告，首次完整披露了从触发、定位到恢复的全过程。本文回答三个问题：一条配置如何垮掉一个全国性Tier 1网络？为什么根因定位花了约14个小时？四年过去，这次事故给全行业的整改清单兑现了多少？

一、事故经过：一次“清理配置”引发的塌方

Rogers的无线网（2G/3G/4G/5G）和固网（DOCSIS cable与光纤）共享一张融合IP核心网，这是全球Tier 1运营商的常见架构。事故前几周，Rogers正在执行一个七阶段IP核心网升级工程，出事的正是第六阶段：为了完成升级，需要在分布路由器上删除一条ACL策略过滤器，目的是“清理配置文件”。

时间线如下（均为美东时间EDT，依据CRTC/Xona报告附录1）：

受影响面覆盖Rogers自有品牌（Rogers、Fido、Chatr）全部移动和宽带用户，以及依靠其网络的部分转售ISP、漫游伙伴、联邦/省/市三级政府、医院、能源交通企业和Interac金融清算网络——刷卡、e-转账在全加拿大范围内大面积瘫痪。

flowchart TD
    A["第六阶段割接：删除分布路由器ACL过滤器"] -->|触发| B["云端DNS地址被允许直接注入OSPF"]
    B --> C["BGP全表重分布进OSPF"]
    C --> D["海量LSA洪泛至核心层"]
    D --> E["核心路由器CPU与内存耗尽"]
    E --> F["核心路由器集体宕机，全网无路由"]
    F --> G["移动、固网、911、公共预警全断"]
    F --> H["网管网依附生产网一起瘫痪"]
    H --> I["只能派员赴站点现场排障，根因定位耗时约14小时"]
    F --> J["恢复期千万终端集中重连"]
    J --> K["对MME限流，防范信令风暴"]

二、根因：BGP全表倒灌OSPF，核心路由器被“撑死”

这是本次事故最值得IP承载网工程师咀嚼的部分。Rogers核心网内部用OSPF/IS-IS作为IGP，对外用BGP与其他AS交换路由。那条被删除的ACL过滤器，本来承担的职责正是阻止BGP路由重分布进OSPF。过滤器一删，配置模板的默认行为是允许把互联网BGP全表（Rogers正常情况下对外宣告约970条IPv4/IPv6前缀，但学习到的全表规模远大于此）重分布进OSPF——OSPF作为链路状态协议，瞬间被海量LSA灌爆，核心路由器CPU和内存耗尽，几分钟内全部宕机。

这里有一个广泛流传的误读需要纠正。事故初期舆论普遍归因于“BGP路由被撤销”，Kentik的深度分析对此明确证伪：

• 正常情况下AS812对外宣告约970条前缀，故障期间数百条分批撤销（08:44、08:50、08:54、08:59、09:10、09:25 UTC分多批发生），但始终有约240条IPv4和120条IPv6路由在全局路由表中存活；
• 这些仍然存活的路由却几乎不承载任何流量，说明问题不在外部可达性（BGP），而在网络内部（IGP层面）已经瘫痪——BGP撤销只是症状，不是病因；
• 少量流量经Bell、Telus、Beanfield等竞争对手网络绕行存活，而无线用户“手机无信号”也印证了故障深入到移动核心网依赖的内部路由。

Kentik的这句话值得写在每张割接卡上：“如果你错误地命令路由器撤销BGP路由，而路由器照做了，那不是BGP的错。”

更致命的是防护缺失。Xona报告指出，行业针对BGP策略错误早已形成成熟最佳实践：核心路由器配置过载保护上限、限制分布路由器注入OSPF的路由数量、对BGP重分布策略命令做人工+自动双重审计、支持配置自动回滚。事故前Rogers的核心路由器没有配置任何路由过载保护——事后整改的第一条，就是给核心路由器加上BGP→OSPF重分布条数上限和OSPF数据库条目上限。两条配置，本可拦住这场灾难。

三、放大器：为什么一条配置能垮掉全国网

单一配置错误在成熟网络里本应被层层拦截。复盘这份报告，至少有五个系统性的“放大器”把一次局部变更变成了全国灾难：

1. 风险等级被算法降级。 七阶段工程最初评估为“高风险”，但因为前五个阶段都顺利完成，风险算法按“历史成功率”把第六阶段自动降为“低风险”——于是免除了额外审批和实验室测试。而行业标准恰恰要求：涉及BGP策略的配置变更必须高风险对待、必须先做实验室验证。用“上次没出事”为“这次降门槛”背书，是变更管理里最隐蔽的陷阱。

2. 网管网依附生产网。 Rogers的网管网络依赖自家IP核心网承载，核心网一瘫，工程师远程登录全部失效，NOC和关键站点也没有第三方运营商的备份专线，只能派人开车去现场登车排障，大幅拉长了恢复时间。

3. 内部通信全军覆没。 员工之间沟通依赖自家手机和宽带，网络一断，应急指挥体系失联，只能从竞争对手那里搞来他网SIM卡、派人送到各个站点——事故发生约5小时后才有足够数量的他网卡到位。事故发生47分钟后值班经理才拉起电话会议。

4. 同一割接窗口塞了多项变更。 当天维护窗口内执行了多项配置变更，故障发生后工程师无法判断该回滚哪张变更单，最初把排查焦点错误锁定在核心路由器上，而不是触发源分布路由器。约14小时后才定位到根因，期间连宕机路由器的错误日志都拿不到。

5. 融合核心网的爆炸半径。 无线+固线共用一张IP核心，日常是成本最优解，故障时就是全国单点。报告认为这不算“设计缺陷”而是行业普遍的设计取舍，但 consequence 是残酷的：核心网一断，LTE/5G移动核心（MME/HSS）完全失去承载，无线侧RAN虽活着但手机全部脱网，2G/3G电路域反而因IP核心间歇性恢复而接通了一部分911呼叫。911体系与公网共用路径，没有独立的应急旁路。报告还澄清，此次故障与多厂商设备互操作性无关；标准允许多种实现，具体行为以各厂家官方文档为准。

四、恢复：14小时定位后的“教科书式”回血

定位到根因后，Rogers的恢复动作反而可圈可点。核心动作是对MME做限流，让千万台终端分批、渐进式地重新注册入网——这是Rogers从2021年4月一次故障中换来的教训：网络恢复瞬间，海量终端并发附着/重注册会触发信令风暴，把刚爬起来的核心网再次打瘫。依靠预先限流，7月8日夜间起业务分区域渐进恢复，深夜恢复移动优先（Rogers无线用户超过1000万，优先恢复是为了让最多的人能打通911），7月9日07:00全国业务基本恢复，恢复全程未再发生二次雪崩。

外部通信同样狼狈：首次客户通告发生在故障后4小时11分（Twitter），通知911网络提供商用了3小时56分，通知监管和预警体系用了6小时36分——而事后发布的报告特意对比：美国FCC在2022年11月的911可靠性新规中，已要求故障发现后30分钟内必须通知911特殊设施部门。整个过程Rogers甚至没有主动告知公众“断网期间如何打通911”（例如拔出SIM卡搜索他网）。

五、整改清单与监管结论：26亿加元买来的教训

事故后Rogers的整改，Xona报告逐项给了评估，总体结论是“令人满意（satisfactory）”，同时明确定性：这不是架构设计缺陷，而是“配置错误+流程失效”的组合。关键动作包括：

行业层面，2022年9月加拿大12家运营商在CSTAC框架下签署《电信可靠性谅解备忘录》，约定应急漫游、互相支援和重大故障通报机制；3GPP从R17起也把灾难漫游（disaster roaming）纳入标准。但Xona报告泼了冷水：应急漫游协议在“RAN活着、核心网瘫了”这种场景下，手机能否自动搜索并注册到他网完成911呼叫，至今缺少端到端的实测验证——协议签了不等于能用。

另一个耐人寻味的细节：Rogers为2021年4月那次故障做过详尽的根因分析报告，整改也确实加固了移动网——但同样的流程改进没有延伸到IP核心网，一年后在同一类问题上栽了更大的跟头。2026年8月仍有行业媒体在讨论，这次事故如何让“IP核心网路由管控”成为运营商问责的固定科目。

六、给网络工程师的七条可落地教训

1. 任何BGP↔IGP重分布都是高危操作，必须过载保护上限（如OSPF外部LSA/前缀数量上限）兜底，不允许“裸奔”上生产网。
2. 警惕“低风险”降级逻辑：变更风险评估看的是变更内容的固有风险，不是执行者的历史成功率。路由策略类变更一律走最高审批+实验室验证。
3. 单窗口多变更等于事故后无法回滚：一个维护窗口尽量只做一张变更单，回滚预案要能一键回退到唯一基线。
4. 网管网必须物理/逻辑独立于生产网，NOC和关键站点必须有他网备份链路，否则故障时你会连自己的设备都摸不到。
5. 给核心岗配发他网SIM卡并演练：沟通中断的时间，就是故障时长被拉长的时间。
6. 恢复比故障更需要设计：MME限流、分区域渐进放号、告警分级抑制，都要在故障前写进预案并演练过。
7. 911/应急呼叫路径要有独立生命线：核对自家网络在“核心网瘫、无线活”场景下，终端能否自动漫游到他网完成紧急呼叫——3GPP R17+的灾难漫游标准值得对齐。

结论

罗杰斯断网的直接肇因是一条ACL过滤器的删除，但真正压垮全国网的，是被算法降级的风险评估、依附生产网的网管系统、失联的应急通信和缺失的过载保护。对一线工程师而言，这起事故最有价值的启示恰恰是它的“平凡”：没有天灾、没有黑客、没有硬件批量故障，只有一个看似无害的配置清理动作，落在了一张没有防御纵深、没有带外生命线的网络上。把过载保护、独立网管网、他网备份链路、应急漫游演练这四件事做实，成本远低于2.61亿加元的核心网分离——但必须在下一次凌晨4:43的割接之前。

参考来源

1. Assessment of Rogers Networks for Resiliency and Reliability Following the 8 July 2022 Outage（CRTC委托Xona Partners评估报告） — 事故时间线、根因、整改措施的一手权威来源
2. A deeper dive into the Rogers outage（Kentik Blog） — 基于NetFlow与BGP数据证实“BGP撤销是症状非病因”
3. Human error caused 2022 Rogers outage, system deficiencies made it worse（CBC News） — 2024年报告发布时的独立新闻报道
4. Rogers July 2022 Outage Assessment Report（Xona Partners完整版PDF，加拿大政府出版库） — 报告正式出版版本
5. Rogers' 2022 outage made IP-core route controls an accountability（BTW Media, 2026-08） — 事故四年后行业对IP核心网路由管控问责的延续讨论

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