RPKI route checks: Stop Invalid BGP announcements

As of June 2026, the math doesn't add up. We have over 375,000 valid Route Origin Authorizations sitting in the global system, yet zero valid router certificates exist to enforce them. This isn't a gap; it's a chasm. IP holders are signing ROA records, but the infrastructure to cryptographically verify BGP announcements at the router level remains critically incomplete. The industry relies on Regional Internet Registries like ARIN and RIPE to publish data, but that data dies in the validator unless we force the final step of enforcement.

This guide skips the theory on how RIR databases feed validators like Routinator. Instead, we focus on the only part that matters: enforcing policy on Cisco and FRRouting platforms. We dissect the three validation states-Valid, Invalid, and NotFound-and explain exactly how each dictates whether your router accepts a route or drops it.

You will get specific instructions for installing Routinator on Linux and configuring the RTR Protocol to push cache data to border routers. We detail creating route maps that assign high local preference to Valid routes while explicitly dropping Invalid announcements. Follow these steps to move from a NotFound majority to a verified routing environment using tools already in your standard distributions.

The Role of RPKI in Modern BGP Security Architecture

RPKI Cryptographic Framework and ROA Records

Resource Public Key Infrastructure (RPKI) is a cryptographic framework that lets IP holders authorize specific Autonomous Systems to originate prefixes. It relies on Route Origin Authorizations (ROAs), which are digitally signed records linking a prefix to an authorized ASN. Traditional BGP accepts all announcements equally, creating a trust-but-verify-none model. RPKI breaks this by introducing three distinct validation states: Valid, Invalid, and Unknown.

A route achieves Valid status only when a matching ROA confirms both the origin AS and prefix length. An Invalid state indicates a mismatch in ASN or an excessive prefix length. Unknown signifies the absence of any covering ROA. This binary logic replaces heuristic guessing with cryptographic proof.

BGP Router Validation of Valid Invalid and NotFound States

BGP routers classify each route as Valid, Invalid, or NotFound by matching announcements against cached ROAs. A route reaches the Valid state only when the prefix falls within a ROA, the origin AS matches exactly, and the announced length does not exceed the set max-length. An Invalid designation occurs if at least one ROA covers the prefix but no record matches both the originating AS and the prefix length constraints.

The NotFound status applies when no ROA covers the prefix, leaving the origin authorization technically unknown rather than cryptographically verified. Operators configure policy to prefer Valid paths while explicitly dropping Invalid updates to block hijacks. Origin-focused approaches provide immediate, deployable security for IPv4 infrastructure unlike path validation mechanisms that remain largely theoretical.

Handling NotFound routes presents the primary operational challenge. Rejecting them breaks connectivity for unregistered legacy prefixes. Accepting them leaves a window for potential sub-prefix hijacks where no ROA exists to trigger an Invalid flag. Implementing strict validation requires precise ROA management to avoid self-inflicted outages during migration. Network architects must balance security posture against the reality that global ROA coverage remains incomplete, making the NotFound state the most common outcome for much of the current routing table.

Misconfigured maxLength or ASN fields trigger Invalid states that block legitimate traffic. Studies presented at NDSS 2026 indicate that greater than a significant majority of detected Invalid prefixes are false positives caused by such configuration errors. Operators frequently set maxLength too strictly or mistype the origin ASN, causing valid announcements to fail cryptographic verification. The global RPKI system currently holds hundreds of thousands of records, yet coverage remains near a significant share of routed prefix-AS pairs. A strict drop-invalid policy without monitoring creates immediate availability risks when human error occurs. Networks must implement alerting on validation state changes to distinguish attacks from typos.

The operational cost of false positives outweighs the theoretical security gain if hygiene is poor. Teams should prioritize accurate ROA management over aggressive filtering defaults.

Inside the RPKI Validation Workflow and Data Flow

RPKI Validator Data Fetching from RIR Repositories

The RPKI Validator initiates synchronization by fetching signed data from the five RIRs: ARIN, RIPE, APNIC, LACNIC, and AFRINIC. The architectural flow moves from these Regional Internet Registries to a ROA Repository, where registries publish Trust Anchor Locators that point validators to specific endpoints containing cryptographically signed prefix authorizations. Unlike routers that rely on lightweight lookups, the validator performs heavy cryptographic lifting to verify signatures before distributing a clean cache to the network edge. This separation ensures that production routers process only pre-validated routing information via the RTR protocol. Operators typically deploy software like Routinator or OctoRPKI to handle this fetch-and-verify cycle independently of the forwarding plane.

The process follows a strict sequence to maintain data integrity:

1. The validator retrieves the latest manifest from each RIR trust anchor.
2. It downloads and cryptographically verifies all associated ROA files.
3. A consolidated, validated dataset is pushed to connected BGP routers.

Update frequency battles network stability. Frequent fetching reduces the window of vulnerability for new hijacks, but aggressive refresh rates strain repository servers and increase the risk of transient validation failures during global updates. Consequently, most deployments standardize on a refresh interval of 600 seconds to balance security responsiveness with operational reliability. This approach allows operators to optimize existing IPv4 resources by ensuring that only authorized origin announcements propagate through the global routing table, directly mitigating the risk of prefix hijacking without requiring changes to core router CPU architectures. As of June 2026, there are zero valid router certificates published in the Internet's RPKI system, contrasting with over 375,000 valid Route Origin Authorizations.

RTR Protocol Refresh Cycles Between Validator and Router

The BGP router receives updated validation data from the RPKI Validator every 600 seconds via the RTR Protocol running over TCP. This specific refresh time parameter ensures that routing decisions reflect the latest cryptographic state without overwhelming the control plane. Operators must configure this interval correctly to address RPKI validation connection issues where stale caches cause valid routes to appear invalid temporarily. The architecture separates heavy cryptographic verification from the forwarding plane, allowing the router to rely on a clean list of prefixes fed by software like Routinator or OctoRPKI.

A common problem with ROA not found status arises when the validator fails to fetch updates from the RIR repositories due to network segmentation. The RTR protocol uses TCP as its underlying transport mechanism for communication between the validator and the router. Because the system relies on synchronized data, maintaining a stable connection is necessary for ensuring routers have the latest valid/invalid/not-found sets. Monitoring the RTR serial number helps detect synchronization gaps before they impact production traffic flow.

False Positive Risks from Incorrect ASN or MaxLength Settings

A mistyped ASN or restrictive maxLength in a ROA immediately flags legitimate routes as invalid, causing routers to drop traffic. Configuration errors rather than malicious hijacks account for a significant portion of detected invalid prefixes, creating a high false positive rate that forces a strategic tension between strict security policies and uninterrupted availability. Operators implementing rigid drop policies risk self-inflicted outages if their own ROA records contain minor syntax errors or if upstream partners misconfigure their authorizations.

To mitigate this operational fragility, networks increasingly adopt fallback mechanisms. Instead of permanently blackholing invalid routes, routers revert to less-specific prefixes or non-ROV paths when validation fails. This approach maintains a security posture while preventing total connectivity loss during configuration drift. The following table contrasts the operational outcomes of different validation policies:

Optimizing existing IPv4 resources requires precise management of these cryptographic records to avoid accidental service denial. The primary challenge in modern deployment is not enabling validation, but sustaining the operational hygiene required to keep ROA data accurate. Without continuous monitoring, the very mechanism designed to secure routing can become a source of instability.

Deploying RPKI Validation Across Cisco and FRRouting Environments

Routinator Deployment and RTR Server Initialization

Install Routinator on a Linux host using `sudo apt-get install routinator` to establish the local validation engine. Current releases ship with bundled RIR TALs, eliminating manual initialization steps for trust anchor configuration. The daemon downloads ROAs from all five registries and serves them to routers via the RTR protocol.

1. Execute `routinator server --rtr=192.168.1.100:3323 --http=127.0.0.1:9556` to bind the service.
2. Test validation lookups using `routinator validate --prefix=203.0.113.0/24 --asn=65001` to confirm data retrieval.

This architecture offloads cryptographic verification from the router control plane, preserving CPU cycles for path selection. The RTR protocol typically operates with a refresh time of 600 seconds, ensuring routers receive regular updates on prefix origin authenticity. While the validator acts as a central data source, the RTR protocol uses TCP as its underlying transport mechanism to maintain reliable communication between the validator and the router.

Configuring Cisco IOS BGP RPKI Cache and Route Maps

Defining the RPKI cache server via TCP establishes the critical link between Cisco IOS and the validation infrastructure. Operators must input the specific command `bgp rpki server tcp 192.168.1.100 port 3323 refresh 600` within the BGP context to synchronize with the external validator. This connection allows the router to receive processed cryptographic data rather than performing heavy signature verification locally.

Applying the route-map logic enforces the desired security posture by explicitly dropping routes marked as invalid. The configuration sequence denies any prefix failing the origin check while assigning higher local-preference values to valid announcements. Traffic matching the not-found state receives a standard preference, ensuring connectivity for unstabilized parts of the global table. This tiered approach assigns a local-preference of 200 to valid routes and 100 to not-found routes.

A strict deny policy prevents installation of hijacked prefixes but risks outages if internal ROA records contain errors. Operators should be aware that configuration mistakes in maxLength fields often trigger false rejections of legitimate traffic flows. This careful staging balances security gains against the operational reality of imperfect data.

Validating RPKI Connection Status and Prefix States

Confirm the RTR session state using `show ip bgp rpki servers` to ensure the cache synchronization is active.

1. Execute the command to verify the neighbor IP and port connectivity.
2. Inspect the serial number to confirm recent data updates from the validator.
3. Check that the refresh timer aligns with the configured interval.

Operators must distinguish between a disconnected session and a valid session containing no matching records. A route is marked as not-found when no ROA covers the prefix, indicating the status is unknown rather than a failure of the local cache to populate. This distinction prevents unnecessary escalation when the issue is merely the absence of a specific record in the global database.

Use `show ip bgp 198.51.100.0/24` to inspect the specific validation state assigned to an IPv4 prefix. The output explicitly labels the route as valid, invalid, or not-found based on the cached cryptographic material. The validation state in BGP extended community attributes is treated as a 32-bit unsigned integer to represent the status of a route. Production stability relies on this granular visibility into the RPKI decision process.

Strategic Best Practices for RPKI Adoption and ROA Management

ROA Registration Requirements for RIR Prefix Protection

Creating a Route Origin Authorization demands registration with a Regional Internet Registry like ARIN, RIPE, or APNIC. The operator must supply three precise data fields to authorize prefix announcements effectively. First, the Origin AS field specifies the autonomous system number permitted to originate the route. Second, the Prefix input defines the allocated IP block, such as a public /24. Third, the Max-length parameter sets the maximum prefix length allowed, which typically matches the allocated prefix size to prevent more specific hijacks.

A route becomes invalid if the announcement exceeds this set maximum length or originates from an unauthorized AS. This strict matching logic creates a tangible operational risk where minor typos in the ASN field instantly blackhole traffic. The limitation of this approach is its binary nature; a single character error triggers a hard fail rather than a warning. Operators must therefore treat ROA creation as a critical change management event requiring peer review. Properly configured records empower downstream networks to filter unauthorized announcements automatically. This mechanism shifts security from voluntary cooperation to cryptographic enforcement at the edge.

Preventing False Positives via Correct ASN and MaxLength Configuration

Misconfigured Origin AS values and excessive Max-length parameters generate the vast majority of RPKI-invalid flags observed in production networks today. This statistical reality shifts the operational focus from mere deployment to rigorous data hygiene during ROA creation.

When an operator sets a Max-length value larger than the announced prefix, any more-specific route automatically triggers an invalid state. The consequence is immediate traffic loss if the receiving network enforces a drop policy on invalid routes. This outcome highlights a critical tension between granular prefix management and the risk of accidental self-denial of service.

Operators must verify that registered ROA entries match their actual BGP announcements exactly before enabling strict validation policies. Fallback mechanisms allow traffic to revert to less-specific prefixes when an invalid route is detected, mitigating the impact of configuration slips. Proper alignment ensures legitimate traffic remains unaffected while maintaining a strong security posture against unauthorized origin announcements.

Operational Checklist for Enabling RPKI Validation Safely

Verify ROA data accuracy before enabling strict drop policies to prevent self-inflicted outages. Most invalid flags stem from administrative errors rather than active hijacking attempts.

1. Cross-reference your Origin AS and Max-length fields against production announcements.
2. Configure route maps to tag but not drop invalid routes during the initial monitoring phase.
3. Establish a fallback mechanism where traffic reverts to less-specific prefixes if validation fails unexpectedly.

InterLIR recommends maintaining a permissive policy for NotFound states while the global system covers only a portion of the routing table. Dropping routes without a matching record causes immediate connectivity loss for unregistered peers. The primary tension exists between maximizing security posture and maintaining universal reachability in a partially deployed system. Operators must prioritize data hygiene over aggressive filtering until coverage matures. This approach protects prefixes from unauthorized-origin hijacks while preserving network stability. Implementation requires careful coordination between registry records and live BGP announcements.