Deployment guide

Routinator

Overview

Routinator is open-source RPKI Relying Party software from NLnet Labs. It fetches RPKI data from the five Regional Internet Registry (RIR) trust anchors (ARIN, RIPE NCC, APNIC, LACNIC and AFRINIC) and cryptographically validates the Route Origin Authorisations (ROAs). It then serves the resulting Validated ROA Payloads (VRPs) to your routers over the RTR protocol.

Resource Public Key Infrastructure (RPKI) lets the holder of an IP prefix publish a signed ROA that declares which Autonomous System may originate that prefix in BGP. With VRPs, your routers can mark BGP routes as valid, invalid or not found, and drop or de-prefer the invalid ones.

This SecureAnyCloud image installs Routinator 0.15.2 from the official NLnet Labs package repository and runs it under systemd as the routinator service. Routinator's HTTP interface is bound to loopback 127.0.0.1:8323, so it is never exposed directly. An nginx reverse proxy on port 80 adds a per-VM HTTP Basic Auth gate in front of it, and the RTR server listens on port 3323 for your routers.

Since Routinator 0.12.0, the RIR trust anchors are built into the binary. The appliance therefore validates fresh from the RIRs on first boot, with no manual initialisation step. Routinator is a single self-contained Rust binary with no external database. It also exposes a read-only status web interface, Prometheus metrics, and a JSON and CSV data API.

What you get:

  • Routinator 0.15.2 installed from the NLnet Labs apt repository and running as the routinator systemd service
  • The read-only status web interface on :80, fronted by nginx, with Routinator's own HTTP listener bound to loopback 127.0.0.1:8323
  • Per-VM HTTP Basic Auth (user admin) protecting the web interface, with a unique password generated on first boot
  • The RTR server on 0.0.0.0:3323 serving Validated ROA Payloads to your routers
  • The five RIR trust anchors built into Routinator, validated fresh from the RIRs on first boot, so no stale cache ships in the image
  • A minimal /etc/routinator/routinator.conf that you can extend with local exceptions (SLURM), extra TALs or a refresh interval
  • routinator.service and nginx.service as systemd units, enabled and active
  • An unauthenticated /healthz endpoint for Azure Load Balancer health probes
  • 24/7 SecureAnyCloud support

Prerequisites

You need an active Azure subscription, an SSH key pair, and a VNet with a subnet in the target region.

Standard_B2s (2 vCPU / 4 GiB RAM) is a comfortable starting size. Routinator is light on CPU and RAM, but it keeps an on-disk RPKI cache of roughly one to two GiB.

Configure the network security group (NSG) as follows:

  • Inbound: allow 22/tcp from your management network, 80/tcp for the web interface, and 3323/tcp from your router networks for RTR.
  • Outbound: allow 443/tcp (RRDP over HTTPS, the primary transport) and 873/tcp (rsync, a fallback for the few publication points not served over RRDP). Routinator needs both to reach the RIR and CA publication points.

Routinator serves plain HTTP on port 80. For production, terminate TLS in front of it with your own domain and restrict access to trusted IP ranges (see Maintenance).

Step 1 - Deploy from the Azure Marketplace

Sign in to the Azure Portal, choose Create a resource, search the Marketplace for Routinator by SecureAnyCloud, and select Create.

On the Basics tab, pick your subscription, resource group, region and size. Under Administrator account, choose SSH public key and paste your key. Under Inbound port rules, allow SSH (22) and HTTP (80).

Select Review + create, then Create. After deployment, add an inbound NSG rule for 3323/tcp from your router networks.

Step 2 - Deploy from the Azure CLI

# Accept the Marketplace terms once per subscription (required before the first CLI deploy)
az vm image terms accept --urn sac1647283583153:routinator:default:latest
az vm create \
  --resource-group <your-rg> \
  --name routinator \
  --image sac1647283583153:routinator:default:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --ssh-key-values ~/.ssh/id_ed25519.pub \
  --vnet-name <your-vnet> --subnet <your-subnet> \
  --public-ip-sku Standard
az vm open-port --resource-group <your-rg> --name routinator --port 80 --priority 1010
az vm open-port --resource-group <your-rg> --name routinator --port 3323 --priority 1020

Step 3 - Connect to your VM

Connect over SSH as azureuser:

ssh azureuser@<vm-public-ip>

Step 4 - Confirm the services and listeners

Routinator and nginx are enabled and active out of the box. Routinator's HTTP interface is bound to loopback 127.0.0.1:8323, and nginx is the only public gate. The RTR server listens on 0.0.0.0:3323 for your routers.

systemctl is-active routinator.service nginx.service routinator --version ss -tlnH | awk '{print $4}' | grep -E ':(8323|3323|80)$' | sort -u

Step 5 - Confirm the first RPKI validation completed

On first boot, Routinator fetches and validates the RPKI data from all five RIRs. This takes a few minutes.

When it finishes, the routinator_vrps_final metric reports the number of Validated ROA Payloads, and the status API records the last update. A non-empty VRP count means validation completed.

curl -s http://127.0.0.1:8323/metrics | grep '^routinator_vrps_final'
curl -s http://127.0.0.1:8323/api/v1/status | jq '{lastUpdateStart, lastUpdateDone, lastUpdateDuration, serial}'

Step 6 - Retrieve the per-VM web UI password

nginx protects the web interface with HTTP Basic Auth (user admin). The password is unique to your VM, generated on first boot and stored on the VM. Read it with sudo:

sudo cat /root/routinator-credentials.txt

The file records ROUTINATOR_URL, ROUTINATOR_USERNAME and ROUTINATOR_PASSWORD. Open http://<vm-public-ip>/ in your browser and sign in as admin with that password.

Step 7 - Explore the status web interface

The interface has four pages:

  • Prefix Check validates a prefix and origin AS against the current RPKI data and shows the data freshness for each RIR trust anchor.
  • Metrics breaks the validation down per RIR: valid and invalid ROAs, total and final VRPs, publication points, manifests, CRLs and certificates.
  • Repositories lists every RPKI publication point that Routinator fetched from, with the VRP counts contributed by each.
  • Connections shows the RRDP and rsync fetches that Routinator made, with per-source duration, HTTP status and serial.

Step 8 - Verify the Basic Auth gate

nginx is the appliance's authentication gate. The unauthenticated /healthz endpoint returns 200 for load balancer probes. The web interface returns 401 until you supply the per-VM password.

PASS=$(sudo grep '^ROUTINATOR_PASSWORD=' /root/routinator-credentials.txt | cut -d= -f2-)
curl -s -o /dev/null -w 'healthz (no auth) : %{http_code}\n' http://127.0.0.1/healthz
curl -s -o /dev/null -w 'ui (no auth) : %{http_code}\n' http://127.0.0.1/ui/
curl -s -o /dev/null -w 'ui (per-VM pass) : %{http_code}\n' -u "admin:$PASS" http://127.0.0.1/ui/
curl -s -u "admin:$PASS" http://127.0.0.1/api/v1/status | jq '{version, serial, lastUpdateDone}'

Step 9 - Connect your routers to the RTR endpoint

Routinator serves the Validated ROA Payloads to routers over the RTR protocol (RFC 6810 and 8210) on port 3323. Point your routers at <vm-public-ip>:3323, and restrict that port to your router networks with the NSG.

You can preview the exact data your routers will receive over the CSV endpoint on the VM:

ss -tlnH | awk '{print $4}' | grep ':3323$' grep -E 'http-listen|rtr-listen|repository-dir' /etc/routinator/routinator.conf curl -s http://127.0.0.1:8323/csv | awk 'NR<=6'

On a Juniper or Cisco router, configure Routinator as an RPKI validator (an rpki / validation-session pointing at <vm-public-ip> port 3323). Then apply an origin-validation policy to your BGP sessions. See the Routinator documentation for per-vendor router configuration.

RPKI trust anchors and the ARIN Relying Party Agreement

By deploying and operating Routinator, you act as an RPKI relying party. You consume the trust anchors published by the five RIRs and validate the RPKI objects beneath them.

Since Routinator 0.12.0, the trust anchor locators for all five RIRs, including ARIN, are built into the binary and loaded automatically. No separate initialisation or ARIN Relying Party Agreement acceptance command is required to start validating.

ARIN's trust anchor and RPKI data remain subject to ARIN's Relying Party Agreement, and the other RIRs publish their own terms. As the operator, you are the relying party under those terms.

If your policy requires excluding a particular RIR's trust anchor, use the --no-rir-tals and --tal options. See the Routinator initialisation documentation.

Maintenance

  • Re-validation runs automatically every 10 minutes. Routinator keeps its RPKI cache under /var/lib/routinator/rpki-cache and updates it incrementally.
  • Local exceptions (SLURM) let you add or filter VRPs for your own network. Add a slurm file reference to /etc/routinator/routinator.conf and reload with sudo systemctl reload routinator.
  • Change the web UI password by rewriting the nginx Basic Auth file: printf '%s' 'new-password' | sudo htpasswd -iB /etc/nginx/.routinator.htpasswd admin. Then run sudo systemctl reload nginx.
  • Add TLS by placing your certificate in front of nginx and serving the web interface over 443 with your own domain. Keep the RTR port restricted to your router networks.
  • Outbound access to 443/tcp (RRDP) and 873/tcp (rsync) must stay open. Otherwise validation stalls and VRP counts fall behind.
  • Updates: apply OS security updates with sudo apt-get update && sudo apt-get upgrade. This also picks up new Routinator releases from the NLnet Labs repository.

Support

SecureAnyCloud maintains this image and provides 24/7 support. For questions about this Routinator image or help with your deployment, contact sales@secureanycloud.com.

Deploy on Azure

Launch Routinator on Ubuntu 24.04 LTS on Azure with 24/7 support from SecureAnyCloud.

View this image

Need Help?

Our support team is available 24/7.

sales@secureanycloud.com

Deploy on Azure