TTR Networks

Intermediate · RPKI and Route Origin Validation · section 5 of 8

Validators and RTR

✓ Lab-tested 17 October 2026 on FRR 10.2.1, StayRTR 0.6.4

A validator (or "relying party") does the heavy lifting:

  1. starts from the TALs,
  2. walks every repository (RRDP or rsync),
  3. verifies signatures, manifests, CRLs and validity dates,
  4. outputs the VRP set, typically every few minutes.

Widely used open-source validators:

ValidatorMaintainerNotes
RoutinatorNLnet LabsSingle binary with a built-in RTR server and HTTP API
rpki-clientOpenBSD projectValidator only; pair it with StayRTR to serve routers
FORTNIC MéxicoValidator with built-in RTR server

Routers get VRPs via the RPKI-to-Router protocol (RTR, RFC 6810 and RFC 8210). It's a simple TCP protocol with incremental updates and serial numbers; IANA assigned port 323, but deployments usually use an unprivileged high port (StayRTR defaults to 8282; Routinator is conventionally run on 3323). Run at least two validators, preferably different implementations, and point every router at both.

The lab in this lesson uses StayRTR serving a hand-written VRP file, so you can see exactly what the router does with a known set of VRPs. In production, StayRTR reads rpki-client's JSON output instead.

When the validator disappears

RPKI fails open. If a router loses every RTR session it keeps the VRPs it has until they expire (FRR's default is 7200 seconds), and after that every route becomes NotFound and is accepted. Monitor your validators and RTR sessions. An outage won't break routing, but it silently turns protection off.

Two things the lab showed

  • After a validator is replaced or restarted, a router may not resync immediately. In the lab, FRR reconnected to a freshly started StayRTR with the old session's state, was disconnected, and would only have tried again after its retry interval (600 seconds by default). rpki reset forced an immediate resync.
  • New VRPs don't automatically resurrect routes that were already filtered. The VRP update arrived in about 20 seconds, but a route R1 had dropped as Invalid stayed dropped until inbound policy was re-run with clear bgp … soft in.
Lab VRPs served by StayRTR
{
  "roas": [
    { "prefix": "203.0.113.0/24", "maxLength": 24, "asn": "AS64501", "ta": "lab" },
    { "prefix": "198.51.100.0/24", "maxLength": 24, "asn": "AS64502", "ta": "lab" }
  ]
}
  • Line 3: AS64501 may originate 203.0.113.0/24 and nothing more specific.
  • Line 4: 198.51.100.0/24 belongs to AS64502. In the lab, R2 (AS64501) announces it anyway: a simulated origin hijack.
The router keeps its VRPs when the validator goes down (real output)
R1# show rpki cache-connection
Connected to group 1
rpki tcp cache 10.0.12.10 3323 pref 1
R1# show rpki prefix-table
RPKI/RTR prefix table
Prefix                                   Prefix Length  Origin-AS
198.51.100.0                                24 -  24   64502
203.0.113.0                                 24 -  24   64501
Number of IPv4 Prefixes: 2
Number of IPv6 Prefixes: 0
  • Line 3: No (connected): the RTR session to StayRTR is gone.
  • Lines 4–10: The VRPs are still there and routes are still validated, until the expire interval (7200s by default). After that, everything becomes NotFound.

Check your understanding

Both of your validators have been down for a day. What is the effect on your routers' ROV?

  • All routes become Invalid and are dropped
  • VRPs have expired, so every route is NotFound and accepted: protection is silently off
  • Routers fetch ROAs from the RIRs directly
  • BGP sessions go down