RPKI route origin validation on OcNOS works in three steps: point BGP at one or more RTR validators with the bgp rpki server command, let the validated ROA table populate, then apply a route-map that matches rpki invalid to drop invalid routes inbound on your peering sessions.
Route origin validation is the cheapest control an operator can add at the internet edge, and it moved from optional to expected. This guide shows how it works on OcNOS and how to configure it on a peering router, with commands verified on OcNOS-SP.
What is RPKI route origin validation?
Resource Public Key Infrastructure (RPKI) binds an IP prefix to the network authorized to announce it in a cryptographically signed record called a Route Origin Authorization (ROA). Route Origin Validation (ROV) is the action a router takes when it compares an incoming BGP route against those ROAs and marks it valid, invalid, or not-found. A route is valid when the origin AS and prefix length match a ROA, invalid when a ROA exists but the origin or length is wrong, and not-found when no ROA covers the prefix. ROV stops the most common routing accident and attack in one step: a network originating a prefix it does not hold, which sends other operators’ traffic the wrong way.
Why RPKI matters now
Route origin validation is no longer a nice-to-have. Large transit providers reject RPKI-invalid routes by default, national regulators reference routing security in their guidance, and the MANRS actions treat origin validation and prefix filtering as table stakes for a serious network. For an operator carrying the full internet BGP table at the peering edge, ROV removes a whole class of mis-origination for very little effort. You also gain protection immediately, because you benefit from every ROA that already exists without waiting for the rest of the internet.
How OcNOS validates routes
OcNOS does not carry the RPKI database on the router. It connects to an external RPKI validator, also called an RPKI-to-Router (RTR) cache, that fetches and cryptographically verifies ROAs from the trust anchors and hands the router a clean set of validated prefix-to-origin records. OcNOS holds that validated table in memory, refreshes it on a timer, and marks routes as it receives them. You can point the router at more than one validator for redundancy. Any validator that speaks the RTR protocol works, including Routinator, rpki-client with StayRTR, and NLnet Labs Krill deployments.
How to configure RPKI route origin validation on OcNOS
The configuration has three parts: connect the router to a validator, let the validated table populate, and apply a policy that acts on the result. OcNOS is transactional, so each stage is applied with commit.
1. Connect the router to RPKI validators
Under the BGP instance, point the router at one or two RTR caches. The address alone is a complete command, and port is optional and defaults to 3323 for TCP.
configure terminal
router bgp 64500
bgp rpki server 10.0.0.10 port 3323
bgp rpki server 10.0.0.11 port 3323
commit2. Match the validation state and drop invalid routes
Use a route-map to act on the RPKI state. This one denies invalid routes and permits everything else, so valid and not-found routes are accepted while invalid routes are dropped.
route-map RPKI-EDGE-IN deny 10
match rpki invalid
!
route-map RPKI-EDGE-IN permit 20
commit3. Apply the policy inbound on the peering session
Attach the route-map to the eBGP peer in the address family it should protect. Repeat under address-family ipv6 unicast for IPv6.
router bgp 64500
address-family ipv4 unicast
neighbor 203.0.113.1 route-map RPKI-EDGE-IN in
exit
commitHow do I verify RPKI validation is working?
Confirm the validator session is up, that the validated table has entries, and that routes are being marked. OcNOS provides three commands for this.
OcNOS# show bgp rpki server
OcNOS# show bgp rpki table
OcNOS# show bgp rpkishow bgp rpki server reports each validator and whether its session is established, show bgp rpki table lists the validated prefix-to-origin records the router downloaded, and show bgp rpki summarizes the RPKI state. Once the session is established and the table has entries, routes that fail validation carry the invalid state and are dropped by the route-map at the edge.
RPKI at the peering edge
Origin validation is one layer of a secure peering edge, not the whole of it. On a complete open peering router, RPKI invalid-route rejection sits alongside prefix filtering aligned with MANRS, BGP FlowSpec for DDoS mitigation, and remote-triggered black-holing, so the router enforces routing hygiene and attack response from the same place it carries the full table. See how the roles fit together on the open IP core and peering router.