Shikanoko Networks (SKNK)
返回技术博客

SKNK 中文技术指南

什么是 BGP 路由泄露？路由公告如何越出它的传播边界

BGP 路由泄露是指路由公告被传播到了它本不该到达的路由策略边界之外。本文解释泄露如何发生、它和劫持有何不同，以及网络运营者如何检测和降低风险。

什么是 BGP 路由泄露？路由公告如何越出它的传播边界

2026 年 1 月 22 日，Cloudflare 的一个路由策略自动化平台做了一次再普通不过的变更。本来只是想停掉从迈阿密机房往波哥大机房转发的一批 IPv6 前缀的公告，结果迈阿密那台边缘路由器，把从 Peer 学来的 IPv6 路由，一股脑重新发布给了别的 Peer 和上游 Transit Provider。Cloudflare 事后发了一份详细的复盘报告。

后面的事发生得很快。那些本来没理由把流量送进迈阿密的网络，开始把流量往那边倒。链路拥塞、延迟拉高、丢包跟着来——峰值时有大约 12 Gbps 的入站流量被防火墙当成不该来的流量直接扔掉。整个泄露持续了大概 25 分钟。

重点不是 Cloudflare 犯了个错。重点是：一个局部的 Export Policy 错误，是怎么够到几百公里外的网络、让从没碰过那台路由器的人一起遭殃的。

白脸小鹿试图把越过策略闸门的路由公告拉回来。

路由泄露的起点，往往是一条公告越过了原本应该守住的边界。

BGP 路由泄露，就是路由公告被传播到了它本不该到达的路由策略边界之外。

定义。 路由泄露是一种路由策略失效：某个网络把学到的路由，公告给了一个不在该路由预期传播范围内的邻居或方向。

这篇文章会讲清楚：泄露到底是什么、为什么 BGP 会照单全收还接着传、它和劫持差在哪、RPKI 到底管不管得了这事，以及运营者该怎么检测、怎么把风险压下去。

1. 到底什么是 BGP 路由泄露

拆开来看，就三步：

  1. 一个网络从上游或 Peer 那儿学到一条路由；
  2. 它又把这条路由发给了不该收到它的邻居；
  3. 路由就此越出了原本的路由策略范围。

RFC 7908 第一次给"路由泄露"下了可用的定义，说的正是这个意思。关键边界是传播范围，不是这条路由由哪个 ASN 起源。

三个概念很容易被搅在一起，先钉死它们的区别：

  • 路由泄露（Route Leak）——路由被传到了范围之外，起源本身可能完全合法。
  • BGP 劫持（Hijack）——有网络起源了一个它没权利起源的前缀，问题出在起源 ASN。
  • 路由撤回（Withdrawal）——公告凭空消失了，问题出在可达性。

这是三种不同的故障，要三种不同的应对。把它们混为一谈，运营者就会去修那个根本修不对的地方。

2. BGP 不只是一张"路径表"，它还是一套路由策略系统

很多人把 BGP 想成一个选路引擎：交换路由、挑 AS_PATH 最短的、完事。但它从来不是这么工作的。BGP 是在路径交换机制之上叠出来的一套路由策略系统。

一个网络接受哪些路由、公告哪些路由、优先选哪条，全由商业关系——客户、上游、Peer——以及 Local Preference、AS_PATH 这些本地属性决定。关键就在这里：当你的 Export Policy 写错了，邻居是不知道的。它收到的是一条语法上完全合法的 BGP Update，然后用自己的本地策略去评估它——而这条被泄露的路由，很可能反而更受欢迎。

这才是最反直觉的地方。一条被误泄露的路由，可能看起来比合法的还"好"。一个平时靠上游 Transit 才能到达某前缀的网络，突然冒出来一条"客户路由"指向同一前缀——而客户路由通常优先级最高。于是这条泄露路由被装上、被继续往下传。

结论很直接：AS_PATH 最短，不等于这条路径最安全、最正确。 它只是某套本地策略眼里的"最便宜"而已。

正常：
客户 → 上游 → 互联网

错误：
Peer → 客户 → 上游

箭头表示的是路由公告的传播方向——谁把路由公告给了谁，而不是数据包的走向。这两者经常被搞混，后面所有内容都建立在分清它的基础上。

注意，这里的"正确"跟物理距离没关系。它说的是：这条传播，是否符合关系双方当初说好的边界。

3. 路由公告的"预期范围"到底是什么

想理解什么叫"越界"，先得认全 BGP 网络之间的四种关系：

  • Customer（客户）——掏钱买另一家网络的 Transit。
  • Transit Provider（上游）——卖 Transit，通常把所有路由公告给客户。
  • Peer（对等）——规模相近的网络之间免费交换流量。
  • Sibling（兄弟）——同一主体或同一管理下的两个网络。

简化版的传播逻辑，长这样：

  • 从 Provider 学到的全局路由，通常不该再发给另一个 Provider 或 Peer；
  • 从 Peer 学到的路由，通常只该发给自己的 Customer；
  • 你自己的路由和 Customer 的路由，才是传播范围最宽的。

但这不是一条放之四海皆准的铁律。真实网络里有各种例外——部分 Transit、付费 Peering、复杂合同、地区差异。所以措辞得留余地：通常、一般、预期路由策略、取决于具体关系。AS_PATH 能给你关于路径的观察证据，但它本身没法证明两个 ASN 之间到底是什么商业关系。

白脸小鹿把路由切换到预期路径，同时让一条侧向路径停在闸门后面。

网络关系决定了一条学到的路由通常应该沿哪条路径继续传播。

4. 路由泄露最常见的四种形态

RFC 7908 分了六类。为了好读，这里只讲你大概率会撞上的四种，完整六类放在文末参考里。

4.1 上游到上游的"发夹弯"（Hairpin）

多上游网络从 Provider A 学到路由，又把它发给 Provider B。

路由从哪里学到： Provider A
路由被发到哪里： Provider B
为什么不对劲：   上游的路由通常只该留在你自己网内。

这就是经典的"发夹弯"（RFC 7908 的 Type 1；若在 Peer 之间横向发生，则是 Type 2）。

4.2 把上游的路由发给 Peer

网络把从 Transit Provider 学到的路由，发给了自己的 Peer（Type 3）。

路由从哪里学到： Transit Provider
路由被发到哪里： Peer
为什么不对劲：   Peer 通常只预期收到你的客户路由。

4.3 把 Peer 的路由发给上游

网络把从 Peer 学到的路由，往上发给了自己的 Transit Provider（Type 4）。

路由从哪里学到： Peer
路由被发到哪里： Transit Provider
为什么不对劲：   上游自己本来就能到达那个 Peer 的客户。

2026 年 1 月 Cloudflare 那次，就是这两种的混合——从 Peer 学到的路由，同时被重新发布给了 Peer 和 Provider。

4.4 内部前缀或更具体前缀泄露

内部前缀、测试前缀，或者更具体的前缀，被误发到了公网（Type 6）。

路由从哪里学到： 内部网络（iBGP、静态或重分发）
路由被发到哪里： 公网 BGP 邻居
为什么不对劲：   这些前缀从来就不该离开这个网络。

迈阿密那次背后的配置 bug 涉及内部重分发的路由，但 Cloudflare 把观察到的公网泄露归类为 Type 3 和 Type 4 的混合——route-type internal 匹配过宽是触发点，不等于公网传播分类就是 Type 6。

5. 一次泄露是怎么滚成全网事故的

泄露不会停在原地。它靠一连串各自独立的决策滚雪球：

  1. 错误路由被发出去；
  2. 邻居接受它——因为 BGP Update 里没有任何字段在说"这条是错的"；
  3. 邻居的本地策略选中它，有时还压过了合法路径；
  4. 邻居又把它往下传；
  5. 流量被吸到一个既没容量、防火墙策略又不对的网络；
  6. 拥塞、丢包、延迟升高，或者部分不可达。
时间 事件
T0 路由策略变更上线
T1 出现预期之外的 BGP 公告
T2 邻居网络接受这些路由
T3 流量转向泄露路径
T4 运营者发现、回滚、确认恢复

有两句话得说在前头，免得被带偏。第一，不是每次泄露都会造成全球中断——影响范围取决于前缀、传播多远、路径选择、网络容量和过滤策略。第二，小网络恰恰可能因为"吸来了它根本扛不住的流量"而成为事故中心。2015 年马来西亚电信（Telekom Malaysia）就是活教材：一家区域 ISP 把约 17 万条路由泄露给了大型上游 Level3，后者接受并继续往下传播，最后影响波及全球。

白脸小鹿正在拧紧阀门，大量空白路由卡片已经涌向一间小型网络机房。

局部的 Export Policy 错误，可能把超出接收网络承载能力的流量引过去。

6. 泄露 vs 劫持 vs 撤回

事件 核心问题 起源 ASN RPKI 结果 典型信号
路由泄露 路由越出预期范围 可能仍合法 可能仍是 Valid 意外的 AS 关系或路径
BGP 劫持 错误网络起源了前缀 往往未授权 若被 ROA 覆盖可能 Invalid 意外的起源 ASN
路由撤回 公告消失 不适用 未必相关 前缀可见性下降

有四点必须强调，绝大多数误解都出在这：

  • RPKI Valid 不代表整条路径安全。 RPKI 验证的是起源，不是路由本身。
  • RPKI Invalid 不等于就是恶意攻击。 也可能是操作失误，或者 ROA 没更新。
  • 泄露和劫持可以同时发生。 被劫持的前缀，还能在路径上被继续泄露。
  • 单一公网观测点证明不了全球可达性。 没有多个 vantage point，别急着下结论。

7. 站在外面，你能看到什么

你读不到泄露网络的配置。你能观察到的，分两类——BGP 信号和流量遥测——它们回答的是不同的问题。

BGP 信号（路由系统告诉你的）：

  • AS_PATH 里冒出了一个不符合预期的网络关系；
  • 某个 ASN 突然公告了一大堆新前缀；
  • 更具体的前缀突然出现；
  • 多个地区的路由可见性同时变化；
  • BGP Update 数量在短时间内异常飙升。

流量遥测（你在数据面测到的）：

  • 流量突然集中到一个没能力承载的网络。

这两者互补，但不能互相替代。AS_PATH 异常是从 BGP 流里读出来的路由信号；流量涌向一个没准备好的网络，是你另外从流量侧量出来的后果。别拿一个去冒充另一个。

简化版 AS_PATH 对比：

预期：
AS64500 → AS64501 → AS64502

意外：
AS64500 → AS64501 → AS64510 → AS64502

多出来的那一跳 AS64510，是线索，不是实锤。

异常的 AS_PATH 是调查的证据，不是泄露的实锤。关系数据本身可能不全，也可能是错的。

Cloudflare 自己的检测流水线，把这一点讲得很明白。它把 AS 关系推断（CAIDA 加上自建数据，细到 per-prefix、per-peer 粒度）和 AS Hegemony 数据合在一起压低误报，再把单条公告聚合成"泄露事件"。原材料是 RouteViews 和 RIPE RIS 的 BGP 数据——几十个 collector，一天大约 20 亿条 BGP 消息。即便堆了这么多料，最后给出的也只是一个可能性，不是判决。

白脸小鹿正在检查路由线上的额外环路，远处几个观测点从不同方向观察它。

异常路径是调查线索；多个观测点拼出来的图景才更可靠。

8. 怎么防、怎么发现、怎么收场

分三层：预防、检测、响应。

预防

  • 出口默认拒绝——用白名单，别用黑名单；
  • 每个 Customer、Peer、Provider 各用一套独立的前缀过滤器；
  • 每条会话都设合理的 Maximum Prefix Limit——它限制的是路由数量，能拦住大规模泄露，但本身判断不了传播关系对不对；
  • 配置变更走 Review、Canary、Rollback；
  • Route Server 用单独、明确的策略；
  • 视需要开启 First-AS 检查和关系校验。

检测

  • 监控 BGP Update 和 AS_PATH 变化；
  • 从多个 Route Collector 或 Looking Glass 观察；
  • 记录前缀数量、起源 ASN 和可见性；
  • 对突然出现的更具体前缀设置告警；
  • 维护历史路由基线做对照。

响应

  • 先停掉继续传播；
  • 撤回错误路由；
  • 恢复原来的策略；
  • 检查邻居是否还在继续传播旧路径；
  • 从多个外部观测点确认恢复；
  • 记录时间线和根因。

9. RPKI 能做什么、不能做什么

RPKI 很好用，但它有明确的分工——而防路由泄露不在它的分工里。

RPKI 能做的：

  • 验证某个 ASN 是否被授权起源某个前缀；
  • 帮接收方识别一部分错误起源；
  • 降低常见 Origin Hijack 的影响。

RPKI 单独做不了的：

  • 验证不了完整 AS_PATH；
  • 判断不了一条路由是不是发给了错误的 Peer；
  • 保证不了一条路由一定被全球接受；
  • 替代不了 Export Filter、Max-Prefix 或运营监控；
  • 自动解决不了所有路由泄露。

真正冲着"传播"这一侧去的机制，还在路上。RFC 9234 的 BGP Roles 和 Only-to-Customer（OTC）属性，让邻居把彼此的关系写进路由里，一旦路由往错误方向流动就能被识破。ASPA（自治系统上游授权）能让网络声明自己的授权上游，别的网络据此拒绝违反关系的路径——但 ASPA 目前仍是正在制定的 Internet-Draft，不是已经定稿、大规模部署的正式 RFC。这些方向都对，但效果取决于部署——目前普及度还很不均。它们都不是本地路由策略正确性的"即插即用替代品"。

10. 一张实用清单

变更前

  • 每个邻居的角色已确认；
  • 出口前缀列表用默认拒绝；
  • Customer、Peer、Provider 策略互相独立；
  • Maximum Prefix Limit 已设置；
  • 回滚方案已备好；
  • 监控和外部观测点确认可用。

部署后

  • 核对实际发出的前缀；
  • 核对 AS_PATH；
  • 核对路由数量是否异常；
  • 从多个外部观测点复核；
  • 确认没有冒出意外的更具体前缀。

事故中

  • 停止继续传播；
  • 撤回错误路由；
  • 恢复上一版策略；
  • 检查邻居缓存和传播状态；
  • 记录时间线；
  • 确认流量和可见性恢复。

白脸小鹿用插销、仪表和绳结把路由闸门固定好。

多层防护能降低一次策略错误演变成大范围泄露的概率。

11. 常见问题

路由泄露和 BGP 劫持是一回事吗？

不是。泄露主要是传播范围问题，劫持主要是未授权起源问题。

RPKI 能防住路由泄露吗？

单独防不住。RPKI 管的是起源授权，不是完整 AS_PATH，也不是商业关系。

泄露会纯属意外吗？

会，而且很常见。写错的 Export Policy、自动化变更、邻居角色配错，是最常见的起因——Cloudflare 那次就是从一次自动化变更开始的，不是攻击。

小网络能引发大事故吗？

能，只要大网络接受并继续传播它的泄露路由。2015 年马来西亚电信就是现成的例子。

异常的 AS_PATH 能实锤泄露吗？

不能。它只是信号，还得结合关系数据和更多证据。

BGP 会话建起来了，路由就安全吗？

不是。会话健康和路由策略正确是两码事。会话可以是 Up 的，但它执行的策略可能是错的。

结语

路由泄露不是"路由不见了"，而是一次边界失效——一条路由被公告到了它不该去的互联网角落，在那里被相信、被优先、被继续传播。

BGP、商业关系、本地策略，三者共同决定一条路由最终走到哪里。所以一条泄露路由，对下游所有人来说都可以看起来完全合法，同时又是完全错误的。

真正的防护从来不是某一个功能。是出口过滤和前缀上限，是关系校验，是管起源的 RPKI，加上管路径的外部监控——层层叠起来，因为它们各自只覆盖了问题的一部分。

一句话总结

BGP 路由泄露，就是路由公告越出了它预期的路由策略边界——这是 RPKI 单独无法阻止的。

相关阅读

工具

参考来源