[RPKI] [EXTERNAL] routinator 0.10.2 vs. 0.11.2

[Alex Band]

Hi Håvard,

From our dual-stack test installation running in a data center in Amsterdam (https://routinator.do.nlnetlabs.nl/status), Routinator is currently attempting to use rsync for these Publication Points:

rsync-durations:
   rsync://rpki.rand.apnic.net/repo/: status=0, duration=3.254s
   rsync://rpki.sailx.co/repo/: status=35, duration=10.004s
   rsync://child.rov.koenvanhove.nl/repo/: status=0, duration=3.256s
   rsync://rpkica.mckay.com/rpki/: status=0, duration=0.236s
   rsync://invalid.rov.koenvanhove.nl/repo/: status=35, duration=10.007s
   rsync://nostromo.heficed.net/repo/: status=35, duration=10.004s
   rsync://rpki.caramelfox.net/repo/: status=0, duration=1.373s

From the exit code you can see that three of them are successful (0) and the other three exit with an Error in Socket I/O (35). These attempts to use rsync are only done after Routinator determines that using RRDP has failed. In the RRDP overview you can see these six publication points attempting to connect over HTTPS but exit with either a -1 or a 404 status.

Routinator’s strategy for data fetching and how you can influence it is explained here:
https://routinator.docs.nlnetlabs.nl/en/stable/data-processing.html

Two remarks with regards to logging:

1. As Martin mentioned, there can be quite a number of log entries for Unsafe VRPs. We’ll fix that in an upcoming version, so users are no longer alarmed by them. See PR #761 and #757 here: https://github.com/NLnetLabs/routinator/pulls

2. If an error is reported about an RPKI object, it will always display the canonical identifier of the object which is the complete rsync URI regardless of the transport used, e.g. “rsync://rpki.arin.net/repository/arin-rpki-ta/5e4a23ea-e80a-403e-b08c-2171da2157d3/2a246947-2d62-4a6c-ba05-87187f0099b2/63e0b1ac-9cd7-4998-bda5-556194e8519d/63e0b1ac-9cd7-4998-bda5-556194e8519d.mft”.

I realise all of this may be a bit confusing. It is essentially the result of the way the RPKI standards have evolved, making it sometimes tricky for operators to implement something that is robust on the one hand and easy to understand and troubleshoot on the other.

Kind regards,

Alex

> On 7 Sep 2022, at 13:13, Havard Eidnes <he at uninett.no> wrote:
> 
> OK,
> 
> I had to bump rsync-timeout to 1800 (at least 600 wasn't enough
> for me), and with that I got a proper session finish:
> 
> 11:06:55.640898 IP 199.71.0.150.873 > 158.38.xx.yy.62909: Flags [P.], seq 48424437:48424459, ack 2026575, win 3193, options [nop,nop,TS val 353214336 ecr 2078], length 22
> 11:06:55.640979 IP 158.38.xx.yy.62909 > 199.71.0.150.873: Flags [P.], seq 2026575:2026580, ack 48424459, win 20581, options [nop,nop,TS val 2078 ecr 353214336], length 5
> 11:06:55.667327 IP 158.38.xx.yy.62909 > 199.71.0.150.873: Flags [F.], seq 2026580, ack 48424459, win 20581, options [nop,nop,TS val 2078 ecr 353214336], length 0
> 11:06:55.829341 IP 199.71.0.150.873 > 158.38.xx.yy.62909: Flags [F.], seq 48424459, ack 2026580, win 3193, options [nop,nop,TS val 353214525 ecr 2078], length 0
> 11:06:55.829368 IP 158.38.xx.yy.62909 > 199.71.0.150.873: Flags [.], ack 48424460, win 20581, options [nop,nop,TS val 2079 ecr 353214525], length 0
> 11:06:55.854681 IP 199.71.0.150.873 > 158.38.xx.yy.62909: Flags [.], ack 2026581, win 3193, options [nop,nop,TS val 353214550 ecr 2078], length 0
> 
> and after a short while I got "Validation completed." and
> 
> Sep 07 11:10:39 rov-osl routinator[9048]: arin: 
> Sep 07 11:10:39 rov-osl routinator[9048]:            ROAs:   54599 verified;
> Sep 07 11:10:39 rov-osl routinator[9048]:            VRPs:   78972 verified,       0 unsafe,   74734 final;
> 
> and
> 
> Sep 07 11:10:39 rov-osl routinator[9048]:  total: 
> Sep 07 11:10:39 rov-osl routinator[9048]:            ROAs:  127077 verified;
> Sep 07 11:10:39 rov-osl routinator[9048]:            VRPs:  386008 verified,       7 unsafe,  378675 final;
> 
> Regards,
> 
> - Håvard