Thanks, George!

For nusenu and other folks here running RIPE's rpki-validator-3:
earlier this summer folks at RIPE told me that their current code does
not forget about de-referenced repositories.  The upshot is that once
a validator learns of a repository, it will forever continue trying to
reach it, even after upstream repositories no longer point to it.

RIPE's developers know this is not a desirable behavior, and fixing it
is on their to-do list.

In the meantime, if one wants to stop these extra failed retrievals
and eliminate the noise in the logs, one may empty the cache and start
it again.  Here are the steps for rpki-validator-3 installations based
on RIPE's Centos 7 packages:


##############################

sudo systemctl stop rpki-validator-3

ls -l /var/lib/rpki-validator-3/db/

sudo -u rpki sh -c '> /var/lib/rpki-validator-3/db/rpki-validator.h2.mv.db'

sudo -u rpki sh -c '> /var/lib/rpki-validator-3/db/rpki-validator.h2.trace.db '

ls -l /var/lib/rpki-validator-3/db/  # just to confirm empty caches

sudo systemctl start rpki-validator-3


In case you use any extra TALs, they will need to be uploaded
again.  I do load extra TALs, so I continued with:

sleep 30  # wait until rpki-validator-3 is running, then:

upload-tal.sh ~/arin-ripevalidator.tal http://localhost:8080/

upload-tal.sh ~/altca.tal http://localhost:8080/

sudo systemctl restart rpki-validator-3


##############################


I have executed the steps above on my boxes today.  The error messages
regarding rpki.cnnic.cn and rpkica.twnic.net.tw have now ceased.  For
now I still see errors for https://rpkica.twnic.tw/rrdp/notify.xml,
but once the issue George described has been resolved, re-applying the
above steps once more will take care of that one, too.

Thanks.

                                                Jay B.


George Michaelson writes:
 > There is a problem with the RRDP pub-point in TWNIC which we (APNIC)
 > are discussing with them. They did not appreciate at first that a 443
 > bound service would have to be publicly visible and wish to
 > re-architect things to move this to a place outside their firewall.
 > 
 > It doesn't appear logistically simple to disable the certificated
 > declaration right now, I think we might have an operations discussion
 > about timeouts and risks here.
 > 
 > Basically, "they know there is a publicly visible problem" and "they
 > are working on it"
 > 
 > -George
 > On Thu, Oct 11, 2018 at 11:15 PM nusenu <[email protected]> wrote:
 > >
 > >
 > >
 > > nusenu:
 > > > https://rpki.cnnic.cn/rrdp/notify.xml: 
 > > > java.util.concurrent.TimeoutException
 > > > https://rpkica.twnic.tw/rrdp/notify.xml: 
 > > > java.util.concurrent.TimeoutException
 > >
 > >
 > > are they generally unavailable or are they just answering to a limited set 
 > > of source IPs?
 > > (depending on geolocation of the source IP)
 > >

Reply via email to