Troubleshooting

Resetting the local database

In some cases it is reasonable to remove the validator's local database and restart it. It would make sense if there's a lot of stale objects due to some of the repositories are not available for long time or the validator instabilities (which doesn't happen very often, but still can be the case).

Please note, that restart means that ARIN TAL will not be registered and needs to be added again. It can be done by using upload-tal.sh arin-ripevalidator.tal http://localhost:8080/ or by putting arin-ripevalidator.tal inside of /var/lib/rpki-validator-3/preconfigured-tals/ before starting the validator.

In order to reset the state of the validator one should do the following:

sudo systemctl stop rpki-validator-3
sudo systemctl stop rpki-rtr-server

# Remove the Xodus database
sudo rm -Rf /var/lib/rpki-validator-3/db/*

# If needed, add the ARIN TAL
# cp arin-ripevalidator.tal /var/lib/rpki-validator-3/preconfigured-tals/

sudo systemctl start rpki-validator-3
sudo systemctl start rpki-rtr-server

Normally, it should take a few minutes for the validator to fill in the local database and validate all the objects.

Checking the connection between validator and RTR server

When your validator and rtr server are running and you want to make sure that the rtr server's cache is valid you can perform the following steps.

First of all, check the status of the cache of the rtr server by opening http://<rtr_server_host:server_status_port>/cache

In the (Debian) environment used for this description, the port used for the HTTP status endpoint of the rtr server is 8081:

$ cat /etc/rpki-rtr-server/application.properties | grep -e '^server.port'
server.port=8081

When the rtr server is valid I get the following response:

$ curl http://localhost:8081/cache
{"data":{"ready":true,"sessionId":-4308,"serialNumber":525,"announcementsCount":161619,"deltas":[]}}

If the cache is not valid this response will contain ready: false. This shows that the local cache has not been loaded. Likely causes for this are:

• Trouble connecting to the validator
• The rtr server has been restarted recently and has not updated yet.
• The validator is not (yet) up to date.

As a second check, you can check that the rtr server can reach the validator on the URL that is configured in the rtr server configuration.

The configuration file of the rtr server contains the URL of the validated objects endpoint on the RPKI validator.

$ cat /etc/rpki-rtr-server/application.properties | grep http
rpki.validator.validated.objects.uri=http://localhost:9176/api/objects/validated

And that URL returns all the validated RPKI objects:

$ curl http://localhost:9176/api/objects/validated
<...a lot of ROAs, such as...>
    }, {
      "asn" : "3333",
      "prefix" : "193.0.0.0/21",
      "maxLength" : 21
    }, {
<...>

Allowing connections to the validator and rtr server

Both the validator and the rtr-server have a setting that controls which hosts are allowed to connect to them.

By default this is set to localhost. This is set using server.address in /etc/rpki-validator-3/application.properties for the validator, and with server.address and rtr.server.address in /etc/rpki-rtr-server/application.properties for the rtr server. To allow all IPv4 addresses to connect, adjust the configurationto listen on all IPs (0.0.0.0 instead of 127.0.0.1) and restart the services.

To validate that it is listening on all IP's you can check it for the validator using:

$  grep address /etc/rpki-validator-3/application.properties
# specifying a different IP address
server.address=0.0.0.0

And for the rtr server by running:

$  grep address /etc/rpki-rtr-server/application.properties
# specifying a different IP address
server.address=0.0.0.0
rtr.server.address=0.0.0.0