DEV Community

FirstPassLab
FirstPassLab

Posted on • Originally published at firstpasslab.com

Stop Accepting BGP Routes on Trust Alone: Deploy RPKI ROV on IOS-XE and IOS XR Today

#networking #security #cisco #tutorial

If you run BGP in production and you're not validating route origins with RPKI, you're accepting every prefix announcement on trust alone. That's 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. With 500K+ ROAs published globally, mature validator software, and RFC 9774 formally deprecating AS_SET, there's no technical barrier left. Here's how to deploy it on Cisco IOS-XE and IOS XR.

How RPKI ROV Actually Works

RPKI (Resource Public Key Infrastructure) cryptographically binds IP prefixes to the autonomous systems authorized to originate them. Three components make it work:

Route Origin Authorizations (ROAs) — 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."

RPKI Validators — Servers (Routinator, Fort, OctoRPKI) that download ROA data from the five RIR trust anchors, validate cryptographic signatures, and build a validated cache.

RPKI-to-Router Protocol (RTR) — RFC 8210 protocol that transports the validated cache to your BGP routers. Each prefix gets tagged:

  • Valid: Prefix and origin AS match a ROA
  • Invalid: A ROA exists but origin AS or prefix length doesn't match
  • NotFound: No ROA published for this prefix

⚠️ Critical distinction: NotFound ≠ Invalid. ~60% of the global table is still NotFound. Dropping those would black-hole most of the internet. The safe policy: drop Invalid, accept everything else, prefer Valid.

Connecting to RPKI Validators

IOS-XE Configuration 

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
Enter fullscreen mode Exit fullscreen mode

IOS XR Configuration 

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
 !
Enter fullscreen mode Exit fullscreen mode

The refresh 300 sets a 300-second poll interval as a safety net. Incremental updates (Serial Notify) arrive between polls.

🔑 Always deploy at least two validators from different implementations (e.g., Routinator + Fort). If your only validator goes down and the RTR session expires, the router flushes its cache and silently disables ROV. You won't even know it happened.

Applying ROV Policy — Start Soft

Without a route-map acting on validation state, the router knows which routes are Invalid but does nothing about it. Here's where enforcement happens.

Phase 1: Tag and Deprioritize (Weeks 1-4) 

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
!
router bgp 65001
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map RPKI-POLICY in
Enter fullscreen mode Exit fullscreen mode

This does three things:

  1. Invalid routes → local-preference 50 + no-export community (least preferred, not propagated)
  2. Valid routes → local-preference 200 (strongly preferred)
  3. NotFound routes → local-preference 100 (functional, but not as trusted)

Why not hard-drop Invalid immediately? Some Invalid states come from stale or misconfigured ROAs by other operators. You need to observe before you enforce.

Phase 2: Hard Enforcement (After Monitoring) 

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
Enter fullscreen mode Exit fullscreen mode

Now Invalid routes are silently dropped at the edge. Route hijacks don't propagate into your network.

Verification and Troubleshooting

Check Validator Connectivity 

Router# show bgp rpki servers

BGP RPKI Server:
  Server Address: 10.0.0.50
  Server Port: 8282
  Server State: established
  Serial Number: 47
  Record Count: 482631
Enter fullscreen mode Exit fullscreen mode

Key checks:

  • Server State must be established — if connecting or down, check reachability and validator health
  • Record Count should be 400K-500K+ — if 0, the validator isn't syncing

Check a Specific Prefix 

Router# show bgp ipv4 unicast 1.0.0.0/24

BGP routing table entry for 1.0.0.0/24
  RPKI validation state: valid
  Origin AS: 13335
  ROA: 1.0.0.0/24, maxlen /24, origin-as 13335
Enter fullscreen mode Exit fullscreen mode

Monitor Invalid Routes 

Router# show bgp ipv4 unicast rpki invalid
Enter fullscreen mode Exit fullscreen mode

This is your daily monitoring command during initial deployment. Cross-reference Invalid prefixes against the ROA database to separate genuine hijacks from ROA misconfigurations.

Common Issues

Problem Cause Fix
Validator session flapping MTU issues on RTR path Check path MTU; large cache responses trigger fragmentation
High record count but no Valid routes Route-map not applied to neighbor Verify neighbor X route-map RPKI-POLICY in
Prefix shows NotFound when you expect Valid ROA not published or expired Check ROA status in RPKI repositories directly
Validator shows 0 records Not syncing with RIR trust anchors Verify validator config syncs with all 5 RIRs

💡 Set up syslog/SNMP traps for RPKI session state changes. A validator failure should be a P1 alert, not something you discover during the next change window.

Beyond ROV: What's Coming

RPKI ROV validates the origin AS only. It can't 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 encodes customer-provider AS relationships, enabling AS path validation. NIST is building test tools (the BRIO framework), and early adoption is expected in 2026-2027.

RFC 9774 deprecated AS_SET, which simplifies ROV — every route now has a single unambiguous origin AS. If you're still generating AS_SET in aggregate routes, update your aggregate-address configs now. Compliant peers will increasingly reject those routes.

Key Takeaways

  1. RPKI ROV is production-ready — 500K+ ROAs, mature validators, no excuses
  2. Start soft — tag Invalid with low local-pref for 2-4 weeks, then hard deny
  3. Two validators minimum — single validator failure = silent ROV death
  4. ROV is layer one — complement with ASPA and BGP session auth (TCP-AO) as they mature
  5. Fix your aggregation — RFC 9774 killed AS_SET; update your configs
  6. Alert on validator failures — treat RTR session drops as P1 incidents

BGP security is no longer optional for any network participating in the global routing system. RPKI ROV gives you a concrete, deployable mechanism to verify route origins today. Configure it, monitor it, enforce it.

Originally published at FirstPassLab. For more protocol deep dives and lab guides, visit firstpasslab.com.

AI Disclosure: This article was adapted with AI assistance. All technical content, configurations, and recommendations are based on documented Cisco IOS-XE/XR behavior, RFC specifications, and industry best practices. Human-reviewed for accuracy.

Top comments (0)