On Thu, Jul 30, 2026 at 10:52:28PM +0200, Lukas Tribus wrote:
There are many reasons rpki-client could stop validating. Connectivity issues, upstream FW changes, read-only FS, no enough memory, not enough disk space, bugs, permission problems, "it's a container so nobody understands what is going on, but the lights are all green".
This seems weird to pick on rpki-client this. What software is resistent against hardware failures or execution in a unfitting environment? For exactly these reasons, a sane program will error out with a non-zero exit code when problems are detected. Whether the program is one-shot or long running is irrelevant in this context: the operator must monitor the process execution. Rpki-client even warns the operator on STDERR when it suspects there won't be enough inodes or disk space.
All in one software stacks will crash and tear down RTR sessions with them in most of those situations.
This doesn't match my experience: I've discovered catastrophic silent bugs in basically every RPKI validator projects. And not even all of those bugs have been solved when I last took stock! I do agree that programs which as a general rule 'crash hard and fast' are easier to manage than programs that just 'limp on'. In my experience it is easier to construct reliable setups when you can monitor each individual component in the pipeline (fwiw, both rpki-client and StayRTR support OpenMetrics/Grafana, which helps me with faster fault identification). This is also why I love programs that properly set exit codes. To pivot to a more constructive line: in the realm of dead man's switches, I've grown fond of https://healthchecks.io/ (up to 20 monitors is free) linked with Pushover ($5 one-time purchase). Very cheap way to keep an eye on whether backups or rpki-client invocations are humming along nicely. Alternatively, OpenBSD's crontab implementation has built-in 'cronic' functionality. In systemd do this: https://wiki.archlinux.org/title/Systemd#Notifying_with_e-mail
With StayRTR v0.6.3+ your RTR count will go to 0, the RTR connection will keep running. Also something you'd wanna know, and it will probably not generate syslogs on your router.
Wouldn't any validator's count go to zero if there are connectivity issues to the rest of the Internet (but not with the BGP routers it is serving)? There is no method of teleporting the ROAs into airgapped validator instances. The RTR protocol even has a "No Data" Error Report PDU: https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-8210bis#name-cache-...
Every RTR server should be monitored against a never changing RTR serial,
Yes.
but the all in one validation + RTR packages are a lot less painful to deal with in these situations.
On the other hand, separation of the 'validation' and 'RTR distribution' function allows for seamless upgrades of the security-sensitive component WITHOUT flapping the BGP router-facing RTR sessions. Different deployment models bring different benefits to the table. Kind regards, Job