RPKI and RIPE Atlas: routing security

Gavin Phratsachack · operator, AS218248 · Minnesota, USA - hosted in Düsseldorf, Germany

AS218248 does not just announce its own prefix — it validates what it accepts. BIRD checks every route learned from the LocIX and ixFabric route servers and from bilateral peers against the global RPKI data, and rejects anything whose origin is invalid. A RIPE Atlas probe on the network watches the filtering in action. This is the routing-security half of the network: the announcement side is the ROA, and this page is the validation side.

Why this exists

RPKI and routing security help provide visibility to the internet and ensure routing validity and security. Validating my own prefix protects AS218248, and rejecting invalid announcements from peers means this network does not forward or amplify bad routes — a small contribution to a routing ecosystem where invalid announcements get rejected instead of propagated. The Atlas probe adds the other half: it gives RIPE measurement visibility into my network, so the filtering can actually be observed from outside.

Route origin validation (ROV)

The covering ROA was tightened on Nov 9, 2026 by Servperso from max-length /128 to exactly /44, verified valid in RIPEstat. The tradeoff is locked in: a future /48 carve-out will not validate until Servperso loosens the ROA again. BIRD does not auto-revalidate when ROA data changes — a reload is birdc configure, and per-protocol revalidation is birdc reload in <protocol>.

The validator journey

Getting ROV running took three tries in one evening, Nov 9, 2026:

• Routinator, phase 1 — the first validator, which worked but proved too heavy in steady state on the 2 GB box, spiking CPU 30–65% every 15 minutes with RAM pinned near 1.85 of 2 GiB.
• rpki-client + stayrtr — the lightweight replacement. The first rpki-client run was killed after 50 minutes of swap-thrashing; a 2 GB swapfile was added and the second run finished. But then the rpki-client cache exhausted the filesystem’s inodes — 824,394 of 930,240 — and the box was in trouble.
• Back to Routinator, stripped down — the cache was deleted, the rpki-client timer left stopped, and Routinator came back with a minimal config: refresh 21600 (6h), no dashboard, validation-threads 2, RTR on 127.0.0.1:3323, no HTTP listener, log-level warn. Verified Nov 9 at ~22:38 CST: rpki1 Established, all 7 BGP sessions Established. ROV has been live since then.

Two things worth knowing: Routinator is not a looking glass — its UI shows validated ROAs, not the BGP table. And never use routinator validate as a status check; it does a full local validation run that spikes CPU and hangs on this box. Use the HTTP API instead (or, in the stripped config, check BIRD’s rpki1 session directly).

The DNS name rpki.gnpk.zip is live (A/AAAA) but points at nothing — there is no HTTP listener in the stripped-down config. Whether to keep or remove it is undecided.

RIPE Atlas probe

An Atlas probe was on this network before — it was removed on Nov 5, 2026 to keep the VPS clean. It came back on Nov 9 with a fresh key, because the old key was never released by RIPE (“A software probe with this key already exists”) and the fix was to delete the key files and regenerate. The reason it matters: the bgp.tools “Validating RPKI ROV” tag needs a probe on the network to observe the filtering, so the probe and the validator went in together.

Atlas DNS monitoring was decided against: it would cost 57,600 credits/day against 21,600/day income, which would exhaust the 236,003 balance in about 4 days.

What bgp.tools sees

Tags for AS218248: Personal ASN, IPv6 only. The “Validating RPKI ROV” tag is pending — it needs ROV plus the probe plus time for the measurement to observe the filtering, and both prerequisites have been in place since Nov 9, 2026.

Find AS218248 around the internet: PeeringDB · bgp.tools · RIPEstat · Hurricane Electric · Network · Peering policy