Not receiving ROAs over RTR using rtrdump

[spgreen]

Hi all!

• Using routinator Docker container image nlnetlabs/routinator:v0.13.2 as a server
  • My understanding is that, routinator is run in server mode with RTR and HTTP services enabled by default
• HTTP connection over port 8323 (default for the container) shows valid ROAs, VRPs, etc once loaded as shown in the screenshot below
  
  

I can confirm the HTTP service is working as expected. However when trying to connect to the RTR service using the rpki/rtrdump tool with the following command

$ sudo docker run -it --rm rpki/rtrdump -connect 192.168.x.x:3323 -file ""

It is able to connect but no vrps, aspas, bgpsec_pubkeys or roas are found (see below screenshot)

This would confirm what we are seeing on our router where it isn't able to sync.

Any advice on what might be the issue? Is there another tool that could be used to verify the routinator RTR?

[partim]

Not sure what exactly is wrong, but to quickly answer you last question before I can find the time to do some testing: You can try rtrlib‘s rtrclient. This should also be available in Debian’s rtr-tools package.

[spgreen]

Hi partim,

Thanks for the rtrclient suggestion!

Using $ rtrclient tcp -k -p 192.168.x.x 3323 command, it is able to retrieve ROAs as shown below.

The interesting thing is that rtrdump works for rpki-client + stayrtr (ingesting rpki.json file) but not for routinator. I am going to see if I am able to get more information on why this is happening by setting routinator logs to DEBUG.

[partim]

Thank you for the confirmation. Phew! ;)

I will have a look myself. My hunch would be that rtrdump and Routinator disagree about how to downgrade to a lower protocol version, ie. #919 which was fixed but will only be in the next release.

[spgreen]

Hi Partim,

Yeap looks like your hunch is correct with Routinator and rtrdump disagreeing on the downgrade.

Forcing rtrdump to use version 1 (by default it uses version 2), works fine! Command in question:
sudo docker run -it --rm rpki/rtrdump -connect 192.168.x.x:3323 -file "" -rtr.version 1

I think this is also the reason why our router running Extreme Network SLX-OS is unable to sync with Routinator but able to with rpki-client + stayrtr due to the RTR version and not being able to downgrade to version 1 properly.

Would you happen to know when the next release will come out?

[partim]

Interesting. I didn’t expect any routers to already support ASPA.

I want 0.14.0 to come out fairly soon, but there are still quite a few items on the milestone – and RTRTR should really have a release first. We’ll discuss internally if we should shift some of these items and release with only the important ones left.

[spgreen]

That's the weird thing, reading through the documentation for the SLX-OS, it doesn't support ASPA (for now).

I'll do some tcpdumps tomorrow to check what the SLX is doing when interacting with routinator.

[partim]

I’ve updated the unstable tag in Docker Hub. Perhaps you can try that image against the router and see if the issues go away before having to make sense of tcpdumps …

[spgreen]

Hi Partim,

Thanks for the unstable tag release for the Routinator image! I did test it with rtrdump again and still issues with downgrading to from RTR version 2 to version 1.

Also, I was able to determine the issue regarding the SLX-OS not being able to connect. I can confirm it is not due to the downgrade process as I originally thought; it was due to implicit deny on the ACL affecting transit traffic between the VXLAN tunnel endpoint on our routers and the RPKI validators.

In this case, should I close the issue, or should it be left open, pertaining to the downgrade of RTR protocol versions between rtrdump and Routinator?

Thanks for your help!

[partim]

Thank you for testing!

Please leave the issue open – I need to test the version downgrade against rtrdump and this is a good reminder.