If you run BGP in production today and you are not validating route origins with RPKI, you are accepting every prefix announcement on trust alone. That is the equivalent of letting anyone walk into your data center and plug into a switch because they said they work there. BGP RPKI Route Origin Validation (ROV) is the mechanism that changes this, and with the formal deprecation of AS_SET in RFC 9774 (May 2025) and NIST SP 800-189 Rev. 1 pushing RPKI as the baseline for routing security, the time to deploy it is now.

This article walks through the core concepts of RPKI and ROV, shows you exactly how to configure it on Cisco IOS-XE and IOS XR, and covers the verification and troubleshooting steps you need to operate it confidently in production.

How RPKI Route Origin Validation Works

RPKI (Resource Public Key Infrastructure) is a cryptographic framework that binds IP address prefixes to the autonomous systems authorized to originate them. At its core, the system has three components:

Route Origin Authorizations (ROAs) are signed objects published by prefix holders in RPKI repositories. A ROA states: “AS 65001 is authorized to originate 192.0.2.0/24 with a maximum prefix length of /24.” This is the source of truth.

RPKI Validators (also called Relying Party software) are servers that download ROA data from the five Regional Internet Registry (RIR) trust anchors, validate the cryptographic signatures, and build a validated cache of prefix-to-origin mappings. Popular validators include Routinator, Fort, and OctoRPKI.

RPKI-to-Router Protocol (RTR) is the protocol defined in RFC 8210 that transports the validated cache from the validator to BGP routers. The router uses this data to tag each BGP prefix with a validation state:

  • Valid: The prefix and origin AS match a ROA.
  • Invalid: A ROA exists for the prefix, but the origin AS or prefix length does not match.
  • NotFound: No ROA exists for the prefix.

The router then applies policy based on these states – typically dropping Invalid routes and preferring Valid ones.

Pro Tip: Do not confuse “NotFound” with “Invalid.” A NotFound prefix simply has no ROA published yet. Dropping NotFound routes would black-hole roughly 60% of the global routing table today. The safe starting policy is: drop Invalid, accept everything else, and prefer Valid routes with a higher local preference.

Connecting to an RPKI Validator on IOS-XE

The first step is connecting your router to an RPKI validator over the RTR protocol. You can run your own validator (recommended for production) or use a public validator for testing.

The following configuration establishes an RTR session to a local validator running on 10.0.0.50 port 8282, with a secondary validator at 10.0.0.51 for redundancy:

! IOS-XE: Configure RPKI cache servers
router bgp 65001
 bgp rpki server tcp 10.0.0.50 port 8282 refresh 300
 bgp rpki server tcp 10.0.0.51 port 8282 refresh 300

The refresh 300 parameter sets the poll interval to 300 seconds. The router will also receive incremental updates (Serial Notify) from the validator between polls, so the refresh is a safety net rather than the primary update mechanism.

On IOS XR (for example, on Cisco 8000 Series routers running IOS XR 25.4.1), the configuration uses an explicit RPKI server definition:

! IOS XR: Configure RPKI cache servers
router bgp 65001
 rpki server 10.0.0.50
  transport tcp port 8282
  refresh-time 300
 !
 rpki server 10.0.0.51
  transport tcp port 8282
  refresh-time 300
 !

Pro Tip: Always deploy at least two RPKI validators for redundancy. If your only validator goes down and the RTR session expires, the router will flush its validated cache and treat all prefixes as NotFound – effectively disabling ROV silently. Two validators from different software implementations (e.g., Routinator + Fort) give you both redundancy and implementation diversity.

Applying Route Origin Validation Policy

Having a validator connection is only half the job. Without a route-map that acts on the validation state, the router knows which routes are Invalid but does nothing about it. Here is where the actual security enforcement happens.

On IOS-XE, create a route-map that drops Invalid routes and applies a higher local preference to Valid routes:

! IOS-XE: ROV enforcement route-map
route-map RPKI-POLICY permit 10
 match rpki invalid
 set community no-export additive
 set local-preference 50
!
route-map RPKI-POLICY permit 20
 match rpki valid
 set local-preference 200
!
route-map RPKI-POLICY permit 30
 match rpki not-found
 set local-preference 100
!
! Apply to eBGP neighbor
router bgp 65001
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map RPKI-POLICY in

This policy does three things:

  1. Invalid routes get local-preference 50 and the no-export community. This makes them least preferred and prevents them from being advertised to other peers. In a more aggressive posture, you would use a deny statement to drop them entirely.
  2. Valid routes get local-preference 200, making them strongly preferred in path selection.
  3. NotFound routes get the default local-preference of 100, keeping them functional while not giving them the same trust level as validated routes.

The reason for starting with the “tag and deprioritize” approach for Invalid routes rather than a hard drop is operational safety. When you first enable ROV, you want to monitor which routes are marked Invalid before you start dropping them. Some of those Invalid states may be caused by stale or misconfigured ROAs published by other operators.

Moving to Hard Enforcement

Once you have monitored the Invalid routes for a few weeks and confirmed they are genuinely unauthorized, tighten the policy:

! IOS-XE: Hard enforcement - drop Invalid routes
route-map RPKI-POLICY deny 10
 match rpki invalid
!
route-map RPKI-POLICY permit 20
 match rpki valid
 set local-preference 200
!
route-map RPKI-POLICY permit 30
 match rpki not-found
 set local-preference 100

This is the target state. Invalid routes are silently dropped at the edge, preventing route hijacks from propagating into your network.

Verification and Troubleshooting

Checking Validator Connectivity

On IOS-XE, verify the RTR session status:

Router# show bgp rpki servers

BGP RPKI Server:
  Server Address: 10.0.0.50
  Server Port: 8282
  Server State: established
  Serial Number: 47
  Refresh Time: 300
  Response Time: 15
  Purge Time: 3600
  Protocol Version: 1
  Session ID: 12345
  Record Count: 482631

The key fields to check:

  • Server State should be established. If it shows connecting or down, verify network reachability and that the validator is running.
  • Record Count should be in the hundreds of thousands (the global RPKI dataset currently contains roughly 500,000+ validated ROA entries). If it shows 0 or a very low number, the validator may be misconfigured or still synchronizing.

Checking Validation State for a Specific Prefix

To see the validation state of a specific BGP prefix:

Router# show bgp ipv4 unicast 1.0.0.0/24
BGP routing table entry for 1.0.0.0/24
  Path: 15169 13335, valid, external, best
  Origin: IGP, localpref 200, valid
  RPKI validation state: valid
  Origin AS: 13335
  ROA: 1.0.0.0/24, maxlen /24, origin-as 13335

The RPKI validation state: valid line confirms this prefix is covered by a matching ROA. If you see invalid, investigate the origin AS and prefix length against the published ROAs using an external tool like the RIPE RPKI Validator or Cloudflare’s RPKI portal.

Monitoring Invalid Routes

To see all routes currently marked as Invalid across your BGP table:

Router# show bgp ipv4 unicast rpki invalid

This command is your primary monitoring tool during the initial deployment phase. Review this output daily. Cross-reference the Invalid prefixes against the ROA database to distinguish between genuine hijack attempts and ROA misconfigurations by other operators.

Pro Tip: Set up a syslog or SNMP trap for RPKI session state changes. If your validator sessions go down, you want to know immediately – not discover it during the next change window. On IOS XR 25.4.1 and later, the router will generate syslog warnings when security best practices are not followed, including routing protocol configurations that lack authentication. This same philosophy applies to RPKI: treat a validator session failure as a high-priority alert.

Common Troubleshooting Scenarios

Validator session flapping: Check for MTU issues on the path between the router and validator. RTR uses TCP, and large cache responses can trigger fragmentation if the path MTU is restricted. Also verify that no firewall is blocking the RTR port (typically 8282 or 323 for SSH-secured RTR).

High record count but no Valid routes: Ensure the route-map with match rpki clauses is actually applied to the neighbor. The validation state is computed regardless of policy, but without the route-map, it has no effect on path selection.

Prefix shows NotFound when you expect Valid: The prefix holder may not have published a ROA yet, or the ROA may have expired. Check the ROA status in the RPKI repositories directly. Also verify your validator is synchronizing with all five RIR trust anchors (ARIN, RIPE NCC, APNIC, LACNIC, AFRINIC).

The Bigger Picture: Where RPKI Fits in BGP Security

RPKI ROV is the first layer of BGP security, but it is not the last. The current technology stack is evolving:

ASPA (Autonomous System Provider Authorization) is an emerging IETF standard that extends RPKI to encode the customer-provider relationships between autonomous systems. While ROV validates the origin AS of a route, ASPA enables routers to verify the entire AS path for route leaks – a class of incident that ROV alone cannot detect. If you are working in an SP environment that is also evaluating SRv6 uSID migration from MPLS, note that RPKI ROV remains equally critical on IPv6-native transport – route origin validation applies to the BGP control plane regardless of the underlying data plane technology. NIST is actively developing test tools (the BRIO framework) for ASPA validation, and early adoption is expected in 2026-2027.

BGPsec provides full AS path cryptographic validation but requires every AS in the path to participate, making incremental deployment impractical for now. RPKI ROV remains the pragmatic first step.

The formal deprecation of AS_SET and AS_CONFED_SET in RFC 9774 also simplifies RPKI validation. Previously, routes with AS_SET in the path were ambiguous for origin validation because the set could contain multiple origin ASNs. With AS_SET now prohibited, every route should have a single, unambiguous origin AS, making ROV validation cleaner and more reliable.

For operators performing route aggregation, this means updating your aggregate-address commands to use summary-only without the as-set keyword. Any aggregation configuration still generating AS_SET will produce routes that compliant peers may reject.

Key Takeaways

  1. RPKI ROV is production-ready today. With 500,000+ ROAs published globally and mature validator software available, there is no technical barrier to deployment. The operational risk of not deploying it (accepting hijacked routes) exceeds the risk of deploying it.

  2. Start soft, then harden. Deploy ROV in monitoring mode first (tag Invalid routes with low local-preference and no-export), observe the results for two to four weeks, then move to hard enforcement (deny Invalid).

  3. Redundant validators are non-negotiable. A single validator failure silently disables ROV. Run at least two validators from different software implementations.

  4. ROV is layer one of a multi-layer strategy. ASPA for route leak detection and BGP session authentication (TCP-AO or MD5) complement ROV. Deploy them together as they become available. For CCIE candidates, ROV configuration is increasingly tested — see our CCIE lab first-attempt strategy guide for exam-day time management when dealing with multi-technology verification tasks.

  5. RFC 9774 matters for your aggregation configs. If you are still generating AS_SET in aggregate routes, update your configuration now. Compliant peers will increasingly reject these routes.

  6. Monitor continuously. Treat RPKI validator session failures and unexpected Invalid routes as high-priority operational events. Integrate them into your existing NOC alerting workflows.

BGP security is no longer optional for any network that participates in the global routing system. RPKI ROV gives you a concrete, deployable mechanism to verify route origins today. Configure it, monitor it, and enforce it. If you are building BGP expertise toward a CCIE SP certification, RPKI is one of the foundational topics that separates competent operators from expert-level engineers.

Frequently Asked Questions

What is the difference between RPKI Valid, Invalid, and NotFound?

Valid means the prefix and origin AS match a published ROA. Invalid means a ROA exists but the origin AS or prefix length does not match. NotFound means no ROA has been published for that prefix — roughly 60% of the global table is still NotFound, so dropping these would cause massive outages.

Should I drop all RPKI Invalid BGP routes immediately?

No. Start with a soft policy that tags Invalid routes with low local-preference and no-export community. Monitor for 2-4 weeks to distinguish genuine hijacks from stale or misconfigured ROAs by other operators, then move to hard deny.

How many RPKI validators do I need in production?

At least two, ideally from different software implementations such as Routinator and Fort. If your only validator goes down and the RTR session expires, the router flushes its validated cache and silently disables ROV.

Does RPKI ROV prevent all BGP hijacks?

No. ROV validates the origin AS only. It cannot detect route leaks where a legitimate AS improperly announces a prefix it received from a peer. ASPA (Autonomous System Provider Authorization) is the emerging standard that addresses AS path validation.

What is the performance impact of enabling RPKI on Cisco routers?

Minimal. The router stores roughly 500,000 ROA entries in memory and performs a lookup per prefix update. The RTR protocol uses incremental updates, so steady-state bandwidth consumption is negligible. The main risk is validator failure, not router performance.

Start Your CCIE Journey →