On 9 November 2026, RIPE Labs published an article by community contributor Ritesh Mukherjee arguing that once your routers drop Invalid routes through route origin validation, the validator feeding them becomes a source of forwarding policy. If that validator crashes or an RTR session is lost, routers can eventually stop applying RPKI; the article points to the CURE research, where routers eventually flushed their RPKI cache. That makes RPKI validator monitoring an operations task, not a nice-to-have dashboard.

Most of the failure history the article cites is old, and it is a community contribution, not an official RIPE NCC position. What is useful is the framing: the chain runs from CA account to repository to relying party to RTR session to router policy. The article puts the first two links with the registries and the last three with the operator.

We operate BGP and peering ourselves: we sit directly on the major European internet exchanges, we peer with AWS, Azure, GCP, Oracle and Cloudflare, and on Colocation we usually provide the transit ourselves. This checklist is written from the operator side of BGP and peering, where the last three links are yours and nobody upstream applies them for you. We do not describe our own validator setup here; the checks below are what the research and the RFCs support.

The short version: losing ROAs or VRPs can move routes from Valid to NotFound with no alert unless you build one, and one unconfirmed FRR report suggests router session state can mislead.

What RPKI fail open means for BGP origin validation

RFC 6811 defines three states. A route is NotFound when no VRP covers its prefix, Valid when at least one VRP matches, and Invalid when a VRP covers the prefix but none matches. Routers that drop Invalid routes still accept NotFound ones.

That is the RPKI fail open design. When a ROA disappears or a router flushes its VRP table, routes slide from Valid to NotFound, nothing is dropped and nothing alerts by default. The RFC also warns that removing records from the validation database can make an otherwise valid route Invalid. As our own illustration: if the ROA for your legitimate origin is removed while a ROA for a different origin still covers the prefix, your route stops matching and gets dropped.

A validator you do not monitor is a forwarding policy you do not audit.

The timers that set your blind window

RFC 8210 recommends Refresh 3600 seconds, Retry 600 seconds and Expire 7200 seconds. The Expire timer starts when the router receives End Of Data, and caches must set it larger than both Refresh and Retry. With defaults, a router can hold stale data for about two hours after the cache goes silent, then drop it.

Routinator refreshes every 600 seconds by default and its expire value defaults to 7200 seconds. What a router does when a session is lost, flush or retain, and which timer it uses, varies by vendor, and we do not assert it per platform here. Measure it instead.

On a lab router or in a maintenance window, cut the RTR session (block the port) or stop the validator. Record three things for each platform and software version: when the VRP table empties, which timer governed that, and what the session-state command reports at that moment. Keep the results in a table like this one:

Platform / version | VRP table empty after | Governing timer      | Session-state command shows
-------------------|-----------------------|----------------------|----------------------------
router A           |                       | cache Expire / local |
router B           |                       | cache Expire / local |
router C           |                       | cache Expire / local |

That table is your real blind window, and it is the number your alert thresholds should be built from.

RTR session monitoring: the states to alert on

Each of these maps to a different failure and needs its own alert. The forwarding effects below describe what can happen, not what every platform does.

  • Validator process or scrape down. Routers may keep serving the last VRPs until their expire timer runs out. If your platform then flushes the table, Valid routes become NotFound and Invalid routes stop being dropped.
  • Validation age. In Routinator, routinator_last_update_done is the seconds since the last update ended. Alert when it exceeds a few multiples of your refresh interval, and check in your Routinator version whether a failed run resets it; if it does not, this also catches a validator that is alive but cannot reach repositories. Meanwhile routers act on an old picture: new ROAs are not seen, and revoked ones keep counting.
  • Serial that stops moving. routinator_serial is the serial served to RTR clients. A flat serial alone is normal on a quiet day, so alert on a flat serial combined with a stale update age. The article says its tool cannot yet detect a stalled validator, a cache that answers but stops publishing new serials, so build this check yourself.
  • Connection count. routinator_rtr_current_connections counts open RTR connections. Alert when it falls below the number of routers you expect; per-client metrics need the --rtr-client-metrics option. A router without a session gets no updates, and may start its expire clock.
  • Serial mismatch. The serial on the router should match the serial on the validator it is connected to, as a community Grafana dashboard for Routinator notes. A router stuck on an older serial applies older policy, so recent ROA changes do not take effect there.
  • VRP count on the router. A sharp drop against a baseline is the signal for a flushed table or a mass ROA removal. The effect can be Valid routes turning NotFound, or, if only some records vanish, Valid routes turning Invalid.

An independent RTR client

The article extends its author’s open-source tool RAVEN with raven rtr monitor, an independent RTR client over TCP and TLS that tracks payload changes and sync timing and flags anomalies against a median-absolute-deviation baseline. The author works for Nokia and RAVEN is a Nokia-hosted project, so weigh it as you would any vendor-adjacent tool. The article lists what it does not do yet: detect a stalled validator, alert on RPKI-driven route changes, compare caches with each other, or inspect router policy.

Do not trust router session state alone

FRR issue #24001, opened on 27 October 2026, is a useful warning. It is a single-reporter, lab-based issue that maintainers have not confirmed, so treat it as a pattern rather than a verdict. The reporter says new VRPs reached bgpd within seconds, yet the inbound match rpki policy was not re-run, and Invalid routes stayed installed in 12 of 13 two-router runs and all 192 topology runs.

In an RTR blackhole test, the reporter saw the VRP table empty after End of Data plus the configured 600-second Expire, while show rpki cache-connection still reported the cache as connected. The reported workaround was clear bgp ipv4 unicast <peer> soft in. Whatever the root cause turns out to be, column three of your lab table matters: alert on the payload and the resulting route state, not only on the session.

Add a canary

A canary exercises the router policy link that no validator metric can see. You need a route that is known to be Invalid and cannot reach the internet.

  1. Pick a spare prefix you hold and do not announce. Publish a ROA for it authorising an AS number you control but never use to announce it.
  2. Build a lab router, in its own AS, and give it a dedicated eBGP session to a production edge router. Announce the prefix from the lab router. Because the origin differs from the ROA, it is Invalid.
  3. On the production edge, apply the same import policy as on your real peers. Alert if the canary is ever accepted, installed or Valid-looking on that edge.
  4. Keep it from leaking: on that edge, deny the canary prefix outbound on every other session, and tag it with the no-export community.

If the canary starts being accepted, RPKI may have stopped being applied, though a changed or revoked ROA for the canary prefix would produce the same result, so check that first. A second canary with a matching ROA that turns NotFound shows the other half: VRPs lost, nothing dropped.

When RPKI silently stops being applied

Decide the response before the night it happens.

  1. Confirm with the canary and the router VRP count, not with the validator dashboard alone.
  2. Restore the validator and check that the router serial catches up with the validator serial.
  3. Re-run inbound policy if your platform needs it, as the FRR report suggests, and recheck the canary.
  4. Look upstream last. Mass deletion, like the 2,669 ROAs RIPE NCC removed and reinstated in April 2020, shows up as a VRP count drop. A compromised RIR account, like the Orange España case of 3 January 2024, where ROAs were re-signed to another ASN, need not change the count; look for a spike of Invalid routes or origin changes on those prefixes.

Our recommendation, not something the article or the RFCs prescribe: run at least two validators on separate paths and attach each router to both, so one crashed process does not start the Expire clock on every router. Do not respond by switching origin validation off; that is the state you were trying to avoid.

Treat each site as its own failure domain

If a router in one site gets its RTR session from a validator in another, that path is now part of your validation chain. Our four core routers are connected over our own Layer 2 network, a path between the sites, not automatic failover. Whatever your own inter-site path is, add its loss to the session-drop alerts, and run the lab table and the canary once per site rather than once per network.

Sources