This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/routing-wg@ripe.net/
[routing-wg] RPKI Validator 3: disable fetching from certain repos?
- Previous message (by thread): [routing-wg] RPKI Validator 3: disable fetching from certain repos?
- Next message (by thread): [routing-wg] 2018-06 New Policy Proposal (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Jay Borkenhagen
jayb at braeburn.org
Fri Oct 12 16:03:18 CEST 2018
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 <nusenu-lists at riseup.net> 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) > >
- Previous message (by thread): [routing-wg] RPKI Validator 3: disable fetching from certain repos?
- Next message (by thread): [routing-wg] 2018-06 New Policy Proposal (RIPE NCC IRR Database Non-Authoritative Route Object Clean-up)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]