Shikanoko Networks (SKNK)
返回技术博客

SKNK 中文技术指南

什么是 ROV？路由起源验证如何判定 BGP 路由

Route Origin Validation（ROV）把 BGP 宣告和已验证的 RPKI 数据比对，得出 Valid、Invalid、NotFound 三种状态。本文解释三种状态的含义、BGP 会话已建立但路由不通的原因，以及遇到 Invalid 时的排查顺序。

RPKI 是一套用来发布签名路由授权的数据体系。ROA 是其中的授权记录：它写明哪个 ASN 可以宣告哪个前缀、最多能宣告到多细。而 ROV（Route Origin Validation，路由起源验证）是接收路由这一侧真正发生的判断——路由器把收到的 BGP 宣告和已经验证过的 RPKI 数据做比对，得出 Valid（有效）、Invalid（无效）、NotFound（未找到） 三种结果。Invalid 不等于网络一定不可达，但很多网络会过滤这类路由或降低它的优先级；NotFound 也不等于 Invalid，它只是说没找到覆盖这条宣告的授权数据。

定义框： ROV 是路由器侧的过程：把一条 BGP 宣告和已验证的 RPKI 授权数据比对，判断这条路由的起源是 Valid、Invalid 还是 NotFound。

白脸小鹿把一封路由信件投入分拣机器：三个无文字出口中，一个继续向前、一个被闸门拦住、一个落入托盘。

每条收到的路由都会被分到三种状态之一，接下来怎么处理，由接收方自己的策略决定。

ROV 在整条链路里处于哪一环？

在 ROV 运行之前，前面几方要先把自己的活干完。完整链路是这样的：

白脸小鹿转动路由验证机器：签名授权进入机器，路由在观察窗中被核对，随后通向三个不同的策略出口。

资源持有方发布 ROA，验证器产出 VRP；路由器据此为收到的 BGP 路由分类，最后由本地策略决定如何处置。

有三个最容易混淆的细节，值得单独说清楚：

  • 路由器通常不自己做密码学验证。 校验证书链和 ROA 签名是验证器的活；路由器消费的是验证器的输出，拿每条收到的路由去和它比对。所以 ROV 的结果不可能比最近一次验证器同步更新。
  • ROV 正好发生在"我看到了这条路由，该怎么处理它"这一步。 它是接收侧的一个分类动作，不会创建路由、宣告路由，也不会改动 AS_PATH。
  • 状态本身不决定任何动作。 丢弃、降优先级、打社区标签还是仅记录日志，都由本地路由策略决定。两家网络即使用同一套 ROV 引擎，也可能对同一种状态做出完全不同的处理。

RPKI 体系本身见什么是 RPKI？，授权记录怎么填见什么是 ROA？。本文只讲判定这一步。

RPKI、ROA、VRP、ROV：四个词不要混

这四个词在每篇 RPKI 教程里都会一起出现，但说的是四件不同的事。混在一起，排障时就容易查错层。

术语 它是什么 谁负责 它不代表什么
RPKI 资源授权与验证的整套体系：证书、仓库、签名对象和校验规则 RIR、资源持有方、验证器运营者 不是 BGP 协议，不承载路由
ROA 一条授权记录：前缀 + Origin ASN + 可选的 maxLength 持有资源证书权限的一方 不证明路由在线、正在被宣告
VRP Validated ROA Payload——验证器产出的、路由器能直接比对的数据 验证器软件 不是原始 ROA 本身，是验证并缓存后的视图
ROV 用 VRP 给收到的 BGP 宣告分类的过程 接收路由的网络 不验证完整 AS_PATH，也不判断路由质量

一句话记法：RPKI 是体系，ROA 是那张许可条，VRP 是路由器能读的许可条核对副本，ROV 是拿路由去对副本的动作。

Valid、Invalid、NotFound 分别是什么意思？

比对规则来自 RFC 6811（BGP Prefix Origin Validation）。收到一条宣告时，路由器会得到 Valid、Invalid、NotFound 三种状态之一。下面表格把 Invalid 按两种最常见的成因拆开列出，方便对照排障：

状态 发生条件 运营含义 下一步
Valid 至少一条覆盖性授权允许该前缀、该 Origin ASN 和该长度 起源授权匹配 继续查传播、IRR、上游过滤
Invalid（ASN） 有覆盖性授权，但宣告的 Origin ASN 不匹配 常被严格 ROV 策略过滤 核对实际起源与 ROA
Invalid（长度） ASN 匹配，但宣告比 maxLength 允许的更长 常被严格 ROV 策略过滤 核对实际宣告与 maxLength
NotFound 没有覆盖这条宣告的授权数据 没有得到起源授权结论 确认这里本应不应该有 ROA

用文档地址做的例子

下面用 2001:db8:1234::/48（IPv6 文档保留段）和私有 ASN 举例，不会让读者误以为是真实资源。

例 1：完全匹配。

ROA:  2001:db8:1234::/48, Origin AS65001, maxLength /48
BGP:  2001:db8:1234::/48, Origin AS65001
ROV:  Valid

宣告和授权完全一致，起源被判定为有效。注意它没说别的：没说路由已经传播出去、没说 IRR 对象存在、也没说有人会接受它。

例 2：两种 Invalid。 在已有 ROA 的情况下，下面两条宣告都会得到 Invalid，但原因不同：

ROA:  2001:db8:1234::/48, Origin AS65001, maxLength /48

BGP:  2001:db8:1234::/48, Origin AS65002   → Invalid（ASN 不符）
BGP:  2001:db8:1234::/52, Origin AS65001   → Invalid（长度超限）

第一条宣告用了错误的起源 ASN；第二条在授权上限 /48 的块里宣告了更细的 /52，超过 maxLength。

例 3：NotFound。 如果这条前缀完全没有发布任何 ROA：

BGP:  2001:db8:1234::/48, Origin AS65001   → NotFound

没有覆盖性授权，所以得不出任何结论——这就是 NotFound，不是"判定它有罪"。

区分两种 Invalid 对排障很重要：ASN 不符指向起源路由设计，长度超限指向 ROA 里的 maxLength。什么是 ROA？详细解释了 maxLength 为什么是最常见的出错点。

为什么 BGP Session 已 Established，路由还是不通？

会话建立了，前缀却用不起来——按顺序走一遍，ROV 只占其中一个位置：

  1. BGP 会话和上游建立成功。
  2. 路由器在 BGP 更新里收到你的前缀。
  3. ROV 给它分类——如果是 Invalid，问题就在这里停下来。
  4. 上游按自己的策略处理：拒收、降优先级，或不再往下传。
  5. 即使 ROV 判定 Valid，路由仍可能被 IRR 过滤、客户前缀白名单、export policy 配置错误、下一跳不可达或下游传播问题拦住。

白脸小鹿操作一扇关闭的过滤闸门；连接仍然连通，但路由信封停在闸门前。

BGP Session 已 Established 只说明会话已通；一条具体路由仍可能被策略拒收，或不再向下游传播。

所以"已建立但不通"其实是两种完全不同的情况：要么路由是 Invalid、上游的 ROV 策略正在作用；要么路由起源没问题，但链路其他地方断了。下面的工具帮你分辨是哪一种：

ROV 不做什么

ROV 只回答一个问题——宣告的起源有没有被授权。超出这个范围的，都不在它的能力之内，过度解读三种状态会让人查错方向：

  • 不验证完整 AS_PATH。 只检查这条路由的 Origin ASN，通常是 AS_PATH 最后一段中最右侧的 ASN。中间的 ASN 一概不看——那是 BGPsec 的职责，而 BGPsec 目前并未广泛部署。
  • 不能阻止所有路由泄漏。 只要泄漏用的是被正确授权的起源 ASN，照样能通过 ROV。它过滤的是特定一类攻击，不是通用防泄漏机制。
  • 不保证全网接受。 Valid 是关于授权的声明，不是"每条网络都会接受、传播或优先选择这条路由"的承诺。
  • 不替代 IRR Route Object。 IRR 数据用于生成前缀过滤和路由策略；ROV 只做起源分类。多数按 IRR 过滤的网络，过滤逻辑独立于 ROV。见什么是 IRR Route Object？。
  • 不证明商业或合同所有权。 授权只证明资源证书关系成立，不证明谁付了钱、谁拥有合法所有权。
  • "路由 Invalid"不等于"ROA 无效"。 ROA 可以格式完全正确、密码学上也完全有效，只是没匹配上某条具体宣告。改宣告和改授权是两件不同的事。

遇到 Invalid 时的排查顺序

ROV 报 Invalid 时，按这个顺序走。跳步——比如还没记下路由器实际宣告了什么就去改 ROA——通常会白费第一轮修改：

白脸小鹿用放大镜把一张路由卡和授权模板逐项核对，旁边放着旧的授权卡。

先记录实际 BGP 宣告，再核对前缀、长度与 Origin ASN 是否匹配覆盖性授权；确认事实后再改 ROA。

  1. 记下实际宣告。 精确记录 BGP 里宣告的前缀、长度和 Origin ASN。凭记忆猜"应该是对的"最容易翻车。
  2. 查询 ROV 状态和覆盖性授权。 用验证器或 RPKI 查询工具，看哪些 ROA 覆盖这个前缀、授权了什么。
  3. 核对 ASN。 宣告的 Origin ASN 和覆盖性 ROA 里的 ASN 一致吗？
  4. 核对前缀长度。 宣告比 maxLength 更细吗？如果是，要么宣告聚合前缀，要么为更细的前缀单独建一条 ROA。
  5. 查旧 ROA 和冲突授权。 上一轮路由设计留下的 ROA 可能正好构成了让今天宣告变 Invalid 的覆盖性授权——但只有在没有其他匹配的 VRP 授权这条宣告时，旧 ROA 才会导致 Invalid。
  6. 确认谁有权限改 ROA。 这个人不一定是你自己。
  7. 改完，等，再验证。 授权变更后，发布、验证器同步、上游策略刷新都需要时间。等这些稳定下来再查 BGP 可见性，并且从多个公共视角确认。

给 SKNK 客户的话： 如果你的前缀是 SKNK 分配的 IPv6 PA /48，ROA 权限在 SKNK 手里，不在你手里。请确认实际 Origin ASN 与存档授权一致——不要假设你能自己在 RIPE Portal 里创建或修改 ROA。任何 ROA 变更请联系 SKNK，并把处理周期算进上线计划里。

常见误解

"NotFound 是不是就是坏路由？"

不是。NotFound 只是说没有覆盖性授权，系统得不出任何结论。它是授权数据的一个缺口，不是对路由的判决。

"Valid 是不是代表全网都可达？"

不是。Valid 只是起源授权的结果，不是可达性报告。传播、接受、下一跳和数据面都是独立的检查——Valid 的路由照样可能在公网上完全不可见。

"有 ROA 还需要 IRR Route Object 吗？"

不一定。ROA 供 ROV 使用；IRR 对象供很多上游生成前缀过滤器。是否需要 IRR，取决于你的上游和对等方实际用什么。保留上游要求的记录——对很多网络来说，就是两套都维护。

"ROV 会让 BGP 收敛变慢吗？"

ROV 本身对路由处理造成的延迟可以忽略。真正花时间的是操作层面：你改了一条 ROA 之后，发布、验证器刷新和上游策略更新都要时间。这是传播延迟，不是协议变慢。

"是不是应该一开始就把所有 Invalid 都丢弃？"

不必。严格丢弃是合理的策略，但很多运营者先采取更温和的姿态——记录、打标签或降优先级——同时确认自己的数据是对的。第一天就硬丢弃，一个小授权错误就可能变成一次事故。策略要刻意决定，而不是默认选。

"一个前缀能被多条 ROA 覆盖吗？"

能。多条 ROA 可以用不同的 Origin ASN 或不同的 maxLength 覆盖同一个前缀。只要至少一条覆盖性授权匹配，路由就是 Valid；和其中一条对不上没关系，如果另一条覆盖了这条宣告。这也是旧 ROA 会造成"莫名其妙 Invalid"的原因——但一条旧 ROA 只有在没有其他匹配的 VRP 授权当前宣告时，才会导致 Invalid。

FAQ

ROV 和 RPKI 有什么区别？

RPKI 是体系——证书、仓库、签名对象和校验规则。ROV 是把收到的 BGP 路由和已验证的 RPKI 数据比对、得出 Valid / Invalid / NotFound 的过程。RPKI 是基础设施，ROV 是路由器上执行的一步判断。

什么会让一条路由变成 RPKI Invalid？

存在覆盖性 ROA，但宣告和它对不上：要么 Origin ASN 与 ROA 里的不同，要么宣告的前缀比 ROA 的 maxLength 更细。

NotFound 的路由该被丢弃吗？

不一定要丢。它是否被接受、降级或丢弃，完全取决于接收网络自己的策略。

路由可以是 RPKI Valid 但不可达吗？

经常可以。Valid 只说明起源被授权。它仍可能栽在 IRR 过滤、export policy、下一跳不可达或传播问题上——请把 ROV 结果和 BGP 观测放在一起看。

ROV 会验证整条 BGP 路径吗？

不会。它只检查这条路由的 Origin ASN——通常是 AS_PATH 最后一段中最右侧的 ASN。中间的 ASN 一概不看。

谁能修复 Invalid 的 ROA？

只有持有相关资源证书权限的一方。资源直接登记在你名下，那就是你；如果你的前缀来自 Sponsoring LIR（比如 PA IPv6 /48），ROA 权限在 LIR 手里。上线前先确认谁有权改 ROA。

ROV 能替代 IRR 过滤吗？

不能。ROV 做起源授权分类，IRR 数据用于生成前缀过滤和路由策略。两套系统、两套信任模型，互相不能替代。RPKI 与 IRR 的区别有详细对比。

小结

ROV 是接收侧的一步判断：拿收到的 BGP 宣告和已验证的 RPKI 数据比对，分成 Valid、Invalid、NotFound 三种状态。它只回答"起源有没有被授权"这一个问题，不保证全网可达、不验证完整路径、也不替代 IRR。状态本身不决定动作——最终怎么处理，是每条网络本地策略的事。

一句话记住

ROV 不评判一条路由"好不好"，它只检查宣告的起源是否被授权，然后把路由处置的决定权留给每条网络自己的策略。

参考资料

继续阅读