RPKI显示Valid、Invalid或NotFound分别说明什么：起源授权与运营策略边界

路由看板把某个前缀标成RPKI Invalid，几分钟后一名用户又报告网页打不开。把两件事放在同一时间轴上很有价值，但还不能直接写成“RPKI导致全球断网”。Invalid描述的是起源授权比较结果，网页能否访问则经过运营商政策、路由选择、转发、域名解析和服务器状态。

相反，Valid也不是一张完整安全证书。它没有认证公告经过的每一个自治系统，更没有测量实际数据包的延迟、丢包或回程。正确读法要把验证对象、政策动作、观测范围和用户结果分成四层。

起源验证比较的是前缀、长度和起源AS

BGP公告携带一个可达前缀以及路径属性。RFC 4271把路由定义为目的前缀与路径属性的组合。AS_PATH是其中一个属性，记录这条路由信息在传播过程中经过的自治系统序列。

AS_PATH末端通常用来识别起源AS。RPKI中的ROA则由地址资源持有者发布，把一个地址块、获授权的起源AS和允许的最长前缀长度联系起来。验证系统把收到的公告与当前可用的ROA资料比较。

这里有三个容易混淆的对象。地址块说明授权覆盖哪段空间；起源AS说明谁可从BGP发起该前缀；最长长度限制获授权公告可以细分到什么程度。起源AS正确但公告比授权更具体，仍可能得到Invalid。

例如，ROA授权AS 64500发布203.0.113.0/24，最长长度也是/24。该AS发布/24时可匹配。若它发布两个/25，起源号码相同，但长度超出授权范围，验证结果会改变。不能只看AS号码就判断状态。

Valid说明匹配，不说明整条路径安全

当至少有适用ROA，公告前缀、长度和起源AS满足授权条件时，结果可以是Valid。这个状态支持一个有限结论：在验证时所用的RPKI资料里，该起源获得了覆盖这项公告的授权。

Valid不验证AS_PATH中间每一段关系。RFC 7115明确指出，RPKI起源验证不解决AS_PATH验证问题。一个公告即使由获授权AS发起，中间传播仍可能出现策略错误、路径泄漏或其他异常。

它也不证明服务器、DNS或应用正常。BGP控制平面可能有可用路由，数据平面的某台设备仍在丢包。目标主机也可能拒绝连接。把Valid翻译成“网站安全且可访问”，跨越了协议没有检查的多个层次。

Valid更不能证明路径地理位置。AS_PATH列的是自治系统，不是城市、机房、海底电缆或每一跳路由器。一个AS可能在多个国家运营，也可能通过不同内部链路承载流量。公开地图若把AS序列画成线，只是可视化，不是物理轨迹测量。

Invalid说明授权冲突，不等于全球不可达

Invalid通常表示存在覆盖该前缀的ROA，但公告的起源AS不被授权，或公告长度超过ROA允许范围。它应引起调查，因为配置错误、过度细分或未经授权的起源都可能产生同一状态。

状态本身不告诉观察者原因。一次网络迁移可能忘记更新ROA；地址持有者可能把最长长度设得过窄；路由器也可能错误地从另一个AS发起公告。恶意劫持只是可能性之一，不能由标签单独确认。

Invalid也不自动规定全球路由器丢弃公告。RFC 8481强调系统应设置验证状态，但没有运营商配置时不应自行执行政策动作。状态是政策输入，不是全球统一命令。

一部分网络可能拒绝Invalid，另一部分网络可能降低优先级，还有网络暂时只记录状态。于是同一前缀可能对某些接入网络不可达，对另一些仍可达。这种差异本身就是需要保存的观测，不应被平均成“全网正常”或“全网中断”。

即使某网络接受Invalid，最长前缀匹配仍可能影响转发。RFC 7115提醒，若更具体的Invalid路由仍被接受，单纯降低本地优先级未必能阻止流量流向它。政策效果要结合路由选择规则读取。

NotFound表示缺少覆盖资料，不是恶意评分

NotFound通常表示验证系统没有找到覆盖该公告的适用ROA。它没有说公告被授权，也没有说公告未经授权。最准确的表达是：当前验证资料不足以形成Valid或Invalid比较。

RPKI部署并非从一开始就覆盖所有前缀。RFC 7115讨论渐进部署时指出，NotFound会长期存在，运营商通常仍需对这些路由提供服务。把NotFound一律丢弃，可能让尚未发布ROA的合法网络失去可达性。

NotFound也可能随时间改变。资源持有者发布新ROA后，它可能成为Valid；错误ROA覆盖了该空间，也可能让同一公告变成Invalid。分析截图若没有验证时间和资料来源，日后难以重现当时状态。

因此，面向使用者的看板不宜把NotFound涂成与恶意相同的红色。可以显示“没有覆盖授权资料”，并另列观察时间。颜色若保留，也应在图例中明确它不是攻击判决。

状态计算和路由动作是两个阶段

RFC 8481的核心澄清是“设置状态”和“采取动作”不能混为一谈。路由器可给收到的公告附上验证状态；运营商再依据自己的政策、邻接关系和风险管理决定如何使用。

政策可能按客户、对等体和上游分别处理。网络对自有客户的Invalid公告或许直接阻挡，对其他来源则先告警。也可能用社区属性传播状态，让下游设备再决定。只看到最终标签，无法还原全部策略。

本地政策还会与LOCAL_PREF、前缀长度、邻接类型等选择因素共同作用。Valid不一定成为最佳路径，Invalid也不一定在所有实现中立即消失。判断某网络采取什么动作，需要该网络的政策说明或从其视角取得路由结果。

这也是为什么两个看板可能对同一事件给出不同可达判断。它们可能使用不同验证缓存、不同收集器，或把状态映射到不同提示。差异不能直接归咎于某一方错误，必须比较输入和规则。

验证缓存让时间成为必要字段

路由器通常不自行遍历全球RPKI资料，而是从依赖方验证器或缓存取得经过处理的有效授权载荷。缓存抓取、验证和传送存在周期，因此不同系统在短时间内可能持有不同版本。

资源持有者刚修改ROA时，旧缓存可能仍保留先前状态。某个RPKI资料库暂时无法访问，也可能触发缓存保留或失效规则。只比较两个界面的结果，不记录更新时间，就无法区分政策差异与资料时间差。

一份可复查记录应包含验证器资料更新时间、路由公告时间和观察时间。三者不是同一时钟。公告先出现、ROA后发布，与ROA先存在、公告后来冲突，运营含义并不相同。

时区也应明确。BGP更新常用UTC，现场报告可能用当地时间。若相差数小时，观察者会把不相关的事件排在一起。保存原始时间与时区比把时间改成“上午”或“晚上”更可靠。

AS_PATH是控制平面属性，不是逐包轨迹

RFC 4271说明，外部BGP发言者传播路由时会在AS_PATH中加入自己的AS号。这个序列表达路由信息如何传播，也参与环路防止和路由选择。

它没有列出自治系统内部的每台路由器，也没有告诉数据包使用哪根光纤。运营商可在内部改选链路而不改变外部AS_PATH。反过来，AS_PATH改变也可能只是出口政策变化，用户数据平面延迟没有明显变化。

路径还可能使用聚合、路由反射、联盟或其他机制。读取者应把AS_PATH称为“控制平面观察到的AS序列”，不要简写成“数据包实际经过的完整路线”。

返回流量也可能走不同路径。公开公告通常帮助理解到目标前缀的正向可达信息，不能据此倒序填充回程。用户看到的往返延迟同时包含正向与回程，单边BGP序列不足以定位哪一段增加时间。

RIPE RIS只看见其对等体提供的视角

RIPE RIS使用分布式路由收集器接收BGP资料。多数收集器位于互联网交换点并与参与网络建立会话，部分收集器通过多跳会话接收更远对等体的路由。

收集器的价值在于持续保存多个网络视角，而不是拥有全知视角。没有与收集器建立会话的路由器，其最佳路径不会被直接记录。即使同一运营商参与，它送给收集器的路径也可能与送给客户或其他上游的路径不同。

因此，“RIS没有看见”只支持“所查收集器和对等体在该时间没有提供该记录”。它不自动等于互联网无人可达。同样，“十个对等体看见”说明可见范围扩大，却仍不是所有网络的一致状态。

选择收集器时要记录地理和拓扑位置、对等体AS以及会话状态。若事件只在某一区域发生，远端单一收集器可能没有相关视角。比较多个独立对等体，比重复查询同一聚合图更有信息量。

状态转储与更新记录回答不同问题

RIPE的MRT原始资料通常分成状态转储和更新文件。状态转储保存某一时点收集器所持的路由状态，适合回答“当时有哪些路径”。更新文件保存一段区间内收到的公告和撤回，适合回答“期间发生哪些变化”。

只有更新而没有前一状态，可能不知道一条撤回对应哪条既有路径。只有状态转储，又会漏掉两次快照之间出现后又消失的短事件。分析应把两类资料接起来，并保留文件时间范围。

更新数量大也不必然表示用户故障。一次会话重置可产生大量消息，最终最佳路径可能很快恢复。更有意义的指标包括持续时间、受影响前缀、看到事件的独立对等体数量和最终状态。

聚合界面常把多个更新压缩成一条“路径变化”。阅读时应寻找原始前后路径、公告与撤回类型、收集器及对等体。没有这些字段，事件只能作为线索，不能支持精确归因。

从三态到用户影响需要数据平面证据

控制平面告诉网络可选的路由信息，数据平面告诉实际任务是否完成。要判断RPKI事件是否影响用户，必须让两类记录在目标、接入网络和时间上对齐。

目标应使用具体前缀和实际解析地址。一个域名可能同时返回IPv4、IPv6或多个CDN地址，其中只有一个前缀出现状态变化。若用户实际连接另一个地址，把事件归因给该前缀就不成立。

接入网络也要匹配。某个运营商拒绝Invalid，不代表另一运营商相同。可以从不同接入网络测试DNS解析、TCP或QUIC连接、TLS建立和真实页面任务。结果应保留成功、超时与错误阶段，不只保存一个总延迟。

测量时间窗要覆盖事件前、事件中和恢复后。若延迟早在BGP变化前已经上升，或事件结束后仍持续，单一RPKI解释就变弱。反之，多个相关接入网络在相同窗口同步失败，证据链会更强，但仍需排除服务器或DNS共同故障。

一组反例能防止扩大结论

第一种情况是Valid但不可达。起源AS与ROA完全匹配，运营商却因光纤故障没有可用数据平面，或服务器端口关闭。正确结论是起源授权匹配，同时存在另一层可达故障。

第二种情况是Invalid但部分可达。部分运营商拒绝该公告，部分仍接受。不同用户报告相反结果并不矛盾。记录应按接入AS分组，而不是投票决定全球状态。

第三种情况是NotFound且长期稳定。前缀持有者没有发布ROA，公告仍按传统BGP政策传播。这里可以推动补充授权，但不能把多年正常服务突然写成已确认劫持。

第四种情况是收集器看见AS_PATH变化，真实任务没有变化。出口策略切换改变控制平面序列，内部容量仍足够。观察者应记录“路径属性变化，未观察到同步用户影响”，而不是制造性能事故。

第五种情况是用户变慢但收集器没有变化。拥塞发生在AS内部、无线接入或服务器端，不会必然改变BGP公告。这说明没有BGP变化也不能排除网络问题。

建立可复查的观察表

控制平面栏记录目标前缀、公告长度、起源AS、AS_PATH、公告或撤回、收集器、对等体和UTC时间。RPKI栏记录ROA前缀、最长长度、授权AS、验证状态、验证器资料时间和所用信任锚。

政策栏只写有证据的动作，例如“该接入网络从其路由视角未选用该公告”。若只有公开标签，动作保持未知。不要从Invalid替网络填上“已阻挡”，也不要从Valid填上“已信任”。

数据平面栏记录测试位置的非敏感描述、接入AS、解析地址、协议、连接阶段、真实任务和结果。分享时无需公开家庭IP、账号或精确地址；区域和测量编号通常足以复查。

结论分成事实、推论与未知。事实可以是“RRC某对等体在某时收到起源AS变化”。推论可以是“与部分接入网络不可达时间重合”。未知则包括运营商具体政策、回程和服务器内部状态。

来源核对记录：IETF《RFC 6811》，2013。IETF《RFC 7115》，2014。IETF《RFC 8481》，2018。IETF《RFC 4271》，2006。RIPE NCC《Route Collectors》，2025。RIPE NCC《MRT Files》，2023。

Valid、Invalid与NotFound是有用的路由起源证据，但它们的力量来自边界清楚。把前缀授权、政策动作、收集器视角和用户任务分开，再用一致目标与时间把它们连接，才能解释一次事件。任何省略这些层次的红绿标签，都只能作为调查入口。

资料来源

• Internet Engineering Task Force：《RFC 6811: BGP Prefix Origin Validation》，发布或更新于 2013-01-01
• Internet Engineering Task Force：《RFC 7115: Origin Validation Operation Based on the RPKI》，发布或更新于 2014-01-01
• Internet Engineering Task Force：《RFC 8481: Clarifications to BGP Origin Validation Based on RPKI》，发布或更新于 2018-09-01
• Internet Engineering Task Force：《RFC 4271: A Border Gateway Protocol 4》，发布或更新于 2006-01-01
• RIPE NCC：《RIPE RIS Route Collectors》，发布或更新于 2025-04-09
• RIPE NCC：《Route Collection Raw Data: MRT Files》，发布或更新于 2023-04-04