<!-- title: 90万条路由公告压垮Optus -->

2023年11月8日凌晨4点05分，澳大利亚第二大电信运营商Optus的全国网络，在没有任何攻击、没有任何人为误操作的背景下安静地熄灭了。超过1000万人、近50万家企业同时失联，银行、医院、火车、POS机、甚至连000紧急电话都打了出去。事后查明：触发点只是一次“按计划顺利完成”的海外上游软件升级，而压垮网络的，是一小时内超过94万条BGP路由公告——这个数字是平常水平的300多倍。本文基于澳洲参议院委员会文件、政府委托的Bean独立审查报告和通信监管机构ACMA的执法调查报告，把这场“路由雪崩”的完整链条拆开来看：一次合规的变更如何层层放大成全国瘫痪，为什么4G/5G基站都正确“熄火”了，3G却成了紧急电话的隐形杀手，以及这份价值18条建议的整改清单，对每一个核心网运维人意味着什么。

## 目录

- 一、清晨4点05分，一张网悄悄熄灯
- 二、时间线：13小时全国静默
- 三、根因复盘：一场合规升级如何引爆路由雪崩
- 四、为什么900倍的路由公告能压垮核心网
- 五、比断网更致命的：000打不通的两小时
- 六、恢复为什么不能一键重启
- 七、代价：市值、CEO与1200万罚单
- 八、Bean审查的18条建议与制度补丁
- 九、给核心网运维人的五个教训
- 十、结语

## 一、清晨4点05分，一张网悄悄熄灯

Optus是澳洲第二大运营商，隶属新加坡电信（Singtel），移动用户超1000万，4G网络覆盖96.9%的人口，全澳约25%的手机用户和19%的宽带用户挂在它网上。此外还有Dodo、Amaysim、Aussie Broadband、Moose Mobile等一票虚拟运营商和转售商，也都骑在这张网上。

11月8日凌晨4点05分（AEDT，澳东夏令时），网管系统捕捉到第一批异常：客户侧网络开始成片断连，部分域名解析随之失效。这个时间点选得很“好”——凌晨4点，值班人员最薄、告警最安静的时刻，而三个多小时后，整座国家就要醒来了。

断网的影响面在 Sunrise 之前就已经展开：银行App连不上、EFTPOS刷卡机离线、医院内网受阻、部分政府服务停摆。受冲击最直观的是墨尔本城铁——从5点到6点，因为司机无法与控制中心通话，Metro Trains直接停摆，全天累计约500个班次取消。而在所有影响里，最严重的一条直到调查阶段才被量化：**000紧急电话打不通了**。有处于险境的人按下呼叫键，听到的是错误提示音。

当天晚些时候，Singtel在新加坡交易所的股价下跌4.8%，单日市值蒸发超过20亿澳元。这不是一次机房跳电，也不是一次网络攻击——Optus很快排除了网络攻击的可能。这是一张核心网在自己的“自我保护”逻辑下，把自己关了机。

## 二、时间线：13小时全国静默

先看完整的时间线，细节均来自参议院委员会收到的技术文件、Bean审查报告与媒体当日报道的交叉记录：

| 时间（AEDT） | 事件 |
| --- | --- |
| 11-08 04:05 | 首批用户断连，BGP路由公告风暴开始，部分DNS失效 |
| 05:00–06:00 | 墨尔本城铁因调度通信失联停摆，全天约500班次取消 |
| 06:33 | Optus发出第一份媒体声明（事发约2.5小时后） |
| 08:16 | 第二份媒体声明，仍未给出恢复时间表 |
| 09:00前后 | Optus宣布找到“恢复路径”，恢复工作铺开 |
| 11:30 | 约11%业务恢复 |
| 13:00 | 约88%业务恢复 |
| 16:00前后 | 主要业务恢复（全程约12–13小时，9News称“近14小时”） |
| 18:00 | Optus宣布大部分服务恢复，间歇性异常持续到次日 |
| 11-09 | CEO宣布200GB流量补偿；联邦政府宣布委托独立审查 |
| 11-17 | Optus向参议院提交技术报告，根因链条首次公开 |
| 11-20 | CEO Kelly Bayer Rosmarin辞职 |
| 2024-03 | 政府收到Bean审查最终报告 |
| 2024-04-30 | 审查报告与政府回应一同公开发布 |
| 2024-11 | ACMA裁定违规成立，Optus支付超1200万澳元罚金 |

故障传播本身，可以用一张图概括——这也是本文最想让你记住的一条链：

```mermaid
flowchart TD
    A["STiX北美路由器<br/>计划内软件升级"] --> B["一台路由器退出<br/>流量按预期改道"]
    B --> C["Optus收到海量<br/>IPv6路由更新"]
    C --> D["路由更新逐层传播<br/>全网路由表快速刷新"]
    D --> E{"超过设备厂商<br/>默认安全阈值"}
    E -->|是| F["约90台边缘路由器<br/>触发自保护隔离"]
    F --> G["无线接入与核心网<br/>连接中断"]
    G --> H["O&M网管网失联<br/>看不见基站"]
    H --> I["3G射频单元仍在发射<br/>终端驻留错误信号"]
    I --> J["000紧急呼叫失败"]
```

注意链条后半段：从“路由器自隔离”到“紧急电话失败”之间，还隔着两层——网管网失联，和3G基站的异常行为。这两层才是这次事故真正的行业级教训，后面展开。

## 三、根因复盘：一场合规升级如何引爆路由雪崩

### 3.1 起点：一次“按预期完成”的升级

根据Optus提交参议院的技术文件，事件的起点是Singtel国际互联网交换中心STiX（Singtel Internet eXchange）在北美的路由器软件升级。升级过程中，一台路由器按预期离线，流量自动改道到另一台位于亚洲的对等路由器——这本身就是这类升级的标准剧本，改道行为完全正常。

问题出在改道的“副作用”上。ACMA的调查报告（2024年11月发布）还原了细节：改道之后，Optus网络从那条备用对等路由器收到**一次性的、海量的IPv6路由信息更新**。这些更新不是攻击，不是误配，就是拓扑变化之后正常的路由重收敛——只是体量足够大。

### 3.2 放大：路由表刷新的多层传播

这些路由更新沿着Optus网络逐层传播，从骨干到汇聚再到边缘，触发各层路由器密集重算路由表。这里有一个经常被低估的事实：**路由收敛是有代价的**。每一次大规模重收敛，都意味着CPU、内存和信令交互的瞬时尖峰。平时的网络对此毫无压力，但当天下午的Optus核心网，正被一波接一波的路由更新反复冲刷。

### 3.3 引爆：厂商默认阈值下的“自保”

参议院文件披露，当天约**90台边缘路由器**因为路由更新负载超过了预配置的默认安全阈值，触发了自动保护机制，主动断开了自身连接——也就是所谓“自隔离”（self-isolation）。按维基百科引述的文件原文，这些阈值是设备厂商设定的出厂默认值（ACMA报告表述为“第三方设备厂商预设的安全限制”，并特别指出：**这些默认值本来是可以修改的**）。

这里要先澄清一个容易误读的点：自保护机制本身没有错，它防止的是路由进程彻底崩死。真正的争议在于——ACMA在调查中明确拒绝了Optus“不可抗力”的辩护。ACMA的逻辑是：路由改道是按预期发生的，流量逐层传播时其他层的设备都没有自隔离，Optus自己也承认网络“本应扛得住”这种变化；核心路由器的维护、网络架构与配置，全部在Optus自己的可控范围内。**设备厂商和外部专家从未提示过这个风险，不能免除Optus对自身配置与变更管理的责任**——这是ACMA执法认定里最重的一句话。

换句话说：触发器在别人手里，但引信、火药和引爆条件，都在自己家里。

### 3.4 旁证：Cloudflare看到的94万条公告

第三方数据也印证了这场雪崩的规模。Cloudflare Radar对Optus自治域AS4804的监测显示：事发前一小时内，该节点发布了**超过94万条BGP路由公告**，而它平时的水平是**每小时不足3000条**——300多倍的瞬时放大。一个网络向全球互联网“尖叫”了整整一个小时，而这场尖叫的终端效果，是它自己闭上了嘴。

## 四、为什么900倍的路由公告能压垮核心网

给非路由专业的读者补一层原理。BGP（边界网关协议）是互联网各自治域之间交换“哪些地址走我这里可达”的协议。正常情况下，路由表是相对稳定的，增量更新每秒几条到几十条。但当一台核心路由器退出时，它原本“代言”的几十万条路由前缀需要被重新通告、重新选路、重新传播——这就是所谓的路由重收敛风暴，业界俗称“路由抖动”的极端形态。

更麻烦的是路径探测（path hunting）现象：拓扑变化会诱发设备之间反复地撤回、重新通告、再撤回、再重新通告，公告数量呈乘法放大。Cloudflare看到的那94万条，就是这整个过程的外部投影。

多数运营商对这类风险的防线有两个：一是路由策略控制（对上游传来的前缀数量、变化速率做过滤与限速），二是设备级的保护阈值（比如控制路由进程的最大内存占用、每秒更新处理上限——超过就挂起或隔离，宁可断自己也不崩全网）。Optus事件暴露的正是第二道防线的暗面：**阈值是死的，网络是活的**。出厂默认值按“通用网络”设计，而一张全国性移动网的路由规模、IPv6前缀体量、多层传播结构，都和“通用假设”相去甚远。ACMA的结论之所以站得住，就是因为“审查并调整这些默认值”这件事，始终在运营商自己的责任清单上。

## 五、比断网更致命的：000打不通的两小时

如果说路由雪崩是技术层面的根因，那000紧急电话的失灵，就是这次事故之所以惊动国会、催生18条制度建议的直接原因。而这一段，恰恰是所有移动网运维人都该抄进教科书的部分。

### 5.1 wilting机制：全网的“保险丝”

澳洲移动行业有一个通行做法叫**wilting**（基站“萎蔫”）：当某个网络的业务出问题时，基站主动熄灭无线信号，让手机搜不到本网，从而自动驻留到其他运营商的网络上去——此时用户即使拿着Optus的卡，也能借道Telstra的电话网把000打出去。这是“紧急呼叫优先于商业关系”的行业底线设计，平时通过端到端演练保障其有效。

### 5.2 4G/5G熄了，3G亮着

8日当天，核心网失联后，Optus的4G和5G基站按设计自动wilting了——这部分机制工作正常，手机开始搜索其他网络。但**3G射频单元没有熄灭**。Bean审查报告解释了原因：3G单元通过语音通道维持着与核心网的最后连接，在它自己看来“链路还活着”，于是继续发射信号；而实际情形是，呼叫根本无法穿过已经瘫痪的核心网抵达000平台。

于是灾难性的场景出现了：一部分手机在搜索网络时，捕捉到了Optus残存的3G信号，认为“本网还在”，便驻留上去尝试拨打000——然后收到核心网返回的错误信号。这些手机没有再去尝试其他运营商。**一道本应保护用户的多余信号，反而成了困住用户的牢笼。**

### 5.3 网管网同归于尽，想关都关不掉

更扎心的在后头。运维人员并非不知道3G还在发射——问题是**看不见，也够不着**。ACMA调查认定：核心网自隔离导致Optus的O&M运营管理网随之失联，而O&M网络正是监控和管理基站等网元的通道。也就是说，路由器自保的那一刻，运维人员对全网的“眼睛”和“手”同时被拔掉了。Bean审查把Optus无法保证000接通的原因归结为两条：**无法通过O&M网或带外（OOB）网触达核心基础设施，以及无法强制3G基站执行wilting**。

带外管理网（Out-of-Band）本是为此类场景准备的生命线——一条不依赖业务网的管理通道。但ACMA认定，Optus没能采取可实施的步骤建设“在断网时仍能有效管理网络”的带外连接；O&M网的设计本应降低对核心网的依赖，把级联故障风险压到可接受水平。Optus曾辩称OOB网不承载紧急呼叫、因此不适用相关条款，被ACMA直接驳回：OOB失守之所以相关，正因为它让全网失去了进入“更安全的降级状态”的能力。

最终，ACMA在执法认定中给出的数字是：**2145人未能接入紧急呼叫服务**（其中Optus Mobile用户2091人、Optus Networks用户41人、Optus Internet用户12人，另有1通106TTY呼叫失败）；事后法定的福利回访（确认呼叫者后来是否得到帮助）又有**369人未按要求完成**。每一通失败的000背后，都是一次心脏病发作、一场火灾或一次暴力侵害的可能性——这就是监管机构把罚单开到1200万澳元以上的原因。

这个案例给全体移动网人的启示是赤裸裸的：**fallback不是画在架构图上的，它是必须被反复实测的行为。**保险丝起效的前提，是“断得干净”——残缺的信号比没有信号更危险。

## 六、恢复为什么不能一键重启

很多人第一反应是：90台路由器断了，重启不就完了？现实远比这残酷。

第一，这不是几台设备宕机，而是路由器在过载保护下主动退出，若不解决路由风暴的输入源就强行复位，设备会再次被同一波更新冲垮，甚至引发更大面积的连锁自保。恢复的第一步是让路由收敛过程重新可控，而不是简单加电。

第二，又是O&M失联的后遗症：大量设备处于“盲区”，哪些自隔离了、哪些还活着、哪些状态异常，网管一概不知。Bean审查记录的恢复规模是：**在全国14个站点、对超过100台设备逐台操作**，能远程的远程，不能远程的派人上站。这就是为什么11%到88%的恢复曲线花了整整一个半小时，而“大部分恢复”的宣告直到18点才发出，间歇性异常拖到次日。

第三，每恢复一批设备，就有一批业务突然回流，对仍在带病运行的部分又是一次冲击。恢复操作必须分批、验证、再分批——凌晨4点的一次路由风暴，最终变成了一场持续十几个小时的全国性手工修复工程。

```mermaid
flowchart TD
    subgraph L4["4G与5G基站"]
        A1["核心网失联"] --> B1["按设计自动wilting<br/>信号熄灭"]
        B1 --> C1["终端搜索其他网络<br/>000可借道他网"]
    end
    subgraph L3["3G射频单元"]
        A2["核心网失联<br/>但语音通道未断"] --> B2["信号继续发射<br/>网管网失联无法关闭"]
        B2 --> C2["终端驻留Optus 3G<br/>000呼叫收到错误信号"]
    end
```

同一张网、同一时刻、两代无线接入，一个保险丝正确熔断，一个保险丝焊死在“闭合”位——结果天差地别。

## 七、代价：市值、CEO与1200万罚单

事故的直接与间接代价，可以列一张账单：

- **资本市场**：母公司Singtel当日股价跌4.8%，市值蒸发超20亿澳元；
- **竞争格局**：竞对Telstra门店出现排队转网，摩根大通分析师测算，若仅2.5%的Optus用户流失，Telstra未来几年年利润可增加约1.25亿澳元；
- **企业用户**：近50万家企业当日无法收款、无法接单，大量小店被迫歇业，而Optus事后给出的补偿——后付费用户200GB流量、预付费用户周末不限量、家宽用户12月提速——被舆论痛批“毫无诚意”，媒体标题直接引用用户原话：“数据对我们没有价值”；
- **人事**：11月20日，CEO Kelly Bayer Rosmarin辞职，距事发仅12天；
- **监管**：2024年11月，ACMA裁定Optus三家子公司在紧急呼叫接入、通知其他通信服务商（16家与20家CSP仅靠媒体声明“广播式”通知，被认定不构成法定直接通知）、福利回访等环节违规，累计支付超过1200万澳元罚金。ACMA的原话是：000可用性是电信商必须向公众提供的最根本服务，“当紧急呼叫无法接通时，可能对公共健康与安全造成毁灭性后果”。

一次凌晨的路由风暴，最终以市值、帅位、罚金三线买单收场。

## 八、Bean审查的18条建议与制度补丁

事故次日（11月9日），联邦通信部长Michelle Rowland宣布委托独立审查，由前ACMA副主席Richard Bean主持。审查于2024年3月提交最终报告，4月30日与政府回应一同公布，共提出**18条建议**。技术根因虽不在其scope内，但审查对应急体系、客户通信、申诉补偿的系统性批评极其锋利。核心整改可以归成四张补丁：

| 领域 | 事故暴露的缺口 | 整改动作 |
| --- | --- | --- |
| 紧急呼叫治理 | 000生态无端到端责任主体，Telstra仅是"接线员"角色，无权也无责统管全链路 | 政府设立Triple Zero生态托管人（Custodian），统筹端到端监控 |
| 演练与实测 | wilting、驻留切换等fallback只停留在架构假设上，从未在最恶劣断网场景下实测 | 建议每半年对000全生态做端到端测试，缺陷须报ACMA并附整改时间表 |
| 客户通信 | 第一份声明迟至事发2.5小时后，全天无恢复时间表，弱势群体无所适从；行业协议属自愿性质 | ACMA更新紧急呼叫规则，出台《断网期客户通信行业标准（2024）》，把断网告知变成强制义务 |
| 协同与冗余 | 重大中断通报协议未被遵守，国家协同机制（NCM）下午才激活；政府自身业务单运营商依赖 | 升级通报协议与中央协同点；政府自查关键业务的通信冗余 |

审查报告里有一句话值得裱起来挂在NOC墙上：保险与兜底“不是因为架构图上画了它就存在，只有真实设备在真实故障下的行为正确，它才存在”。

## 九、给核心网运维人的五个教训

以一个在核心网和运维一线滚了十八年的视角，这场事故值得抄进个人运维手册的，是下面五条：

**第一，把“厂商默认值”当成待审项，而不是出发点。**设备的安全阈值、保护参数都是按“假想的通用网络”出厂的，而你的网络是具体的。每一次扩容、每一次IPv6规划调整，都应该回头问一句：那些保护阈值还合适吗？ACMA点名“默认值本可修改”，这句话在任何裁决书里出现，都意味着责任无可推卸。

**第二，管理面必须与业务面解耦，且要真演练。**这次事故里，业务面垮掉的同时管理面跟着陪葬，是恢复缓慢和000失灵的直接推手。带外管理网不是预算富余时的装饰品，它是全网失明时唯一的眼睛。检验标准只有一个：把核心网按停，你还能不能看见并操控基站？没按停过，就等于没有。

**第三，警惕“残存信号”这种最阴险的故障态。**用户和终端无法区分“本网健在”与“本网只剩个空壳”。任何在故障期间仍在辐射、但已无法完成业务的信号——3G语音通道、Wi-Fi Calling热点、伪善的RSSI——都是把用户锁死在故障里的锁链。降级状态的设计目标不是“看起来还活着”，而是“干净地把用户让出去”。

**第四，对上游变更保持敬畏，变更管理要有“外部输入”维度。**这次没有任何一方“做错”：上游升级按计划完成，改道按预期发生。事故发生在两层变更管理的缝隙里——上游不知道自己的重收敛会冲击下游多深，下游没有评估过上游变更对自己的影响。跨域互联的变更通报与压力评估，应当在你们的变更流程里有一席之地。

**第五，紧急通信是全网设计的最高约束条件。**调度优先级、参数配置、降级策略，全都要服从“任何时刻、任何故障下，用户都能打通报警电话”这一条。000失败呼叫的记录、事后的福利回访，同样要当作生产流程而非文书流程来建设——ACMA罚单里，有相当比例就是因为回访没做成。

## 十、结语

Optus 2023断网最令人后背发凉的地方，在于整场灾难里**没有一个人做错了事**：上游的升级按计划完成，路由器按出厂设计自保，4G/5G基站按行业规范wilting，运维团队也在当天就找到了恢复路径。但一张全国性网络依然瘫痪了13个小时，2000多通报警电话没能接通。这不是某个人的失误，而是一整套“假设没有被实测过”的体系，在真实压力下的总暴露。

两年多过去，这份账单已经陆续开出：1200万澳元罚金、一位CEO、18条制度建议、一部强制客户通信标准、一个全新的000生态托管人。而对每一个通信人来说，真正的作业只有一道题——**你网上那些“设计上应该生效”的保命机制，上一次在真刀真枪的故障里被验证，是什么时候？**

## 参考来源

1. [2023 Optus outage - Wikipedia](https://en.wikipedia.org/wiki/2023_Optus_outage) — 事件全貌综述，含参议院委员会技术文件、Reuters/SMH/9News当日报道及Cloudflare Radar AS4804数据引注
2. [Bean Review into nationwide Optus outage - 澳大利亚基础设施与通信部长媒体稿](https://minister.infrastructure.gov.au/rowland/media-release/bean-review-nationwide-optus-outage) — 官方确认审查负责人、wilting机制说明及"3G未熄灭为000中断主因"的结论
3. [Australian Government Response to the Bean Review Final Report (PDF)](https://www.infrastructure.gov.au/sites/default/files/documents/review_into_the_optus_outage_of_8_november_government_response.pdf) — 政府对18条建议的正式回应，2024年4月30日发布
4. [ACMA Investigation report - Optus outage 8 Nov 2023 (PDF)](https://www.acma.gov.au/sites/default/files/2024-11/Investigation%20report%20-%20Optus%20outage%201Nov23%20%28redacted%29.pdf) — 监管执法调查：核心路由器自隔离定责、O&M/带外网认定、2145通未接通紧急呼叫细节
5. [Optus and the outage that made emergency calling a carrier accountability test - btw.media](https://btw.media/en/optus-and-the-outage-that-made-emergency-calling-a-carrier-accountability-test) — 对Bean审查与ACMA报告的深度责任链分析，含罚款金额、福利回访与整改清单梳理

---
> 本文由「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 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
