# 一条ACL过滤器的代价：罗杰斯“7·8”断网26小时全复盘 ## 概述 2022年7月8日凌晨，加拿大运营商罗杰斯（Rogers）的一名工程师在例行升级中删除了一条路由配置过滤器，15分钟内全国核心路由器被“路由洪水”压垮，超过1200万用户的手机、宽带、911报警电话和公共警报同时失灵，直到次日上午才基本恢复，全程26小时以上。本文以加拿大监管机构CRTC委托Xona Partners出具的官方评估报告为主轴（2024年公开），逐段拆解时间线、根因链、为何一修就是26小时、影响面有多大、整改花了多少钱，最后提炼出九条任何运营商网管中心都该贴在墙上的硬经验。 ## 目录 - 一、事故速览：一张表看懂加拿大史上最大断网 - 二、26小时时间线：每一步都慢在了哪里 - 三、根因拆解：一条过滤器删除引发的雪崩 - 四、为什么修了26个小时：故障的“次生灾害” - 五、影响面：倒下的不只是手机信号 - 六、处置与整改：2.61亿美元买来的教训 - 七、给运维人的九条硬经验 - 八、写在2026年：这起事故为什么还没过时 - 参考来源 ## 一、事故速览：一张表看懂加拿大史上最大断网 | 项目 | 内容 | | --- | --- | | 事发时间 | 2022年7月8日4:58（美东时间，触发点为4:43） | | 恢复时间 | 7月9日7:00起逐步恢复，全程26小时以上 | | 故障位置 | IP核心网（核心路由器全数宕机） | | 影响用户 | 超过1200万个人与企业用户，含Fido、Chatr子品牌及批发客户 | | 波及业务 | 无线、有线宽带、固话、政企专线、911报警、公共警报（NAAD系统） | | 直接根因 | 分发路由器误删ACL策略过滤器，BGP全表重分发进OSPF，压垮核心路由器 | | 深层根因 | 无过载保护＋变更风控降级＋管理网依赖生产网 | | 整改投入 | 无线/固网核心网分离2.61亿加元，三年网络投资111.66亿加元 | 先说清楚这份报告的分量：它不是运营商自己的公关稿，而是CRTC在事故发生两年多后，委托独立工程咨询公司Xona Partners对罗杰斯网络架构、变更管理、故障管理三个维度做的全面技术评估，2024年7月发布摘要、2024年10月至11月放出脱敏全文。报告中设备商名称被脱敏，只说明分发层与核心层路由器来自不同主流厂商，并明确指出多厂商组网与协议互操作**不是**事故原因——这一点原文写得清清楚楚，我们不做过多的厂家里面的猜测，以报告为准。 ## 二、26小时时间线：每一步都慢在了哪里 ```mermaid timeline title 罗杰斯7·8断网关键时间线（美东时间） section 7月8日 4时43分 : 工程师删除分发路由器ACL策略过滤器 4时58分 : 核心路由器被路由洪水压垮 全业务中断 6时45分 : 值班人员抵达NOC 距故障已2小时07分 8时39分 : 通报911网络运营商 距故障近4小时 8时54分 : 社交媒体首次告知用户 9时25分 : 警报系统运营方Pelmorex主动来问 才得知警报发不出去 11时19分 : 通报监管机构CRTC 17时04分 : 首次表态将补偿用户 20时32分 : 部分区域逐步恢复 23时43分 : 政企VPN恢复 距故障19小时 section 7月9日 7时 : 服务基本恢复 全程约26小时 10时51分 : 通知911侧网络已恢复 16时25分 : 恢复后首条公共警报成功下发 ``` 时间线里有几个细节值得所有NOC同行琢磨： **4:43到4:58，只有15分钟。**从过滤器被删到核心路由器全倒，留给系统的自愈时间是零。路由协议的收敛速度在这里成了帮凶——LSA洪水扩散得越快，倒得越彻底。 **8:39才通知911侧，距故障近4小时。**报告对比了美国FCC在事故半年后出台的FCC 22-88规则：发现影响911的故障后30分钟内必须通报。而罗杰斯的解释是NOC自己都断了网，没法发通知——这个理由成立，但恰恰说明通报机制不能依赖生产网。 **9:25是Pelmorex主动打来的。**加拿大公共警报聚合分发系统（NAAD）的运营方Pelmorex是从新闻里听说断网的，反过来询问罗杰斯“警报能不能发到你的用户”。答案是：警报中心平台收到了，但发不出去。故障方主动通报警报体系的机制，当时在加拿大并不强制。 **定位根因花了约14小时。**前14个小时工程师看不到故障路由器的错误日志，加上同一维护窗口里做了多处变更、分不清该回滚哪张变更工单，初期还判断错了方向——先去查核心路由器，没想到真正的雷在分发层。 ## 三、根因拆解：一条过滤器删除引发的雪崩 ### 3.1 触发点：一次“配置清理” 事故前几周，罗杰斯在执行一个七阶段的IP核心网升级工程，出事的是第六阶段。这一步的目的是清理分发路由器的配置文件，操作中工程师删除了一条ACL（访问控制列表）策略过滤器。这条过滤器原本的作用是：阻止外部BGP路由被无限制地重分发进内部网关协议OSPF。 过滤器一删，标准配置模板里“允许BGP路由进OSPF”的行为立刻生效——互联网级的BGP全表开始被注入OSPF，作为链路状态通告（LSA）在自治域内 flooding。 ### 3.2 雪崩链：15分钟从一条命令到全国瘫痪 ```mermaid flowchart TD A["第六阶段变更：清理分发路由器配置"] --> B["误删ACL策略过滤器"] B --> C["BGP全表重分发进OSPF"] C --> D["LSA路由洪水涌向核心网"] D --> E["核心路由器CPU与内存耗尽"] E --> F["无过载保护上限可挡"] F --> G["15分钟内核心路由器全数宕机"] G --> H["无线与固网全业务中断"] H --> I["911与公共警报一并停摆"] ``` 看懂这条链需要补一点背景：罗杰斯和全球大多数一线运营商一样，采用无线＋固网共核心网的融合架构，移动、家宽、政企、911全部流量走同一张IP核心网。报告明确说这**不是设计缺陷**，而是业界普遍的成本与性能权衡——但代价是故障半径没有边界：核心层一倒，就是“ catastrophic loss of all services（所有服务的灾难性损失）”。 ### 3.3 为什么守不住：三道防线的集体缺席 报告把根因归纳为“配置错误＋流程失效”的组合，三道防线全部缺席： **第一道：路由器过载保护。**核心路由器上没有配置路由前缀数量上限（max-prefix类保护）。OSPF数据库条目数、BGP重分发条目数都没有限制。报告的原话是：如果有过载上限，“这次网络故障本可以被阻止”。这是整个事故里最扎心的一条——业界防止BGP策略误配导致路由泛滥的最佳实践早已是老生常谈。 **第二道：变更风控与实验室验证。**七阶段工程的第一阶段风险评估为“高”，此后每一阶段因为前面都成功了，风险评级被算法一路下调，到第六阶段变成了“低”——于是免除了额外审批和实验室验证。报告直接点名：对BGP路由策略进OSPF这类变更快评“低风险”，**违背行业规范**，此类变更本应先在实验室验证再上生产网。 **第三道：配置自动回滚。**核心和分发路由器上都没有配置自动回滚机制（超时未确认自动恢复旧配置）。报告也坦承：即便配了，对分发路由器这起案例是否来得及起作用并不确定——但没有它，工程师失去设备访问权后就只能干瞪眼。 ## 四、为什么修了26个小时：故障的“次生灾害” 如果说根因是“15分钟的雪崩”，那么恢复就是“26小时的长征”。拖时间的不是技术修复本身，而是报告里罗列的一连串次生灾害，每一条都值得抄进自己的应急预案： **1. 管理网骑在生产网上。**罗杰斯的管理网络（RCMIN）依赖自家IP核心网承载。核心网一倒，工程师远程登录不了任何一台路由器，只能派车派人去机房现场操作——NOC人员到达都花了2小时07分，偏远站点更久。NOC和关键远程站点也没有从第三方运营商购买的备份专线。 **2. 员工联系不上员工。**内部沟通依赖自家手机和宽带，两张网一起倒，应急指挥体系（战争室）召集都成问题。罗杰斯只能派人把其他运营商的SIM卡 physical dispatch 到各个站点——这一送就是5个小时。报告评论：说明灾备演练从来没真正测过“自己断网时怎么开会”。 **3. 14小时看不到错误日志。**远程管理通道断了，日志自然也拿不到。没有日志就没有根因，没有根因就只能靠猜。同一维护窗口里的多张变更工单成了烟雾弹——初期回滚了错误的工单，精力浪费在核心路由器上。 **4. 恢复还得防“信令风暴”。**根因定位后，罗杰斯没有一键放闸，而是先对MME（移动性管理网元）做限流节流，防止千万台终端同时涌回网络引发注册信令风暴，按中部、东部优先的顺序分区分批放号。这一手恰恰是2021年4月那次较小规模断网换来的经验——报告对此给予了正面评价，称恢复过程“有条不紊”。可惜的是，2021年那次复盘后的加固集中在移动网，没有延伸到IP核心网。 **5. 911的诡异场景：无线网活着，核心网死了。**基站和无线接入网其实还在运行，但核心网断了，终端收不到“本网不可用”的指示，不会自动漫游到别的网络去打911。只有两条路能打通：一是2G/3G电路域在核心网间歇性恢复时偶有接通（报告证实当时2G/3G话务量异常升高）；二是部分新款手机自带“主网不可用时自动搜网打紧急电话”的机制。这个“无线活、核心死”的缝隙场景，成了后来加拿大行业紧急漫游测试的重点科目。 ## 五、影响面：倒下的不只是手机信号 报告第五章列出的受影响客户清单，读起来像一份加拿大关键基础设施名录： | 影响领域 | 具体表现 | | --- | --- | | 个人用户 | 1200万无线＋家宽用户失联，含Fido、Chatr子品牌 | | 911报警 | 相当大比例用户无法接通PSAP接线台，固网911接通量远低于日常水平（具体比例在公开版中被脱敏） | | 公共警报 | NAAD系统警报无法送达罗杰斯无线用户；有线电视同样中断，警报通道全断 | | 金融支付 | Interac电子转账与刷卡支付网络走罗杰斯专线，全国借记卡支付大面积瘫痪 | | 政府机构 | 联邦、省、市三级政府部分服务中断 | | 关键设施 | 医院、能源电力、交通运输的MPLS/SD-WAN专线受影响 | | 广播媒体 | 罗杰斯旗下电视台、电台依赖自家IP网，警报与节目分发受阻 | | 行业下游 | 使用罗杰斯批发、漫游、转售服务的其他运营商与ISP被连带 | 一个细节可以说明影响的荒诞程度：加拿大服务局（Service Canada）护照办公室当天关门，付款终端刷不了卡，连多伦多罗杰斯中心球场的工作人员的手机都是罗杰斯的。一家运营商的核心网故障，等于全国数字生活的地基塌了一角——这就是融合核心网时代“故障半径”的真实含义。 ## 六、处置与整改：2.61亿美元买来的教训 ### 6.1 罗杰斯自救清单 事故后罗杰斯的整改可以归成三句话：**把洪水挡住、把管理网搬走、把两张网拆开。** - 挡洪水：在核心路由器上实施BGP重分发进OSPF的条目上限、OSPF数据库容量上限两道过载保护——直接对症根因； - 搬管理网：新建物理与逻辑双重独立的带内＋带外管理网，并为NOC及关键站点接入多家第三方ISP备份链路，还在评估卫星备份； - 拆核心网：宣布投入2.61亿加元将无线与固网IP核心网物理分离，故障半径从此有界（报告发布时该项目仍在推进中）；配套三年111.66亿加元网络投资。 流程侧同样大动干戈：新版变更风险算法（堵死“前几步成功就降级”的漏洞）、新增“受限类”变更强制高层审批与实验测试、运维与工程团队组织重构、告警优先级自动排序、核心路由器自动配置回滚、给全体应急与危机管理团队成员配发第三方运营商SIM卡。 ### 6.2 监管与行业动作 - **行业互助MoU**：2022年9月9日，在ISED要求下，12家主要运营商在CSTAC框架下签署《电信可靠性谅解备忘录》，内容包括紧急漫游、物资互助、重大故障2小时内通报政府和公众三大机制。罗杰斯随后与Bell、TELUS、SaskTel、Eastlink、Videotron/Freedom签了双边紧急漫游协议，覆盖911和语音漫游。 - **上报机制**：依据CRTC 2023-39号通告，重大故障2小时内向CRTC通报成为过渡性强制要求；罗杰斯与Pelmorex之间也建立了最高级别故障的自愿通报流程。 - **标准侧**：3GPP从R17起立项灾难漫游（disaster roaming）标准（TS 23.501体系内），全球监管近年都在推动——这次事故是常被引用的动因之一。 ### 6.3 评估结论与批评 Xona报告的总体结论是：整改措施“足以提升网络韧性并解决根因”，但反复强调一句话——**这类事故的本质是配置错误与流程失效的组合，防御它的不是买设备，而是日复一日把流程执行到位。**舆论并非一片好评：公共利益倡导中心（PIAC）执行主任John Lawford批评监管机构花了两年才交出报告，称这是一次“洗白”，认为“罗杰斯已解决问题”的说法证据不足。这份争议本身也有价值——它提醒我们，独立复盘报告的“ satisfactory”结论，和真实网络里的韧性，是两回事。 ## 七、给运维人的九条硬经验 报告第8.1节面向全球运营商总结了九条教训，我按一线视角翻译成大白话，建议逐条对照自家网络自查： 1. **核心网与汇聚层路由器必须配过载保护**——路由条目上限、重分发上限，这是本次事故的直接救命稻草； 2. **管理平面与数据平面物理、逻辑双隔离**——带外管理网不能骑在生产网上； 3. **NOC和关键站点要有第三方备份链路**——不能只用自家网络自己监控自己； 4. **配置变更审计要跨团队**——工程、运维、项目管理共同参与，关键基础设施变更拉上设备商驻场工程师； 5. **路由策略类变更必须过实验室**——实验室要能真实复刻生产网拓扑与规模； 6. **单一维护窗口控制变更数量**——变更越密，回滚决策越慢；自动回滚机制要预配置； 7. **告警分级自动化**——变更期间压制噪音告警，让真告警浮出来； 8. **给应急人员配异网SIM卡**——并纳入常态演练，而不是事故当天现派人送卡； 9. **故障场景演练要动真格**——桌面推演覆盖不了“管理网也断了”的场景，就永远发现不了这些坑。 ## 八、写在2026年：这起事故为什么还没过时 四年多过去，这个案例非但没有过时，反而越来越像一面镜子。2026年8月还有行业媒体专门撰文，把罗杰斯事故定义为“IP核心网路由控制问责”的标杆案例——此后每一次路由策略事故，业内都会拿它做参照。本栏目此前复盘过的KDDI、Optus全国性断网，根因细节各不相同，但底色高度一致：**一次变更、一个缺陷、一层缺失的保护，放大成全国性灾难。** 往后看，报告第8.2节预判的几条趋势，到今天全部应验并加重了：核心网云化、网元虚拟化让“配置错误”有了更多入口；AI自动化在加速变更的同时也在放大错误半径；天地一体网络被正式列为911备份通道的候选；灾难漫游从标准走向落地。换句话说，防止下一个“罗杰斯”，靠的不再是某台路由器上的某条命令，而是把过载保护、带外管理、变更风控、应急演练串成一条闭环——最好是在凌晨4点43分之前就串好。 ## 参考来源 1. [CRTC官方评估报告：Assessment of Rogers Networks for Resiliency and Reliability Following the 8 July 2022 Outage（Xona Partners）](https://crtc.gc.ca/eng/publications/reports/xonarp2023.htm) — 本文主轴来源，含完整时间线、根因分析与整改评估 2. [CRTC报告全文PDF（加拿大政府出版库）](https://publications.gc.ca/collections/collection_2024/crtc/BC92-130-1-2024-eng.pdf) — 报告正式出版物版本 3. [CBC News：Human error caused 2022 Rogers outage, system 'deficiencies' made it worse](https://www.cbc.ca/news/politics/rogers-outage-human-error-system-deficiencies-1.7255641) — 主流媒体报道与PIAC批评观点 4. [MobileSyrup：July 2022 Rogers outage caused by human error, prolonged by restoration challenges](https://mobilesyrup.com/2024/07/05/july-2022-rogers-outage-report-crtc/) — 加拿大科技媒体对报告要点梳理 5. [CRTC第二份评估报告（2024）](https://crtc.gc.ca/eng/publications/reports/xona2024.htm) — 罗杰斯网络韧性与可靠性评估系列文件 6. [BTW Media：Rogers' 2022 outage made IP-core route controls an accountability](https://btw.media/en/rogers-2022-ip-core-route-control-accountability) — 2026年8月行业回顾：该事故如何改变路由控制问责 --- > 本文由「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 等场景全覆盖。