技术指南

BGP、IRR 与 RPKI 不一致：排查路由与可达性问题

对照 BGP、IRR 路由对象与 ROA，定位起源 ASN、前缀长度及过期记录问题，让客户 API 和服务器恢复稳定连接。

了解 IPv4 Continuity

发布时间: 2026-10-02
更新时间: 2026-10-02
作者: LARUS Editorial Team

路由看起来正常，部分客户却访问不了 API 或服务器？BGP、IRR 与 RPKI 记录不一致，是值得优先核对的原因。把实际宣告、路由对象和 ROA 放在一起检查，可以更快找到过滤发生在哪一层，减少无效改动。

BGP 展示正在宣告的路由；IRR 记录预期的前缀与起源 ASN；RPKI 通过 ROA 提供可验证的起源授权。迁移 ASN、更换上游或增加 IPv4 容量时，同步这些信息能让客户连接平稳衔接。

BGP、IRR 与 RPKI 不一致：快速解答

BGP、IRR 与 RPKI 不一致是指实时 BGP 路由中观察到的前缀和起源 ASN，与 Internet Routing Registry、Route Origin Authorization 或两者所发布的信息不一致。

例如：

BGP 可能显示 AS64501
IRR 路由对象可能仍然列出 AS64500
ROA 可能仍然授权 AS64500

这并不自动意味着 AS64501 存在恶意行为。

网络可能只是更改了起源 ASN，却没有同步更新周边的路由记录。

但这种不一致可能带来实际的运营影响。

过时的 IRR 记录可能与基于 IRR 数据生成的过滤规则发生冲突。

错误的 ROA 可能导致一个合法的 BGP 宣告，在执行 Route Origin Validation 的网络中被判定为 RPKI Invalid。

因此，更安全的处理方式是：

确定预期使用的起源 ASN。
验证实时 BGP 宣告。
检查 IRR 路由对象。
检查 ROA 和 RPKI 验证状态。
检查近期发生的网络或资源变更。
修正已经无法反映预期部署状态的那一层。
修改完成后验证全球网络可达性。

这些路由和授权系统也属于更广泛的互联网技术治理框架的一部分，该框架用于协调号码资源、路由信息、路由安全声明以及运营互操作性。

BGP、IRR 和 RPKI 分别代表什么？

要理解“不一致”，首先需要了解这些系统实际上回答的是不同的问题。

BGP、IRR 和 RPKI 分别代表什么？
系统	代表什么	核心问题
BGP	实时路由可达性和路径信息	现在实际上是哪个 ASN 在发起这个前缀？
IRR	已发布的路由策略信息	记录中预期由哪个 ASN 作为 Origin？
RPKI / ROA	可通过密码学验证的 Origin 授权	哪个 ASN 获得授权，可以发起这个前缀？

这些功能有所重叠，但不能互相替代。

BGP：实际上正在宣告什么？

Border Gateway Protocol 是自治系统之间用于在互联网交换可达性信息的路由协议。

BGP 的核心规范 RFC 4271 将 BGP 描述为一种在 Autonomous Systems 之间交换网络可达性信息的协议。

当运营商检查某个 IPv4 前缀的 BGP 状态时，可以观察：

起源 ASN
AS path
前缀长度
上游可见性
更具体的路由宣告（more-specific announcements）

因此，BGP 可以告诉你一个非常重要的信息：

网络实际上正在宣告什么？

但观察到一条 BGP 路由，本身并不能证明该起源 ASN 已获得授权。

配置错误、路由泄漏或未经授权的路由宣告同样可能出现在 BGP 中。

IRR：已发布的路由策略说明了什么？

Internet Routing Registry 用于保存路由策略信息。

对于 IPv4，IRR 路由对象通常会关联：

一个 IP 前缀；以及
一个起源 ASN。

例如：

route:  203.0.113.0/24
origin: AS64500

这表示 IRR 记录将该前缀与 AS64500 关联。

LARUS 在 What Is an IRR 路由对象? A Guide for Network Operators 中进一步解释了它的结构和运营作用。

IRR 记录描述的是路由策略信息。它本身并不会创建 BGP 宣告。

一些网络会利用 IRR 信息帮助生成路由过滤规则，因此不准确或过时的 route object 仍然可能引发实际的运营问题。

RPKI：哪些内容获得了密码学授权？

Resource Public Key Infrastructure 为路由资源授权提供了一套密码学框架。

Route Origin Authorization 指定某个 IP 前缀获授权的起源 ASN，同时还可以定义该授权允许的最大前缀长度。

当前 ROA 技术规范定义于 RFC 9582。

ROA 数据可以通过 Route Origin Validation 使用，根据 BGP 宣告是否符合经过验证的授权信息，对其进行分类。

LARUS 在 What Is RPKI? 中提供了更全面的说明。

因此，RPKI 帮助回答：

根据经过验证的 RPKI 数据，这个起源 ASN 是否获授权发起这个前缀？

RPKI Origin Validation 并不会验证完整的 AS path，也不能取代 BGP 监控、IRR 数据维护或运营过滤机制。

BGP、IRR 与 RPKI 不一致是什么样的？

假设一个组织使用：

203.0.113.0/24

预期的起源 ASN 为：

AS64500

理想状态如下：

BGP、IRR 与 RPKI 不一致是什么样的？
层	状态
BGP	AS64500
IRR	AS64500
RPKI	AS64500 已授权
结果	一致

但在网络迁移之后，BGP 可能变成：

AS64501

而其他记录仍然没有改变。

BGP、IRR 与 RPKI 不一致是什么样的？
层	状态
BGP	AS64501
IRR	AS64500
RPKI	AS64500 已授权
结果	BGP 与 IRR 和 RPKI 均不一致

此时，网络需要确定：

AS64501 是否为合法的新 Origin；
BGP 配置是否错误；
IRR 对象是否已经过时；
ROA 是否已经过时；
是否出现了意外的路由宣告。

确定这些问题，就是排查不一致问题的核心。

常见 BGP、IRR 与 RPKI 不一致场景

下表可以作为初步判断的参考。

常见 BGP、IRR 与 RPKI 不一致场景
BGP	IRR	RPKI	可能的解释
ASN A	ASN A	ASN A	记录一致
ASN B	ASN A	ASN A	BGP Origin 已改变；需要确认应该修改路由还是相关记录
ASN B	ASN B	ASN A	IRR 与 BGP 一致；ROA 可能需要检查
ASN B	ASN A	ASN B	BGP 与 ROA 一致；IRR 可能已经过时
ASN A	缺失	ASN A	RPKI 与 BGP 一致；IRR 信息可能不存在
ASN A	ASN A	NotFound	可能不存在覆盖该路由且经过验证的 ROA
ASN A	ASN A	Invalid	检查 ASN 和前缀长度授权
没有可见路由	ASN A	ASN A	记录存在，但该前缀目前可能没有被宣告

以上任何一种情况都不应该被自动视为存在违规或恶意行为的证据。

它们只是用于诊断问题的信号。

场景 1：BGP 起源 ASN 与 IRR 路由对象不一致

假设实时 BGP 显示：

203.0.113.0/24 → AS64501

但 IRR 路由对象显示：

route:  203.0.113.0/24
origin: AS64500

可能存在多种原因。

网络最近更换了 ASN

网络可能已经：

更改 Transit 架构；
迁移基础设施；
迁移至新的 ASN；
更换路由提供商；
重新组织网络。

BGP 可能已经反映新的网络设计，而 IRR 记录仍然保留旧的信息。

IRR 对象没有更新

迁移本身可能完全合法，但变更流程中遗漏了 IRR 维护。

BGP 配置错误

相反的情况也可能发生。

IRR 记录可能仍然正确描述预期 Origin，而 BGP 却意外从错误的 ASN 宣告了路由。

为什么这很重要？

如果上游供应商或 Peer 根据 IRR 数据生成路由过滤规则，那么不符合预期 IRR 信息的合法 BGP 宣告可能会遇到过滤问题。

这条路由可能通过一个供应商正常工作，但通过另一个供应商却无法使用。

因此，排查路由问题时应该使用多个外部观察点，而不能只检查本地路由器。

场景 2：BGP 起源 ASN 与 ROA 不一致

这种不一致可能带来更直接的路由安全影响。

假设：

BGP:  203.0.113.0/24 → AS64501
ROA:  203.0.113.0/24 → AS64500

如果该路由被 ROA 覆盖，但起源 ASN 与获得授权的 Origin 不一致， Route Origin Validation 可能会将该宣告分类为 Invalid。

采用拒绝 RPKI Invalid 路由策略的网络，可能会拒绝这条宣告。

结果可能包括：

部分网络无法访问；
不同网络中的可见性不同；
来自执行 ROV 网络的流量丢失；
难以诊断的区域性连接问题。

RPKI 本身不会自动关闭一条路由。网络运营商会自行决定如何在路由策略中应用 RPKI 验证结果。

因此，两个网络对于同一种不一致情况可能采取不同的处理方式。

场景 3：BGP 与 RPKI 一致，但 IRR 已过时

例如：

BGP:  AS64501
ROA:  AS64501
IRR:  AS64500

这可能意味着实时路由和 RPKI 授权已经反映新的预期 Origin，但 IRR 记录没有同步更新。

运营商仍然应该验证相关变更是否正确。

可能造成的影响包括：

基于 IRR 生成的过滤规则无法识别新的 Origin；
上游供应商接入延迟；
故障排查时产生混淆；
不同路由工具之间显示不一致的记录。

解决方法可能只需要联系维护方修正或替换相关 IRR 对象。

场景 4：BGP 与 IRR 一致，但 RPKI 为 Invalid

例如：

BGP:  AS64501
IRR:  AS64501
ROA:  AS64500

网络可能已经正确更新路由和 IRR 信息，却忘记更新 ROA。

这种情况可能发生在：

ASN 迁移；
上游网络更换；
IPv4 租赁部署；
IPv4 转让；
网络重组。

这种不一致尤其值得注意，因为该路由在 BGP 中看起来可能完全正常，但仍然会被判定为 RPKI Invalid。

场景 5：ASN 一致，但前缀长度不一致

并非所有 RPKI 不一致都与起源 ASN 有关。

ROA 还可以指定允许的最大前缀长度。

假设网络获得以下授权：

203.0.112.0/23

但实际宣告：

203.0.113.0/24

该宣告是否属于 RPKI Valid，取决于授权内容以及允许的前缀长度。

因此，限制过于严格的 ROA 可能会让一个合法的更具体前缀的宣告变成 Invalid。

排查 RPKI 问题时，应始终同时检查：

起源 ASN；
Prefix length / MaxLength。

不要只检查 ASN。

为什么路由不一致会导致部分网络无法访问？

一个常见误解是：路由要么全球正常，要么全球失效。

现实中的互联网路由要复杂得多。

不同网络可能使用不同的：

IRR 数据库；
过滤规则生成流程；
RPKI validator；
ROV 策略；
缓存更新时间表；
Transit 策略；
Peering 策略。

因此，一个网络可能继续接受某条路由，而另一个网络则可能拒绝它。

Network A → 可访问
Network B → 可访问
Network C → 无法访问
Network D → 可访问
Network E → 无法访问

这种问题甚至可能比完全中断更难诊断。

从运营商自身所在位置来看，服务可能完全正常，但部分客户却无法访问。

因此，路由验证应该从多个外部网络视角进行。

什么原因会导致 BGP、IRR 和 RPKI 记录失去一致性？

大多数不一致问题并不需要复杂或异常的原因。

网络本身就在不断变化。

起源 ASN 变更

网络开始通过不同的 ASN 宣告某个前缀。

上游网络迁移

路由架构发生改变，但相关授权数据没有同步检查。

IPv4 租赁

租赁的前缀被部署到客户网络，因此需要在 IPv4 提供商、客户 ASN、IRR 和 RPKI 之间进行协调。

对于准备部署租赁前缀的组织，LARUS 提供了关于如何租赁 IPv4 地址的分步指南。

IPv4 转让

IPv4 转让完成后，注册记录可能在实际路由迁移之前或之后发生改变。

针对 IPv4 转让，i.lease 在IP 地址转移后 IPv4 记录会发生什么变化中进行了说明。

人为错误

网络工程师可能更新了一个系统，却遗漏另一个系统。

自动化失败

原本应该同步完成的变更流程可能只执行了一部分。

错误的 MaxLength

起源 ASN 是正确的，但 ROA 不允许实际宣告的前缀长度。

旧的 IRR 对象

实际路由关系已经改变，但旧的 route object 仍然存在。

意外的管理变更

注册机构 account、RPKI 或 IRR 可能在没有同步配合预期路由计划的情况下发生变化。

Heng Lu 在 Preparing for an Unexpected Change in 注册机构 Records 中讨论了这种更广泛的连续性问题。

IRR 与 RPKI：网络运营商应该相信哪一个？

这个问题本身就不太准确。

IRR 和 RPKI 并不是同一个数据库的两个竞争版本。

它们通过不同的信任模型提供不同的信息。

IRR 用于帮助发布路由策略信息。

RPKI 提供可通过密码学验证的 Origin 授权。

BGP 显示运营网络实际传播的路由。

更合适的问题应该是：

这些层是否准确描述了我们实际希望运行的网络？

如果不是，就应该调查其中的差异。

NRS.help 在 RPKI vs IRR: What’s the Difference and Why You Need Both 中提供了更深入的比较。

如何排查 BGP、IRR 与 RPKI 不一致？

采用有步骤的故障排查流程，可以降低误改错误系统的风险。

步骤 1：确定预期的路由状态

在进行任何修改之前，先回答：

应该宣告哪个前缀？
应该由哪个 ASN 发起？
预期使用哪些前缀长度？
这次变更是永久性的还是临时性的？
最近是否发生过迁移？

如果没有明确的预期状态，就没有可靠的比较基准。

步骤 2：检查实时 BGP

验证：

当前起源 ASN；
前缀长度；
AS path；
more-specific routes；
全球可见性；
多个 route collector 或 looking glass 的结果。

不要只依赖一个网络视角。

步骤 3：检查 IRR 路由对象

确认：

Prefix；
起源 ASN；
Source IRR；
Maintainer；
最后修改时间；
是否存在多个或互相冲突的对象。

将这些对象与预期路由状态进行比较。

步骤 4：检查 RPKI / ROA

验证：

是否存在覆盖该路由的 ROA？
哪个 ASN 获得授权？
覆盖的是哪个前缀？
允许的 MaxLength 是多少？
观察到的路由是 Valid、Invalid 还是 NotFound？

ARIN 的 ROA documentation 提供了更多关于 ROA 管理的信息。

步骤 5：检查近期变更

检查是否发生过：

ASN 迁移；
Prefix 移动；
Transit 变更；
IPv4 转让；
IPv4 租赁；
ROA 修改；
IRR 更新；
注册机构 account 变更。

步骤 6：确定哪一层需要修正

不要自动修改所有系统。

如果预期 ASN 是 AS64501，而：

BGP = AS64501
IRR = AS64500
RPKI = AS64500

那么 IRR 和 RPKI 可能都需要协调更新。

但如果：

Intended ASN = AS64500
BGP = AS64501
IRR = AS64500
RPKI = AS64500

那么真正的问题可能出在 BGP 配置上。

步骤 7：按照正确顺序协调变更

对于计划中的 Origin-AS 变更，运营商可能需要协调：

Authorization
ROA
IRR
Upstream filters
BGP announcement
Validation
删除过时记录

最重要的原则，是避免出现一段时间，使合法路由因为变更顺序问题而意外成为 Invalid 或被过滤。

步骤 8：从多个网络验证

修正不一致之后，验证：

BGP Origin；
RPKI validation；
IRR 信息；
全球路由传播；
区域可达性；
客户连接。

不要因为数据库已经更新，就假设实际运营问题已经消失。

BGP、IRR 与 RPKI 不一致故障排查清单

BGP

正确的前缀已被宣告；
显示正确的起源 ASN；
使用预期的前缀长度；
不存在意外的更具体前缀的宣告；
多个 route collector 都能看到该路由；
上游供应商接受该路由。

IRR

存在正确的 route object；
列出正确的起源 ASN；
正在使用正确的 IRR source；
不存在造成混淆的过时冲突对象；
清楚了解 Maintainer 授权。

RPKI

存在正确的 ROA；
正确的起源 ASN 已获授权；
覆盖正确的前缀；
MaxLength 支持预期的路由宣告；
路由没有意外变成 Invalid。

运营

在需要的情况下，LOA 仍然有效；
上游网络的过滤规则已经更新；
相关变更已经记录；
已经检查多个外部路由视角；
重大迁移具有回滚流程。

为什么注册机构与路由信息的准确性很重要？

即使部分周边记录已经过时，路由系统仍然可能继续运行。

但这并不代表这些记录不重要。

准确的信息能够帮助运营商：

排查路由问题；
验证授权；
建立过滤规则；
协调迁移；
响应事件；
了解资源关系；
维持网络连续性。

LARUS Foundation 在 Why Accurate 注册机构 Data Supports a Stable Internet 中讨论了这一更广泛的协调原则。

注册机构和授权系统用于支持网络，而不是取代网络本身。

因此，一个健康的运营模式应该确保协调记录与合法、实际运行的网络状态保持一致。

为什么这对 IPv4 租赁尤其重要？

在部署租赁 IPv4 时，BGP、IRR 和 RPKI 不一致尤其值得关注。

假设一家企业租赁了一个 /22，并计划通过自己的 ASN 进行宣告。

IPv4 资源
↓
租赁授权
↓
LOA
↓
IRR Route Object
↓
RPKI / ROA
↓
客户 ASN
↓
BGP
↓
全球可达性

如果提供商已经提供资源，但各个路由层没有协调一致，这个地址块可能无法按照预期方式运行。

因此，在部署租赁 IPv4 之前，企业应该明确：

哪个 ASN 将发起该前缀？
由谁创建或更新 IRR 对象？
由谁控制 ROA？
需要什么 MaxLength？
由谁提供 LOA？
由谁处理路由变更？
如果客户更换 ASN，会发生什么？
错误记录可以多快得到修正？
续租或终止期间由谁负责？

这就是为什么生产环境中的 IPv4 租赁不能只根据每月价格来评估。

运营控制同样重要。

从五个层面理解路由一致性

对于生产网络，可以从五个层面考虑路由是否已经准备就绪。

从五个层面理解路由一致性
层	关键问题
资源（Resource）	谁控制或管理 IPv4 资源？
授权（Authorization）	谁授权该网络使用并宣告这个资源？
策略（Policy）	IRR 记录是否描述了预期的路由关系？
安全（Security）	RPKI 是否授权预期的起源 ASN 和前缀长度？
运营（Operation）	实时 BGP 是否反映预期运行的网络？

出现不一致通常意味着其中某一层发生了改变，而其他层没有同步更新。

对于关键基础设施而言，知道由谁负责修正每一层，与发现不一致本身同样重要。

LARUS 如何帮助客户保持连接？

客户依赖的是持续可达的 API、服务器和网络出口。LARUS 将第一方地址供应、路由协调、RPKI/ROA、反向 DNS、信誉和续租放在同一套 Continuity 服务中，让新增容量与已有业务一起稳定运行。

用 Unlimited IPv4 支撑增长，也让更换 ASN、上游和部署位置时有人衔接地址相关工作。了解LARUS IPv4 租赁与 Continuity。

常见问题

什么是 BGP、IRR 与 RPKI 不一致？

BGP、IRR 与 RPKI 不一致，是指实时 BGP 路由信息与 IRR 路由对象、RPKI ROA 或两者发布的 Origin 信息不一致。

出现不一致是否意味着 BGP 路由一定是错误的？

不是。BGP 可能反映一个合法的新网络配置，而 IRR 或 RPKI 数据仍然没有更新。相反，BGP 本身也可能配置错误。因此，首先必须确认预期的路由状态。

如果 BGP 与 RPKI 不一致会发生什么？

如果 BGP 宣告被某个 ROA 覆盖，但不符合获授权的起源 ASN 或允许的前缀长度，它可能被判定为 RPKI Invalid。采用 ROV 拒绝策略的网络可能会拒绝该路由。

如果 BGP 与 IRR 不一致会发生什么？

使用基于 IRR 数据生成路由过滤规则的网络，可能无法按照预期识别该宣告。实际影响取决于不同网络使用的 IRR 数据和过滤策略。

一条路由可以是 RPKI Valid，但在 IRR 中没有记录吗？

可以。IRR 和 RPKI 是两个独立的系统。即使没有对应的 IRR 路由对象，一条路由仍然可能拥有有效的 RPKI 授权。

IRR 可以是正确的，而 RPKI 是错误的吗？

可以。例如，在 ASN 迁移过程中，运营商可能已经更新 IRR 路由对象，却忘记更新 ROA。

RPKI Invalid 是什么意思？

RPKI Invalid 通常意味着存在覆盖该路由且经过验证的授权，但观察到的路由不符合获授权的起源 ASN 或允许的前缀长度。

RPKI NotFound 与 Invalid 一样吗？

不一样。NotFound 通常表示没有经过验证的 ROA 覆盖该路由。 Invalid 则表示相关授权确实存在，但该路由宣告不符合授权要求。

RPKI 会取代 IRR 吗？

不会。RPKI 提供可通过密码学验证的 Origin 授权，而 IRR 提供可能用于过滤和运营协调的路由策略信息。

应该始终把 BGP 当作唯一的事实来源吗？

不应该。BGP 显示的是当前正在被宣告的内容，但该宣告可能是合法的、配置错误的，也可能未经授权。实时路由应该结合预期的网络配置和授权信息一起评估。

BGP、IRR 与 RPKI 不一致会造成部分网络无法访问吗？

会。不同网络可能使用不同的 IRR 过滤规则和 RPKI 验证策略。因此，同一条路由可能被一些网络接受，却被另一些网络拒绝。

如何修复 BGP、IRR 与 RPKI 不一致？

首先确定预期的起源 ASN 和前缀。然后比较实时 BGP、IRR 与 RPKI 信息，找出哪一层已经过时或存在错误，协调完成所需修改，并在修改之后验证路由传播情况。

让路由记录跟上业务变化

先确认客户网络希望实现的路由状态，再对照实时 BGP、IRR 和 ROA 找出差异。修正后从多个网络验证，才能知道客户连接是否真正恢复。记录服务于实际网络；维护记录的价值，是减少上线、扩容和迁移时的业务中断。

IPv4 与业务连续性

让客户连接跟上每一次网络变更。

用 Unlimited IPv4 扩展网络，让 LARUS 第一方供应与 Continuity 持续支持客户的服务器、API 和连接。