标签 RFC7908 下的文章

这是一场典型的“看起来只是删了几行配置，实际把闸门拆了”的事故。

2026 年 1 月 22 日，Cloudflare 在美国迈阿密（Miami）的一个数据中心路由器上，因为自动化路由策略配置错误，把一部分原本只该在内部传播的 IPv6 BGP 前缀意外对外宣告了出去，形成 BGP Route Leak（路由泄漏）。事故持续 25 分钟，导致迈阿密骨干链路拥塞、部分客户流量丢包/延迟升高，同时还把一些外部网络的流量“误导”进迈阿密，最终被 Cloudflare 的防火墙过滤规则丢弃（峰值丢了约 12Gbps 入口流量）。

听起来像网络圈的“蝴蝶效应”：你只是在路由策略里挪了一块砖，结果半个街区的车流都改道了🚧。

什么是 Route Leak：

不是“断网”，是“指错路”

路由泄漏的本质非常直白：某个 AS 告诉整个互联网：来我这走，我能带你到终点——但它其实不该这么说。

BGP 里有个“潜规则”：从上游（provider）和对等（peer）学到的路由，不能再转发给另一个 peer 或 provider，否则就违反所谓的 valley-free routing。一旦违反，流量会被吸到不该承载它的网络上，轻则拥塞、抖动，重则大范围不可达。

image

这次事故就是类似的“指路牌摆反了”：Cloudflare 在迈阿密把从一些 peer 学到的路由，又转手“推销”给了其他 peer 和 transit provider，属于 RFC7908 里提到的多种 route leak 类型混合体（简单理解：该往下游走的路，被错误地往上/平行扩散了）。

时间线：从合并代码到止血，只花了 25 分钟（但足够难受）

这次节奏很“现代工程化”：代码合并 → 自动化跑配置 → 线上立刻出事 → 人肉回滚止血 → 再回滚代码。

Time (UTC)Event
2026-01-22 19:52 UTC触发路由策略 bug 的变更合并进网络自动化代码仓库
2026-01-22 20:25 UTC自动化在迈阿密单台边缘路由器运行，开始向 transit/peer 异常宣告（IMPACT START）
2026-01-22 20:40 UTC网络团队开始排查迈阿密的异常 BGP 广告
2026-01-22 20:44 UTC事故升级，开始协同处置
2026-01-22 20:50 UTC操作员手动回滚坏配置，并暂停该路由器的自动化（IMPACT STOP）
2026-01-22 21:47 UTC触发泄漏的代码提交被回滚
2026-01-22 22:07 UTC确认自动化恢复健康，可重新在迈阿密路由器运行
2026-01-22 22:40 UTC迈阿密单台路由器解除自动化暂停

“删掉 Bogotá 的前缀”怎么删成了“全都放行”？

事故起点其实很合理：Cloudflare 之前会把一部分 IPv6 流量经迈阿密转发到哥伦比亚波哥大（Bogotá）数据中心，但随着基础设施升级，这个绕路不需要了，于是要把 Bogotá 相关前缀从迈阿密撤掉。

变更 diff 大概长这样（看着很“无害”对吧？）：

[edit policy-options policy-statement 6-COGENT-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-COMCAST-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-GTT-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-LEVEL3-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PRIVATE-PEER-ANYCAST-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PUBLIC-PEER-ANYCAST-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-PUBLIC-PEER-OUT term ADV-SITELOCAL from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-TELEFONICA-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;
[edit policy-options policy-statement 6-TELIA-ACCEPT-EXPORT term ADV-SITELOCAL-GRE-RECEIVER from]
-      prefix-list 6-BOG04-SITE-LOCAL;

问题就出在：把 prefix-list 条件删掉后，策略项的匹配条件变得过于宽松，直接变成了“只要是 internal route-type，我就 accept，然后对外 export”。

policy-options policy-statement 6-TELIA-ACCEPT-EXPORT {
    term ADV-SITELOCAL-GRE-RECEIVER {
        from route-type internal;
        then {
            community add STATIC-ROUTE;
            community add SITE-LOCAL-ROUTE;
            community add MIA01;
            community add NORTH-AMERICA;
            accept;
        }
    }
}

这里有个 JunOS/JunOS EVO 的坑点：route-type internal 会匹配所有非 external 的路由类型，包括 IBGP 学到的内部路由。于是本来只想“内部可见”的 IPv6 前缀，被这条 export policy 直接放行对外广播了。

一句话：原来靠 prefix-list 当“门禁”，删了门禁后，剩下的条件相当于“只要你是小区住户，就能把快递站里的所有包裹搬出去”——策略写得再“优雅”，accept 一落地就成了事故开关🔘。

影响面：拥塞、丢包、延迟上升，还顺带“误伤”外部网络

当迈阿密开始对外宣告这些不该宣告的 IPv6 前缀后，互联网路由收敛会让部分流量被吸到迈阿密。结果就是：

  • 迈阿密—亚特兰大骨干链路出现拥塞，导致一些 Cloudflare 客户流量出现更高的延迟/丢包
  • 被泄漏的前缀所属网络（外部网络）的一部分流量也被引向迈阿密，但 Cloudflare 路由器的防火墙过滤器只允许 Cloudflare/客户相关前缀的流量，导致这部分流量被丢弃（峰值约 12Gbps）

image

image

同时，路由泄漏的证据也能在路由收集器的历史数据里看到，比如这段 monocle 检索结果（注意 AS path 中 Cloudflare AS13335 出现在不该出现的位置上）：

➜  ~ monocle search --start-ts 2026-01-22T20:24:00Z --end-ts 2026-01-22T20:30:00Z --as-path ".*13335[ d$]32934$*"
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f077::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f091::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f16f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f17c::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f26f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f27c::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113609.854028|2801:14:9000::6:4112:1|64112|2a03:2880:f33f::/48|64112 22850 174 3356 13335 32934|IGP|2801:14:9000::6:4112:1|0|0|22850:65151|false|||pit.scl
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f17c::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f27c::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113583.095278|2001:504:d::4:9544:1|49544|2a03:2880:f091::/48|49544 1299 3356 13335 32934|IGP|2001:504:d::4:9544:1|0|0|1299:25000 1299:25800 49544:16000 49544:16106|false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f091::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f17c::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
A|1769113584.324483|2001:504:d::19:9524:1|199524|2a03:2880:f27c::/48|199524 1299 3356 13335 32934|IGP|2001:2035:0:2bfd::1|0|0||false|||route-views.isc
{trimmed}

别再迷信“自动化=不会错”

这次事故最扎心的一点是：自动化没有坏，坏的是策略生成逻辑里那个“空条件”缺口。自动化把错误放大得更快、更一致、更“全自动”，所以也更需要“刹车系统”。

Cloudflare 的改进方向很有代表性，基本可以当成网络自动化团队的“安全 checklist”：

  • 立刻修补路由策略自动化里导致错误放行的缺陷，并在同类风险点上补洞
  • 在路由策略里加更强的基于 BGP community 的防护：对外 export policy 上明确拒绝“来自 peer/provider 的路由”
  • 在 CI/CD 里做自动化策略评估：重点抓“空/错误的 policy term”（像这次就是删 prefix-list 后 term 还 accept）
  • 提前告警：更早发现配置异常与自动化变更的负面效应
  • 更长期的路由安全：验证并推进 RFC9234（BGP Roles / Only-to-Customer）等机制，从“协议能力”层面降低本地 AS route leak 的概率
  • 促进 RPKI ASPA 之类能力的采用，让异常 AS path 更容易被自动拒绝

结语

网络世界最怕的不是“改配置”，是“改配置还以为没事”😅

这场 25 分钟的泄漏，杀伤力并不靠持续时间，而靠 BGP 的传播速度 + 流量的惯性。更现实的是：只要系统允许“内部路由被 accept 并 export”，那就等于把“内部车道”直接连到了高速入口——迟早会堵。

真正能让系统更稳的，不是“以后小心点”，而是工程化地把风险钉死：

  • 关键策略项不能出现“条件被删空但仍 accept”
  • 对外 export 必须能识别并拒绝来自 peer/provider 的路由
  • 自动化要配“策略单测 + 变更评估 + 审计与回滚”三件套

毕竟，互联网的路由不是你家路口的指示牌，摆歪了，整座城市都可能跟着绕路。😵‍💫

喜欢就奖励一个“👍”和“在看”呗~

image