网络知识
Incident Files · Internet Infrastructure

大厂网络事故复盘

协议没有突然失效。真正把一次变更推成全球事故的，往往是信任边界、自动化半径、隐含依赖和恢复流量共同作用。这里用 20 起公开复盘，把“为什么”还原成值班时可辨认的证据。

本页关注广域网与基础设施；主机内核、容器、连接队列和抓包证据请看并行的 主机侧网络实战案例集。

证据等级厂商确认外部观测分析推断

案例索引

路由信任链

01 · P1YouTube /24 劫持02 · P1Verizon route leak03 · P11.1.1.1 /32 与 RTBH13 · P2CenturyLink FlowSpec

内部网络与自动化

04 · P1Cloudflare local-pref 吸流05 · P1GCE 全量撤路06 · P1FlowSpec 打崩边缘07 · P1Direct Connect 误转发14 · P2Cloudflare MCP 顺序错误15 · P2GitHub 网络分区16 · P2Fastly 配置触发17 · P2GCP ACL 与 fail-static

DNS 是数据，也是路径

08 · P1Meta 骨干与 DNS 撤路09 · P11.1.1.1 拓扑全撤路18 · P2根区签名过期19 · P2Akamai DNS 配置

拥塞吃掉救援工具

10 · P1Google 控制面停摆11 · P1AWS 重试风暴12 · P1Azure 全球 WAN 重算20 · P2Cloudflare–AWS PNI
THREAD 01 / 04

路由信任链

BGP 邻居说“这条路可达”，不代表它有权说。更具体前缀、商业策略与黑洞社区，会把一个局部错误放大成全球转发事实。

01

Pakistan Telecom / YouTube：本地黑洞泄露全球

AS17557 的 /24 压过 YouTube AS36561 的合法 /22，世界流量被最长前缀匹配带向巴基斯坦。

外部观测 · RIPE RIS
External symptom

YouTube 从全球大量网络不可达；路由表里同时存在合法聚合路由与来自巴基斯坦的更具体路由。

时间线

  1. Pakistan Telecom AS17557 开始向上游 PCCW AS3491 宣告 208.65.153.0/24；YouTube 原有覆盖该网段的 208.65.152.0/22。

  2. YouTube 宣告同一 /24，部分网络按 AS path 与策略切回，仍非全量恢复。

  3. YouTube 临时宣告两个 /25；很多运营商不接受长于 /24 的 IPv4 路由，效果并不一致。

  4. PCCW 撤销 AS17557 的错误路由，全球收敛恢复。

网络根因链

现象合法服务全球不可达
触发国内封锁用 /24 黑洞路由被送给外部上游
放大上游未过滤；/24 比 /22 更具体，LPM 优先
恢复合法方临时反宣告；上游最终撤掉错误起源
失效防线

AS17557 缺少出口过滤；AS3491 缺少按客户授权前缀的入口过滤。全球 BGP 把逐跳信任当成了权限证明。

值班证据
  • Looking Glass / RIS 里同一目的出现 /22、/24、/25。
  • 跨探针 traceroute 在 AS3491→AS17557 方向收束。
  • 流量曲线随更具体前缀出现/撤销呈阶跃变化。
教训：恢复不能只靠“再宣告一条更具体的路”；客户前缀清单、ROA/ROV 与出口过滤才是长期防线。
全书 · CIDR 与 LPM全书 · 路由转发图谱 · BGP

来源：RIPE NCC RIS 案例研究 · APNIC 原理佐证

↑ 返回顶部
02

Verizon / Allegheny：优化器泄露更具体前缀

AS33154 的优化路由经 AS396531 泄露给 Verizon AS701，容量不足的小路径吸入大范围互联网流量。

外部观测 · Cloudflare
External symptom

Cloudflare、Amazon、Linode 等大量目的从部分网络不可达；Cloudflare 最坏时丢失约 15% 全球流量。

时间线

  1. DQE AS33154 生成的更具体“优化”路由经 Allegheny AS396531 进入 Verizon AS701 并广泛传播。

  2. 大量目的被送入小容量路径，丢包与超时取代了单纯的路径绕行。

  3. 相关方停止泄露路由，互联网路由逐步稳定。

网络根因链

现象多家服务从部分 ISP 不可达
触发Noction 优化器生成的 more-specific 被错误对外发布
放大AS701 缺少 IRR/RPKI/max-prefix 过滤；LPM 与商业 local-pref 吸流
恢复停止错误宣告，等待全网路由收敛
失效防线

客户边界没有限制可宣告前缀与数量。即使 origin 看似合法，传播关系仍可能是 RFC 7908 所说的 route leak。

值班证据
  • Looking Glass 显示大量无关前缀突然共享 701 396531 33154 路径片段。
  • 路径变化先于 HTTP 5xx/超时，且只影响选择 AS701 的来源。
  • 错误路径带宽小，RTT、丢包与接口利用率同步恶化。
教训：ROV 只验证起源不够；还需要 IRR 过滤、max-prefix 与能验证 AS 传播关系的机制。
全书 · 最长前缀匹配全书 · BGP图谱 · LOCAL_PREF

来源：Cloudflare 当日复盘 · Cloudflare 深入分析

↑ 返回顶部
03

Cloudflare 1.1.1.1：/32 劫持与 RTBH 叠加

AS267613 宣告 1.1.1.1/32，AS262504 又经 AS1031 泄露 1.1.1.0/24；部分网络把第三方 /32 当远程黑洞路由接收。

厂商确认外部路由观测
External symptom

巴西等地区的 1.1.1.1 查询黑洞或绕到异常远端；同一 anycast 地址因上游选择不同呈现“有人完全不通、有人只是变慢”。

时间线

  1. AS267613 宣告 1.1.1.1/32；一分钟后 AS262504 向上游泄露 1.1.1.0/24。

  2. Cloudflare 建立事故，关闭受污染 peering 并联系相关网络。

  3. 黑洞基本解除，但部分路径仍被错误带往巴西而高延迟。

  4. /24 route leak 完全解决。

网络根因链

现象递归 DNS 黑洞或地理绕路
触发未授权 /32 起源与 /24 错误传播同时出现
放大LPM 压过正常 /24；Tier-1 接受未授权 RTBH；部分网络忽略 RPKI Invalid
恢复隔离受污染对等连接并协调撤路
失效防线

公网通常过滤长于 /24 的 IPv4 前缀，但这只是惯例；RTBH 社区授权、ROV 与 route-server 策略任一放宽，/32 仍可能进入转发决策。

值班证据
  • BGP collector 看到 /32 的 RPKI 状态为 Invalid。
  • 不同探针分别表现为无路由、RTBH 丢弃或 RTT 突然指向巴西。
  • dig @1.1.1.1 超时，而其他 resolver 正常。
教训：监控不应只问“我的 /24 还在吗”，还要问“是否出现更具体路由、路径是否发生不合理地理漂移”。
全书 · LPM全书 · BGP图谱 · BGP图谱 · DNS

来源：Cloudflare 官方详细复盘 · RFC 7908 · Route Leak

↑ 返回顶部

P2 · 对照短卡

13 · P2CenturyLink / Level 3：FlowSpec 阻断 BGP 会话2020-08-30 · 路由控制面自伤＋
厂商确认 · 规则阻断会话Cloudflare 观测自激循环为分析推断

链：offending FlowSpec 阻止 BGP 建立 → 全球单归属客户失联；Cloudflare 观察到 15 分钟更新量由常态 1.5–2 MB 升至约 26 MB，并在 48 城停用该 transit。CenturyLink 确认 FlowSpec 是根因；“会话断开使规则消失、会话恢复又重新收到规则”的自激循环仅是 Cloudflare 基于现象提出的推断，不当作厂商结论。

值班看什么：BGP session flap 与 UPDATE 字节量同步脉冲；按 transit 分组的可达性；撤掉该上游后是否恢复。修复是识别并阻断错误规则，约 14:30 UTC 恢复（Cloudflare 观测）。

图谱 · BGP全书 · 收敛排障 · 路由断点

来源：Cloudflare 外部分析

THREAD 02 / 04

内部网络与自动化

自动化把正确意图快速复制，也会把错误语义快速复制。真正的安全门不是“有人审核”，而是能阻断异常前缀集合、错误转发和相关性设备故障的闭环。

04

Cloudflare：一条策略把半张网吸到亚特兰大

prefix-list 条件被停用后，策略 term 变成 match-all，以 local-pref 200 压过本地路由的 100。

厂商确认
External symptom

多个地区站点失去服务，亚特兰大 CPU 满载；Cloudflare 全网流量一度下降约 50%。

时间线

  1. EWR–ORD 链路丢失，ATL–IAD 开始拥塞。

  2. 错误策略生效，亚特兰大开始吸引几乎全部骨干流量。

  3. 将亚特兰大从骨干摘除；客户流量恢复。

  4. 日志与指标等内部系统完全恢复。

网络根因链

现象多地掉线、单点满载
触发本想禁用 term，却只禁用其中 prefix-list 条件
放大无条件即匹配全部；local-pref 200 吸走 local-pref 100 的本地路由
恢复摘除 ATL，后续加 max-prefix 与本地优先级护栏
失效防线

配置审核只看文本差异，没有计算策略匹配集合的语义变化；iBGP 邻居也没有用 max-prefix 限制异常 fan-out。

值班证据
  • 路由反射器/Looking Glass 中大量前缀 next-hop 同时指向 ATL。
  • ATL 流入、CPU、丢包陡升，其他站点流量同步塌陷。
  • 控制面 BGP 仍 up，但数据面经过热点后失败。
教训：配置发布前要做“匹配了多少前缀、最优路径将迁移到哪里”的语义 diff；本地服务路由要有不被普通远端策略覆盖的护栏。
图谱 · LOCAL_PREF全书 · BGP排障 · 路由断点

来源：Cloudflare 官方复盘

↑ 返回顶部
05

Google Compute Engine：canary 失败，坏配置仍下发

配置生成器错误移除全部 GCE IP block；canary 正确报警，第二个 bug 却没有把失败返回发布器。

厂商确认
External symptom

外部入站到 GCE 的流量损失超过 95%，内部通信和出站仍正常；早期只看到 asia-east1 VPN 与路径变远。

时间线

  1. 删除一个未使用 IP block，触发两个配置文件短暂不一致。

  2. asia-east1 VPN 先出现异常；逐站发布令仍在线的 anycast 站点承接更远流量。

  3. 最后站点收到坏配置；外部入站损失超过 95%。

  4. 回滚完成，BGP 前缀重宣告恢复。

网络根因链

现象入站全黑，内部/出站仍通
触发配置不一致触发潜伏 bug，产出空前缀集合
放大canary 失败未闭环；渐进发布最终撤掉所有站点 BGP
恢复回滚最近配置，逐站重宣告
失效防线

canary 本身做对了判断，但“失败必须阻断发布”不是硬约束；发布器把一个未返回的错误当成可继续。

值班证据
  • 路由 collector 看到 GCE 前缀按站点逐批消失。
  • 外部探针失败，实例内部互访与出站保持正常。
  • 路径变远、VPN 局部异常先于全球黑屏，是容量基数下降的早信号。
教训：比较发布前后的前缀集合与站点覆盖基数；canary 的拒绝必须是不可绕过的硬门。
图谱 · BGP全书 · 路由转发排障 · 控制/数据面

来源：Google Cloud 官方事故报告

↑ 返回顶部
06

Cloudflare：一条 FlowSpec 打崩全部边缘

攻击画像生成不可能的 99,971–99,985 字节包长；规则全球下发后触发 Juniper 路由器内存耗尽。

厂商确认
External symptom

Cloudflare 从互联网“消失”：ping、traceroute 无路由，代理与 DNS 同时不可达，23 个 anycast 站点相继掉线。

时间线

  1. 全球站点不可达；边缘路由器遇到坏 FlowSpec 规则后耗尽内存并崩溃。

  2. 团队定位到规则并删除；部分设备只能由数据中心人员硬重启。

  3. 站点陆续恢复，但先恢复的小部分容量被全网流量再次压满。

  4. 全量服务恢复，DNS 负缓存留下少量尾部。

网络根因链

现象所有 anycast 站点撤路
触发异常攻击画像被转成合法 FlowSpec 配置
放大全球 fan-out + 同型号设备相关性 bug；小规模恢复又被流量淹没
恢复删除规则、硬重启设备、分批恢复容量
失效防线

输入没有“不可能值”校验；安全规则缺少 canary 与作用域；设备同质化让站点冗余无法抵御相关性故障。

值班证据
  • （分析推断）Looking Glass 中所有正常 anycast 前缀同时撤销。
  • （分析推断）设备内存曲线在接收同一规则后同步上升。
  • 首批重启节点恢复后立刻出现接口/CPU 满载。
教训：安全自动化也要做输入边界、canary 和分批发布；恢复容量未达到流量需求前，不能让全网 anycast 自动灌回。
图谱 · BGP全书 · 路由收敛全书 · 拥塞控制

来源：Cloudflare 官方复盘

↑ 返回顶部
07

AWS Direct Connect Tokyo：健康信号未识别数据面错误

快速收敛协议与新流量模式触发网络 OS 潜伏缺陷；设备未正确转发，自动化却没有将它们摘除。

厂商确认
External symptom

东京区域 Direct Connect 客户间歇高丢包；互联网、VPN 和跨可用区路径正常，手工摘除一台设备只能短暂缓解。

时间线

  1. 告警开始，Direct Connect 出现间歇连接与高丢包。

  2. 手工摘除设备后又有更多冗余设备进入相同错误状态，可用容量持续下降。

  3. 团队将怀疑收敛到快速收敛协议与网络 OS 的交互。

  4. 先在单 AZ 禁用验证，再逐 AZ 扩展；网络稳定恢复。

网络根因链

现象设备/控制侧健康信号未识别数据面错误
触发正常流量模式撞上数月前启用协议的潜伏 OS 缺陷
放大健康检查未识别错误转发；故障设备未摘除，冗余设备继续同类失败并造成拥塞
恢复按 AZ 禁用相关协议，恢复正确转发与容量
失效防线

设备/控制侧健康信号未识别数据面错误；自动化没有用端到端数据面探针验证实际转发。

值班证据
  • 设备/控制侧未触发自动摘除，但探针丢包与特定设备路径相关。
  • 双端流量计数不守恒：入口增长、预期出口没有对应字节。
  • 强制绕开嫌疑设备后即时恢复，是数据面故障的关键反证。
教训：设备或控制侧健康信号不等于数据面正确转发；必须用合成流量、接口计数与端到端可达性驱动摘除。
图谱 · 控制面与 FIB全书 · 路由转发排障 · 数据面

来源：AWS 官方事件总结

↑ 返回顶部

P2 · 对照短卡

14 · P2Cloudflare：BGP term 顺序让 19 个核心站点离线2022-06-21 · 配置顺序就是语义＋
厂商确认

链：新架构 MCP/Clos 站点的站点本地 term 被排到 REJECT-THE-REST 之后 → 关键前缀不再发布 → 19 个大站点离线；这批站点只占约 4% 的位置，却承载约一半请求，小站点过载。03:56 UTC 首个旧架构站点未受影响，06:27 MCP 站点开始受损，06:58 根因明确并回退，07:42 完成。

值班看什么：按站点架构分组的 BGP 宣告差异；前缀数量突然归零；流量从大站点跳到小站点。离线站点还带走主远程管理路径，暴露备份管理通道不足。

图谱 · BGP全书 · 路由转发

来源：Cloudflare 官方复盘

15 · P2GitHub：43 秒网络分区，24 小时数据恢复2018-10-21 · 网络隔离不是短故障＋
厂商确认

链：维护故障 100G 光模块造成东西两地 43 秒分区 → Orchestrator/Raft 在西部与云端形成 quorum 并提升 MySQL 主库 → 两边出现分叉写入；跨国 RTT 又让应用无法直接在西部主库上运行。22:52 UTC 分区，23:19 暂停 webhook/Pages，次日逐步恢复主库、拓扑与积压，整体 24 小时 11 分。

值班看什么：链路 down 时间很短，数据库 role change 与复制拓扑变化却持续；判断恢复完成要看写入权威、复制 lag、任务积压，不是只看链路绿灯。

全书 · 收敛排障 · 双端证据

来源：GitHub 官方复盘

16 · P2Fastly：合法客户配置触发潜伏软件缺陷2021-06-08 · 技术细节有限＋
厂商确认

链：5 月 12 日部署的潜伏 bug → 6 月 8 日一项合法客户配置触发 → 约 85% 边缘网络返回错误。Fastly 1 分钟内发现，10:27 UTC 识别配置，10:36 开始恢复，49 分钟内约 95% 网络恢复，17:25 部署永久修复。

证据边界：官方没有公开具体路由或数据面机制，因此本例只用于讲配置 blast radius 与快速停用路径，不把它写成 BGP 事故。

排障 · 先划故障域

来源：Fastly 官方总结

17 · P2Google europe-west2-a：ACL 让控制面失去 leader2020-12-09 · canary 没有生产旧状态＋
厂商确认

链：仍被生产使用的 ACL 权限被删除 → 网络控制 leader 无法访问锁/选主系统 → fail-static 到期，BGP peering 撤销并隔离可用区。18:29 PST 告警并自动停止发布，18:31–19:55 影响，19:30 回滚，19:55 网络恢复；VPN 因另一恢复 bug 更晚。

值班看什么：leader/lock 失败先于 BGP 撤路；canary 因没有遗留生产状态而通过，说明“配置相同”不等于“状态等价”。

图谱 · BGP全书 · 收敛

来源：Google Cloud 官方事故报告

THREAD 03 / 04

DNS 是数据，也是路径

DNS 服务器进程还活着，不代表查询能到达它；路由还在，也不代表签名与缓存仍有效。DNS 的内容、可达路径和运维依赖必须分开观测。

08

Meta：骨干全断，DNS 随 BGP 一起消失

维护命令断开全球数据中心骨干；权威 DNS 边缘因到不了数据中心，主动撤销 anycast/BGP 宣告。

厂商确认外部 BGP/DNS 观测
External symptom

Facebook、WhatsApp、Instagram 的域名无法解析，服务整体不可达；互联网观测到 Meta 权威 DNS 前缀撤销。

时间线

  1. 例行容量评估命令被执行；审计工具本应阻止危险范围，但其 bug 放行。

  2. 数据中心间骨干全部断开，边缘 DNS 健康检查失败并撤销 BGP。

  3. 主网络、远程管理与部分内部工具共因失效，工程师必须到现场恢复。

  4. 骨干恢复后分阶段拉起服务，避免缓存、流量和供电瞬时回灌。

网络根因链

现象递归解析返回 SERVFAIL；直连不可达/超时，服务像从互联网消失
触发危险维护命令被审计工具 bug 放行
放大全球骨干全断；DNS 健康联动撤路；主网/OOB/工具共享故障域
恢复现场恢复骨干，再受控恢复 DNS 与服务
失效防线

命令审计是唯一门；DNS 健康把“到不了后端”转换成“全网撤路”；带外管理和内部工具没有真正独立。

值班证据
  • 对递归器查询直接 SERVFAIL 并被负缓存放大（dig @1.1.1.1 facebook.com）；委派记录其实仍在 .com TLD 上，需直问 TLD 服务器（dig @a.gtld-servers.net facebook.com NS）才能看到。
  • BGP collector 同时看到权威 DNS 前缀撤销。
  • DNS anycast 前缀在 BGP collector 上消失；部分应用前缀仍在表内，但到数据中心的路径不通。
教训：DNS 的可达性、后端依赖和管理路径不能共用同一个全球骨干故障域；恢复过程本身也需要流量预算。
图谱 · DNSRFC 1035 · 首部图谱 · BGP排障 · dig

来源：Meta 官方技术复盘 · Cloudflare 外部观测

↑ 返回顶部
09

Cloudflare 1.1.1.1：沉睡 38 天的拓扑错误全量撤路

生产 resolver 前缀被误绑到预生产 DLS；一次测试位置变更触发全局刷新，把拓扑缩成单个离线位置。

厂商确认
External symptom

直接使用 1.1.1.1 / 1.0.0.1 的 UDP、TCP 与 DoT 用户大面积解析失败；使用不同地址的域名式 DoH 多数未受同样影响。

时间线

  1. 错误拓扑引用进入配置，但尚未触发全局计算。

  2. 测试位置下线触发刷新；resolver 流量全球下降。

  3. 事故建立并开始回滚；路由先恢复约 77%。

  4. 剩余节点的本地 IP binding 加速重建，流量完全恢复。

网络根因链

现象直接 IP 的公共 DNS 全球失败
触发测试位置状态变更触发全局拓扑刷新
放大旧错误把生产前缀归到单一离线服务；BGP 全撤，部分主机又删 IP binding
恢复回滚拓扑 + 重建主机地址绑定
失效防线

非生产对象能够引用生产全局前缀；配置没有验证“前缀×位置”的基数；回滚只覆盖路由层，未完整覆盖节点绑定层。

值班证据
  • 全球 BGP collector 看到 1.1.1.0/24 等前缀撤销。
  • dig @1.1.1.1 超时，而基于其他 IP 的 DoH 仍成功。
  • 路由重宣告后只恢复约 77%，提示本地接口/binding 仍缺失。
教训：“回滚成功”不是恢复完成；需同时验证控制面前缀、边缘主机地址绑定与真实 DNS 查询。
图谱 · DNS全书 · DNS图谱 · BGP排障 · DNS

来源：Cloudflare 官方详细复盘

↑ 返回顶部

P2 · 对照短卡

18 · P2Cloudflare Resolver：根区数据在，DNSSEC 时间却过期2023-10-04 · DNS 是有时效的数据＋
厂商确认

链：根区加入 ZONEMD 记录 → 边缘 presentation-format 解析器不识别该 RR → resolver 一直使用 9 月 21 日根区副本 → 对应 RRSIG 在 10 月 4 日 07:00 UTC 到期，验证返回 SERVFAIL。08:03 建立事故；08:50 的 stale override 因节点间标签不传播而失败；10:30 停止本地静态根区预载，10:32 恢复。

值班看什么：dig +dnssec 的 SERVFAIL 与签名过期时间吻合；比较开启/绕开 DNSSEC 验证；检查根区 serial、RRSIG inception/expiration，而非只测 53 端口通不通。

RFC 1035 · DNS 报文图谱 · DNS排障 · dig

来源：Cloudflare 官方复盘

19 · P2Akamai：Secure Edge CDN 的 DNS 组件配置回退2021-07-22 · 不等于整个 Edge DNS 宕机＋
厂商确认

链：软件配置更新触发 Secure Edge CDN 内 DNS 组件缺陷 → 约 15:45 UTC 起部分客户域名不可达 → 回滚配置，约一小时内恢复。官方明确影响的是该 CDN 组件，不应扩大表述为 Akamai 全部权威 DNS 服务失效。

证据边界：公开报告没有更细的 DNS 协议机制；值班上可对比受影响产品/域名委派、权威响应和不同网络探针，先划定产品故障域。

全书 · DNS排障 · DNS

来源：Akamai 官方说明

THREAD 04 / 04

拥塞会吃掉救援工具

当生产流量、重试、遥测和配置分发共用路径时，事故不只降低服务容量，还会降低组织修复事故的能力。

10

Google Cloud：控制面批量停摆，剩余骨干被挤爆

维护自动化跨物理地点同时 deschedule 网络控制面；fail-static 到期后撤路，剩余容量不足一半。

厂商确认
External symptom

多个区域同时高丢包与不可达；诊断、配置重建和分发工具也被困在同一个拥塞网络里。

时间线

  1. 维护事件启动；11:47–11:49 多区域丢包出现并告警。

  2. 定位根因并停止维护自动化。

  3. 重建后的网络配置开始下发。

  4. 容量开始恢复，最终全面恢复；区域影响约 3 小时 19 分至 4 小时 25 分。

网络根因链

现象多区域丢包，恢复动作迟缓
触发两个错误配置叠加维护软件 bug，跨故障域停掉控制面
放大fail-static 到期撤路；剩余容量不足一半并拥塞，救援流量也受阻
恢复停自动化、重启控制面、重建配置并做服务侧导流
失效防线

调度器没有理解物理故障域；fail-static 窗口短于人工恢复；控制配置与修复工具依赖被修复的网络。

值班证据
  • BGP withdrawal 在 fail-static 到期后分批出现。
  • 链路未必 down，但剩余路径利用率、队列与丢包同时升高。
  • 配置下发、监控采集延迟与客户错误同向恶化。
教训：拥塞时必须为控制流量保留并验证最低容量；维护系统要按独立物理故障域限速。
全书 · 路由收敛全书 · 拥塞控制全书 · RTT/RTO

来源：Google Cloud 官方详细报告 · Google Cloud 官方摘要

↑ 返回顶部
11

AWS us-east-1：建连洪峰与重试风暴锁死内部网络

自动扩容触发内部客户端异常建连，压垮基础服务网与主 AWS 网之间的路由/NAT 设备。

厂商确认
External symptom

控制面 API、内部 DNS、监控与部署同时高延迟/错误；延迟触发更多连接与重试，拥塞进入正反馈。

时间线

  1. 自动扩容触发异常连接激增；07:33 控制面 API 开始异常。

  2. 内部 DNS 迁离拥塞路径后恢复，但网络仍未完全恢复。

  3. 拥塞显著改善，上层服务开始处理积压。

  4. 网络设备恢复；部分服务继续清理 backlog。

网络根因链

现象控制面与观测系统一起变慢
触发自动扩容撞上多年未显现的客户端建连行为
放大连接洪峰压垮有状态设备；超时导致更多重试尝试，放大负载，监控/部署共因失效
恢复迁移 DNS、隔离重流量、禁用高流量服务并扩充容量
失效防线

（分析推断）疑似容量主要按带宽而非连接速率、PPS 与状态表规划，客户端重试缺少足够退避与 jitter——官方未明确；救援工具没有独立路径。

值班证据
  • （分析推断）新连接/秒和 NAT 状态占用先于 bps 打满。
  • 延迟、超时与重试曲线形成同频上升的正反馈。
  • 迁移 DNS 后解析先恢复，但 API 仍错误，证明不止 DNS 一层。
教训：重试是倍增器；必须有总预算、指数退避、jitter 与熔断，并把控制/监控通道从生产拥塞域中隔离。
全书 · 拥塞控制全书 · RTT/RTO图谱 · UDP 与应用重试

来源：AWS 官方事件总结 · AWS Builders' Library · 退避与抖动

↑ 返回顶部
12

Microsoft Azure：一次路由器操作触发全球 WAN 重算

马德里路由器上的计划操作具有全局语义，引发 IGP 邻接/FIB 重算和 BGP 重宣告；33 分钟后又在第二台重复。

存档材料 · 非官方 PIR 镜像ThousandEyes 观测
External symptom

Azure、Microsoft 365 与 ExpressRoute 全球高延迟/超时；路由撤销和重宣告呈现清晰的两波抖动。

时间线

  1. 第一台路由器操作后影响开始；07:11 网络告警。

  2. 因执行者未获得正确的 safe-deployment 反馈，同一操作在第二台设备重复。

  3. 回滚后区域陆续恢复，核心网络设备稳定。

  4. 残余丢包与上层服务尾部继续清除。

网络根因链

现象全球 WAN 高延迟、丢包与 BGP churn
触发单设备 IP/IGP/BGP 集成操作执行了全局语义命令
放大全网 IGP/FIB 重算；告警反馈缺口让第二台重复，形成第二波
恢复停止操作、回滚并等待 IGP/BGP 与设备稳定
失效防线

AAA 只限制“在哪台设备执行”，没有限制命令的全网效果；多厂商语义差异未充分仿真；执行者看不到端到端告警。

值班证据
  • BGP collector 的 withdrawal/announcement 速率出现两次尖峰。
  • 丢包与路径变化跨区域同步，而非局限马德里。
  • IGP adjacency、FIB programming 时间与外部探针故障窗口对齐。
教训：首台变更必须等端到端数据面验证通过才继续；命令授权要考虑语义爆炸半径，而非只看设备范围。
全书 · OSPF/IGP全书 · BGP全书 · 收敛图谱 · OSPF

来源：Azure 官方状态历史 · 2023-01-25 · Azure PIR 非官方 PDF 存档 · ThousandEyes 外部观测

↑ 返回顶部

P2 · 对照短卡

20 · P2Cloudflare–AWS：双方流量工程互相放大2025-08-21 · PNI 满载与恢复振荡＋
厂商确认 · Cloudflare

链：单一客户从 us-east-1 发起巨大缓存请求，使 Cloudflare 回 AWS 的流量翻倍并填满 PNI → AWS 撤销前缀试图卸载，流量转到异地/DCI 路径；其中一条链路已故障，剩余容量减半 → 双方独立 TE 循环继续改路并放大丢包。16:27 UTC 流量激增，17:22 影响扩大，19:05 Cloudflare 加客户级限流，19:27 稳定 TE，19:45 恢复宣告，20:18 清完尾部。

值班看什么：PNI 接口利用率与丢包；BGP withdrawal 后流量是否真的下降，还是转到更差的 DCI/transit；按客户拆分流量，避免把总量误当自然增长。

全书 · 拥塞控制图谱 · BGP排障 · 路由路径

来源：Cloudflare 官方复盘

五个微练习

先在脑中画路由表、故障域或反馈环，再点开答案。重点不是背结论，而是练习当班时先验证哪条证据。

EX 01想一想：/22、/24、/25 同时存在，路由器先选谁？＋
答案：先做最长前缀匹配，/25 优于 /24，/24 优于 /22；只有在前缀长度相同的候选之间，才继续比较 BGP best-path 属性。现实里很多公网过滤长于 /24 的 IPv4 路由，所以 /25 不一定到得了所有 AS。回看 YouTube 案例，原理见 CIDR/LPM 与 路由转发。
EX 02想一想：远端路由 local-pref 200，本地服务路由 100，会发生什么？＋
答案：在同一 BGP 决策域里，高 local-pref 候选优先，站点可能把本该本地处理的流量送向远端；远端容量不足就形成吸流热点。值班先看“哪些前缀的 best next-hop 同时改变”，而不是先重启服务。回看 Cloudflare 2020，原理见 BGP 协议卡。
EX 03想一想：控制面显示正常，为什么用户仍会丢包？＋
答案：控制面健康信号不等于数据面正确转发；即便一般场景中 BGP session 是 Established，也只能证明邻居还能交换路由，FIB 编程、下一跳解析、ASIC、ACL、队列或物理出口仍可能错误。应发端到端合成流量，核对入口/出口计数和实际路径，并测试绕开嫌疑设备。AWS Tokyo 只用于说明设备/控制侧健康信号可能未识别数据面错误，不据此断言当时 BGP 始终 Established；原理见 控制面与 FIB、路由排障。
EX 04想一想：DNSSEC 验证失败与 DNS 前缀撤路，dig 现场有何不同？＋
答案：要先区分撤掉的是哪类前缀：①递归器前缀撤路（如 1.1.1.1）时，发往该递归地址的包通常超时/无路由，换到其他可达 resolver 有效；②权威 DNS 前缀撤路（如 Meta）时，所有递归器通常都联系不到权威，换 resolver 通常无效，除非新 resolver 仍有可用的正缓存。DNSSEC 验证失败时网络可达，验证 resolver 常返回 SERVFAIL，+dnssec 可看到签名并检查过期时间，关闭验证的对照 resolver 可能仍返回数据。故障域分别是特定递归服务、权威可达性与验证链。对照 Meta 撤路、1.1.1.1 撤路与 Cloudflare 签名过期；原理见 DNS 与 BGP。
EX 05想一想：一次超时后所有客户端立刻重试，为什么恢复会更慢？＋
答案：超时让请求从系统里消失了吗？没有；立即重试会把原负载乘上次数，并让客户端在同一超时边界同步，继续填满队列与 NAT/连接状态。应限制总尝试次数、做指数退避与随机 jitter，并在过载点熔断。回看 AWS 重试风暴，原理见 拥塞控制 与 应用自行重试。