RPKI invalid routes: monitoring route origin validation

RPKI (Resource Public Key Infrastructure) route origin validation is a strong signal for detecting BGP hijacks and route leaks before they reroute traffic. A route classified Invalid by RPKI is, with high confidence, not originated by the authorized AS. Accepting one is a security event.

The monitoring problem: RPKI validation state is not exposed through any standard SNMP MIB. BGP4-MIB (RFC 4273) predates RPKI entirely. CISCO-BGP4-MIB has no validation-state column. There is no portable OID to count invalid routes across a multi-vendor estate. Every platform exposes this through its own CLI, proprietary MIB extensions, or BMP (RFC 7854).

This article covers the validation state taxonomy, the supply chain that produces it, the vendor-specific commands to query it, and the operational gotchas that make RPKI monitoring harder than it looks.

What the three validation states mean

Per RFC 6811, every BGP route is classified into exactly one of three states based on comparison against the Validated ROA Payload (VRP) table:

Not-Found is not a failure state. It is the absence of a signal. A significant fraction of Internet prefixes still have no ROA. A hijack of a Not-Found prefix is invisible to RPKI validation alone and requires AS-path baseline monitoring (via BMP or external route collectors) to detect. RPKI validity alone is not sufficient. Combine it with AS-path monitoring for coverage of prefixes without ROAs.

The RPKI validation supply chain

Routers do not perform public-key cryptography on BGP routes. They receive a pre-validated VRP table from a relying party (RP) validator over the RPKI-to-Router (RTR) protocol (RFC 8210, TCP port 323). The validator (common implementations: RIPE Routinator, NLnetLabs rpki-client) does the cryptographic work: fetching ROAs from publication points, verifying signatures, and producing the VRP table.

flowchart LR
  ROA[ROA published in repository] --> RP[RP validator: Routinator or rpki-client]
  RP -->|RTR protocol, TCP 323| RTR[BGP router VRP cache]
  RTR -->|Per-route classification| S{Validation state}
  S -->|Valid| A1[Accept route]
  S -->|Invalid| A2[Reject or de-prefer]
  S -->|Not-Found| A3[Accept, monitor AS-path]

The validation state on your router is only as fresh as the last successful RTR session update. If the validator falls behind, your router operates on a stale VRP table and may accept routes that should be Invalid.

The monitoring gap: no standard SNMP MIB

BGP4-MIB (RFC 4273) defines bgpPeerState, bgpPeerInUpdates, and the bgp4PathAttrTable, but none of these expose RPKI validation state. The bgp4PathAttrTable reflects only best-path routes; the Adj-RIB-In is not accessible via standard SNMP. CISCO-BGP4-MIB similarly lacks a validation-state column.

You cannot monitor RPKI invalid route counts with a standard SNMP poll. Options:

1. Vendor CLI scraping. SSH to each router and parse show command output. Works everywhere, but brittle and slow at scale.
2. Vendor-proprietary MIB extensions. Some vendors may expose RPKI counters through enterprise MIBs, but coverage is inconsistent and cross-platform normalization is manual.
3. BMP (RFC 7854). A BMP monitoring station receives the full Adj-RIB-In (pre-policy and post-policy), with per-prefix RPKI state, AS-path, and real-time streaming. This is the most complete signal but requires explicit deployment of a BMP speaker and collector.
4. External route collectors. Compare your RIB against public validators (RIPEstat, Routinator, RIPE RIS, RouteViews) to detect discrepancies.

For teams relying solely on BGP4-MIB, RPKI validation state is a blind spot. A hijacked prefix accepted by an upstream can propagate into your RIB with no SNMP signal. You see best-path only, never pre-policy, never rejected routes.

Querying validation state by platform

The following commands are the primary interface for checking RPKI validation state on each major platform. None are exposed through BGP4-MIB.

Juniper’s show validation statistics provides aggregate counters for Valid, Invalid, and Unknown policy requests, the closest thing to a summary counter across major platforms. The show validation database command shows the VRP table contents. On Junos, trace logging is available with set routing-options validation traceoptions file <name> flag all.

RTR server configuration is platform-specific. On Cisco IOS/IOS-XE, the RTR server is configured with bgp rpki server tcp <host> port 323 under router bgp. On Arista EOS, it is rpki cache <host> local-interface <loopback> under router bgp.

Operational gotchas

Validator sync delay

The dominant operational surprise is the lag between a ROA change and router-side enforcement. A ROA published or modified by the resource holder must propagate through the publication point, be fetched by the validator, verified cryptographically, pushed to the router via RTR, and re-evaluated against the existing BGP RIB.

In practice, this takes 5 to 15 minutes, not seconds. Validator synchronization is the bottleneck. A ROA created to authorize a new origin will not protect that route immediately. Conversely, if a ROA is removed, invalid routes previously rejected may start being accepted until the VRP table updates and the router re-evaluates.

Best-path integration defaults

On Cisco IOS/IOS-XE, bgp bestpath prefix-validate is enabled by default, meaning RPKI validation intervenes directly in BGP best-path selection. This can cause routing loops in IBGP topologies where not all routers have the same VRP table state. The recommended pattern is to disable best-path integration (bgp bestpath prefix-validate disable per address family) and handle validation explicitly in a route-map with match rpki invalid.

On Huawei VRP, bestroute origin-as-validation causes invalid routes to be silently ignored during route selection without explicit route-map action. Operators who want to monitor invalid routes before acting on them must disable this default first.

BIRD 2.0 manual revalidation

BIRD 2.0 does not automatically revalidate BGP routes when the VRP table updates via RTR. If a new ROA arrives that should change a route’s classification, the route keeps its old state until the operator manually triggers reload in <protocol-name>. BIRD 3.0 addressed this with automatic revalidation.

This is a silent failure mode: the router accepts or rejects based on stale VRP state with no indication. BIRD 2.0 operators upgrading should verify auto-revalidation is active.

Do not propagate validation state as a BGP attribute

RFC 8097 defines an optional non-transitive BGP extended community that carries the RPKI validation state. It is deprecated. The problem: whenever a ROA changes, every route whose validation state shifted requires a fresh BGP UPDATE, even though the NLRI did not change.

IOS-XR’s bgp origin-as validation signal ibgp implements this behavior. Do not configure it. draft-ietf-sidrops-avoid-rpki-state-in-bgp formalizes the guidance to stop carrying validation states in BGP.

The same concern applies to transitive RPKI state communities (for example, 3356:901 for Valid and 3356:902 for Invalid on Lumen, or 1299:430 for Valid on Arelion). These propagate across AS boundaries and cause the same UPDATE churn. Do not store validation state in bgp_community or bgp_large_community variables.

Soft reconfiguration may be required

When VRP tables update, routers re-evaluate installed routes. Without soft-reconfiguration inbound configured on EBGP neighbors (IOS/IOS-XE) or per neighbor per address family (IOS-XR), the router has no stored pre-policy Adj-RIB-In to validate against. It must request route-refresh from the peer. If the peer does not support route-refresh, an invalid route that should be rejected after a VRP update may remain in the RIB until the next full session reset.

Nokia SR OS best-path knob removed

The compare-origin-validation-state true knob under best-path-selection on Nokia SR OS was removed in a November 2024 update to the BGP Filter Guide.

It previously inserted RPKI state as a step in the BGP decision process between invalid-route removal and local-preference comparison, producing unpredictable behavior. Operators who had this configured should remove it. The recommended replacement is best-path-selection origin-invalid-unusable true.

Signals to watch in production

A stale validator cache can produce false Invalid classifications. Before alerting on a single Invalid route, cross-reference with a public validator (RIPEstat, Routinator) to confirm the ROA state is current.

How Netdata helps

Netdata can correlate RPKI signals with broader BGP and network health:

• Correlate RPKI invalid counts with per-peer prefix changes. A spike in invalid routes from one peer alongside a sudden prefix-count increase is a high-confidence route leak signal.
• Monitor RTR session liveness alongside BGP session state. An RTR session drop does not tear down BGP sessions, but it silently degrades validation. Track both independently.
• Track BGP NOTIFICATION Cease/1 (Maximum Prefixes) alongside RPKI invalids. A peer exceeding prefix limits while also sending Invalid routes is a strong leak indicator. See BGP NOTIFICATION and Cease messages.
• Integrate BMP-derived AS-path data for Not-Found hijack detection. RPKI validity alone misses hijacks on prefixes without ROAs. AS-path baselining via BMP fills the gap.
• Alert on validator health proxies. If the Not-Found rate suddenly spikes (VRP table emptied) or the VRP count drops, page immediately. This is a validator outage, not a network event.
• Cross-reference with BGP session freshness. A stale BGP session can mask route loss. See BGP session Established but stale.

Related guides

• BGP route leak and hijack: the detection signals and alerts that matter
• BGP NOTIFICATION and Cease messages: what each subcode is telling you
• BGP session Established but stale: detecting silent route loss
• BGP flapping: why a peer keeps resetting and how to find the cause
• Network monitoring checklist: the signals every production network needs