路由泄露会让流量走上不该走的路径。Cloudflare 过去多次记录过 BGP 路由泄露事件，这类事故会让流量经过未经授权的网络路径。BGP 路由依赖自治系统（AS）之间的关系驱动，分为客户-提供商和对等两种。客户付费给提供商换取互联网接入，对等方之间通常是免费互换流量。这些关系定义了路由规则，决定哪些路径合理。例如，从提供商或对等方学到的路由只能向下游客户发布，不能回传给另一个提供商或对等方。这条规则表达了互联网路由的预期行为，违反它就是路由泄露。
历史方案的局限
过去每个网络都要自己实现这套规则，用复杂且容易出错的路由策略配置。RFC 9234（《使用 UPDATE 和 OPEN 消息中的 Role 预防和检测路由泄露》）直接在协议内部表达这种预期。它引入了新的 BGP Role capability，要求两个 BGP 邻居在会话建立时就确认彼此的关系，并引入 Only to Customer（OTC）路径属性标记那些不得向上游或对等方传播的路由。理解 OTC 的路由器可以自主拒绝泄露路由，不需要运维人员手写策略。
Cloudflare 的实测方法
Cloudflare 利用全球对等网络，开发了一套独特的方法来追踪 BGP Role 配置的部署情况，监控哪些对等 AS 会向 Cloudflare 发送 OTC 属性。测试过程中发现了一个意外现象：两个大型 Tier-1 网络会从转发的路由中剥离 OTC 属性。Cloudflare 正在与这两个 Tier-1 网络沟通，希望它们允许 OTC 属性通过，这对 RFC 9234 的早期采用者启用路由泄露预防能力至关重要。
BGP Role 和 OTC 属性的工作原理
路由泄露是指路由通告超出了预期范围，这个范围由 AS 关系决定。RFC 7908 给出了明确定义。规则是不对称的，关键在于方向。路由可以自由向下游传播，提供商可以把路由表中的任何路由给客户。但向上游或横向传播受限，AS 只能向上游或对等方发送自己发起的路由，以及从自己客户那里学到的路由。
当一个 AS 把从提供商或对等方学到的路由发给另一个提供商或对等方时，路由泄露就发生了。路由先向下走再向上走，在层级结构中形成一个”谷底”，这种形状是底层关系从未授权的。路由路径必须是无谷的（valley-free）。
违反无谷特性有多种形式。常见的一种是客户把路由在两个提供商之间发布，也叫发夹弯。这对所有人都不利：客户没有收费就在提供商之间传输流量，而且可能没有足够容量承载这些流量。
两个 Tier-1 网络的意外行为
Cloudflare 测量发现，两个 Tier-1 网络会剥离 OTC 属性。这意味着即使下游网络正确配置了 BGP Role 并标记了 OTC，经过这两个 Tier-1 网络后，OTC 标记会丢失。这削弱了 RFC 9234 的防护效果，因为下游网络无法再依靠 OTC 属性判断路由是否应该被拒绝。
Cloudflare 正在与这些网络沟通，推动它们修改配置以保留 OTC 属性。对于已经部署 RFC 9234 的网络来说，这个问题的修复会直接提升路由泄露预防的覆盖范围。
如何在自己的网络启用 BGP Role
RFC 9234 的部署需要在 BGP 会话配置中明确声明每个邻居的关系类型。路由器会在 OPEN 消息中协商 BGP Role，双方必须对关系达成一致才能建立会话。配置完成后，路由器会自动在向客户发送的路由中添加 OTC 属性，并在收到带有 OTC 的路由时检查是否来自客户。如果来自提供商或对等方，路由器会拒绝这条路由。
这套机制把路由泄露检测从运维人员的策略配置中移到了协议本身，降低了配置错误的风险。对于早期采用者，确认上游网络不会剥离 OTC 属性是部署成功的关键。