Shikanoko Networks (SKNK)
返回技术博客

SKNK 中文技术指南

RPKI、IRR、ROA 到底有什么区别？BGP 路由被拒绝时怎么查

BGP 负责宣告，IRR 负责登记和过滤，RPKI/ROA 负责验证起源授权。本文用对比表、故障现象表和四种状态表，给出路由被拒绝时的优先检查顺序与常见坑。

先记住三句话：BGP 是“我在宣告什么”，IRR 是“登记和过滤什么”，RPKI/ROA 用来验证“谁被授权宣告什么”。 它们经常一起出现在上线清单里，但不是同一个系统，也不能互相替代。

本文不重复 RPKI、ROA、ROV 的基础定义——那些内容见什么是 RPKI？和什么是 ROA？。这里只回答一个实际问题：路由被拒绝时，到底先查哪一层。

定义框： BGP 负责宣告正在发生的路由，IRR 记录可用于过滤的路由意图，RPKI/ROA 用可验证的授权关系检查起源 ASN。三者都不能单独证明一条路由已经在公网可达。

白脸小鹿拿着放大镜，沿着一张空白路由卡经过网络、登记柜和授权闸门，逐层检查路由卡卡在哪里。

排障时，把真实宣告、IRR 登记和 RPKI 授权放在同一条检查路径上对照。

先看一张表：三者到底有什么区别

维度 BGP IRR RPKI / ROA
检查对象 正在宣告的路由 route、route6、aut-num、as-set 资源证书、ROA
信任来源 无内置信任（默认相信听到的） 数据库来源 + 对象认证 + 运营者策略 资源证书与数字签名链
输出结果 被接受 / 被过滤 / 继续传播 供生成允许或拒绝列表 Valid / Invalid / NotFound
谁负责修改 路由器配置 网络运营者 / 维护者 地址资源持有方（或其 LIR）
能否证明路由可达 需要公网观测确认 不能 不能

RIPE NCC 明确把 ROUTE / ROUTE6 对象与 ROA 分开处理：路由起源信息可以同时出现在两套数据库里，但两者之间没有直接关联。Requirements for the RIPE Database（RIPE-767）对此有专门说明。IETF 的 BGP 运营安全实践（RFC 7454）同样把 IRR 过滤与 RPKI 验证视为两种不同机制。

一条路由为什么会卡住

路由被拒绝，通常落在下面五个环节之一：

  1. 本地没有 export —— 路由器根本没把前缀发出去，与 IRR、RPKI 都无关。
  2. 上游 IRR 过滤不通过 —— 缺少 Route Object、对象不精确、或对象不在上游采信的 IRR 里。
  3. RPKI 为 Invalid —— Origin ASN 与 ROA 不一致，或宣告长度超过 maxLength。
  4. 前缀长度被过滤 —— 上游可能根据地址族、前缀长度和本地策略设置过滤条件。
  5. 路由没有向公网传播 —— 上游接受了但没转发，或传播链路某处断开。

排查时按“本地 → 上游 → 公网”的顺序走，先排除自己的配置问题，再查上游的检查项。

四种状态：先查什么

IRR 状态 RPKI 状态 优先检查项
正确 Valid 继续看 BGP 传播：上游是否转发、公网是否可见
正确 NotFound 确认上游是否强制 RPKI；有些网络会接受，有些会降低优先级甚至拒绝，取决于接收方的 ROV 策略
正确 Invalid 先检查 Origin ASN 和 maxLength，再核对 ROA
缺失或错误 Valid 检查上游 IRR 过滤和客户白名单——RPKI 正确不代表过滤通过

最容易误判的是最后一行：看到 RPKI Valid 就认为路由一定被接受。实际上，接收方完全可以在 RPKI 之外再用 IRR、白名单或前缀长度做过滤。

故障现象 → 优先检查项

故障现象 优先检查项
Session 已 Established，但前缀完全不通 本地 export policy → route / route6 是否精确存在 → Origin ASN 是否一致
RPKI 显示 Invalid 实际 Origin ASN vs ROA 授权 ASN → 宣告长度 vs maxLength → 是否存在覆盖更宽的 ROA
RPKI Valid，但公网看不到 上游是否接受并转发 → IRR 过滤 → export policy → 多区域 Looking Glass
改了对象后仍不通 上游 IRR 刷新周期（分钟到数天）→ 是否在维护窗口内临时反复修改

用工具快速定位

三个免费工具可以覆盖大部分检查项：

三个常见的坑

1. 只看 RPKI，不问上游是否检查 IRR

RPKI Valid 只说明起源授权通过。如果上游用 IRR 生成过滤器，缺对象一样会被拒。上线前先问清楚：上游跑 ROV 吗？也查 IRR 吗？

2. 只看 RIPE Database，不问上游实际使用哪个 IRR

RADb、ARIN IRR、APNIC IRR 都是独立数据库。对象建在 RIPE 里，不代表读取 RADb 的上游会看到。以对方实际使用的数据源为准。

3. 拿到 ASN 就以为拥有全部管理权限

PA 前缀由 Sponsoring LIR 提供时，ROA 和 Route Object 的管理路径通常掌握在 LIR 手里。先确认谁有权创建、修改、撤销这些记录，再安排上线，避免临门一脚才发现改不了。

上线前检查清单

  • 已确认每个上游分别使用哪些检查：IRR、RPKI，还是两者都要
  • 真实要宣告的 IPv4、IPv6 前缀已列清，长度与宣告一致
  • IPv4 有 route，IPv6 有 route6，且位于上游采信的 IRR
  • IRR 中的 Origin ASN 与实际宣告一致
  • ROA 的 Prefix、Origin ASN、maxLength 与真实路由一致
  • 已确认谁有权创建和修改 IRR 与 ROA（PI 自己 / LIR）
  • 上线后从多个公共视角验证实际可见性
  • 记录资源变更、上游切换和紧急修改的流程

FAQ

没有 ROA 的路由一定会被丢弃吗？

不一定。通常它处于 NotFound 状态，接收网络可能接受、降低优先级，或按自己的政策处理。是否强制 ROV 取决于接收方。

IRR 和 RPKI 都正确，路由还会不通吗？

会。两者正确只说明登记和起源授权检查通过，仍可能是 export policy、上游过滤、传播链路或数据面故障。

路由被拒绝，先查 IRR 还是 RPKI？

取决于上游的检查顺序。一般先确认上游用哪套机制，再按“本地 export → 对应机制的数据 → 公网观测”的顺序查。工具页可以同时给出 IRR 与 RPKI 两个视角。

小结

路由被拒绝时，先分清是哪一层的问题：BGP 负责宣告、IRR 负责登记和过滤、RPKI/ROA 负责起源授权验证。三层各自独立、不会自动同步，所以排查不能只看其中一个结果——把真实宣告、IRR 对象、ROA 授权和公网观测放在一起对照，才能定位真正的卡点。

一句话记住

RPKI Valid 不代表路由会被接受；BGP、IRR、RPKI 是三层不同的检查，路由被拒时先确定卡在哪一层。

参考资料

继续阅读