Route leaks and hijacks remain one of the internet's biggest reliability threats. This guide walks through deploying RPKI ROV and IRR filtering on Junos and IOS-XR.
In March 2025, a Tier-2 ISP in South-East Asia accidentally leaked 13,000 prefixes from a transit customer, causing a 40-minute routing blackhole for traffic destined to three European IXPs. The root cause? A missing max-prefix limit and no RPKI validation.
Understanding Route Origin Validation (ROV)
RPKI allows prefix holders to cryptographically sign Route Origin Authorisations (ROAs) that bind a prefix to an authorised origin ASN. Validators fetch these ROAs and feed the results to your routers via RTR protocol.
Deployment Checklist
- Deploy a local RPKI validator (Routinator, Fort, or rpki-client)
- Configure RTR sessions from your route servers and edge routers
- Set policy: Invalid → Reject, Valid → Prefer, Unknown → Accept (initially)
- Create ROAs for all your announced prefixes in your RIR's RPKI portal
- Register route objects in RIPE IRR / RADB for legacy filtering compatibility
Junos Configuration Example
routing-options {
validation {
group rpki-validators {
session 10.0.0.100 {
port 8323;
}
}
}
}
policy-options {
policy-statement reject-rpki-invalid {
term invalid {
from validation-database invalid;
then reject;
}
}
}Deploying RPKI ROV is no longer optional — it's a baseline hygiene requirement for any network that peers at an IXP or provides transit.