How to Deploy RPKI

Deploy RPKI so new prefixes, upstream changes and customer launches keep moving. A successful rollout connects accurate route authorizations, reliable validators and a BGP policy you have tested against real customer routes.

Start with the routes your customers depend on

Plan two workstreams: publish ROAs for your address space, and apply Route Origin Validation to routes you receive. A published ROA helps other networks validate your announcements; it does not turn on filtering in your own routers.

Capture current external reachability, announced prefixes, origin ASNs and route counts. Include customer suballocations, anycast origins and DDoS mitigation arrangements. This gives you a useful before-and-after comparison. The RPKI introduction explains the terms.

1. Confirm the router and publication path

Check your router model and installed software for RTR support, validation-state policy and route re-evaluation after a data update. Test with your actual routing-table size. Record the working configuration and the exact way to restore it.

Identify who can publish ROAs for each prefix. With leased space, coordinate with the provider managing the authorization. Choose hosted publication or a delegated certificate authority according to who will operate the signing and publication service.

2. Publish the intended routes before changing BGP

1. List each planned prefix, origin ASN and prefix length.
2. Cover customer subprefixes and legitimate additional origins before adding a covering aggregate ROA.
3. Use precise authorizations for the routes you need; avoid an unnecessarily broad maxLength.
4. Check the new data in independent validators. Allow it to propagate before changing your announcements.

For an ASN migration, authorize the new origin before moving traffic. Keep authorization for the old origin while it is still legitimately announcing, then remove it after the transition. RFC9319 explains the trade-offs behind precise ROAs.

3. Give routers a reliable validation service

Run maintained Relying Party software, such as NLnet Labs Routinator, in locations your routers can reach reliably. Use more than one independent cache so maintenance or a host failure does not leave a single point of failure.

Monitor successful validation runs, data age, repository errors, VRP counts and certificate expiry. Keep the cache-to-router path on a controlled network with suitable transport protection. Test access during startup as well as normal operation.

Configure the actual RTR listener on both sides. Routinator's documented container setup uses port 3323 for RTR and 8323 for its HTTP interface; your deployment can use different values. A working web interface does not prove that the router's RTR session is healthy.

4. Observe validation states before filtering

Connect the routers to the caches, confirm usable data arrives, and inspect the states without changing route acceptance at first. Resolve legitimate customer routes that appear Invalid before applying the intended rejection policy.

Checks before applying origin-validation policy

State	What to inspect	Routing treatment
Valid	Origin ASN and length match at least one covering VRP.	Continue ordinary import and path checks.
Invalid	A covering VRP exists, but none matches. Check customer and migration records.	Reject through the explicit ROV policy after resolving intended-route mismatches.
NotFound	No VRP covers the route.	Continue ordinary policy; do not treat this state as Invalid.

Verify how your platform refreshes route decisions when VRPs change. Use its documented procedure, rather than resetting every BGP session to make a change take effect.

5. Test the customer journey and failure behaviour

Use documentation prefixes in a lab for Valid, Invalid and NotFound examples; never announce test prefixes to the public Internet. On a limited production rollout, compare accepted routes, customer reachability, router load and convergence with the baseline.

• One cache unavailable: confirm the remaining cache supplies usable data.
• All RTR sessions unavailable: observe retained data, expiry timers and the router's configured response.
• ROA updated: confirm the router refreshes validation and route policy as intended.
• Unexpected customer loss: restore the recorded policy, investigate the affected route, then repeat the limited rollout.

A disconnect does not instantly make all routes NotFound. Cached data can remain usable until its expiry; subsequent states depend on other available VRPs. RFC8210 describes RTR data lifetime. Test your exact software and timers.

6. Make the next launch easier

Expand the rollout after the limited change passes. Put ROA checks into prefix onboarding, ASN changes and customer migrations. A small repeatable workflow saves the NOC from rediscovering the same mismatch during every launch.

Track time to activate a prefix, customer reachability and time to resolve Invalid routes. ROA coverage and ROV adoption are different measurements; a global adoption percentage cannot prove that your own customer paths work.

Use the RPKI troubleshooting guide for obstacles and the operations guide for ongoing checks.

Prepare the capacity behind your next launch

Accurate routing and dependable address supply belong in the same launch plan. With Unlimited IPv4 and direct LARUS Continuity, your team can plan new services around customer growth. The continuity foundation addresses the provider relationship behind the registry layer.

Deployment questions

Must I operate a certificate authority?

No. Hosted ROA publication can handle signing and publication, while your own validators handle received data. With delegated publication, your team also operates the certificate and publication service.

Do two validators solve every dependency?

They improve local availability. Both still validate upstream certificate data. Track local service health and upstream authorization changes separately, so the team can act on the right cause.

Will ROV stop a route leak?

A leak can keep the authorized origin and remain Valid. Continue prefix filtering, export-policy checks and path monitoring alongside ROV.