Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not receiving ROAs over RTR using rtrdump #950

Open
spgreen opened this issue Apr 4, 2024 · 9 comments
Open

Not receiving ROAs over RTR using rtrdump #950

spgreen opened this issue Apr 4, 2024 · 9 comments

Comments

@spgreen
Copy link

spgreen commented Apr 4, 2024

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
    image
    image

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)

image

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
Copy link
Member

partim commented Apr 4, 2024

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
Copy link
Author

spgreen commented Apr 4, 2024

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.

image

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
Copy link
Member

partim commented Apr 4, 2024

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
Copy link
Author

spgreen commented Apr 4, 2024

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
Copy link
Member

partim commented Apr 4, 2024

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
Copy link
Author

spgreen commented Apr 4, 2024

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
Copy link
Member

partim commented Apr 4, 2024

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
Copy link
Author

spgreen commented Apr 5, 2024

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
Copy link
Member

partim commented Apr 5, 2024

Thank you for testing!

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants