Page MenuHomeVyOS Platform

rpki connection not working
Closed, ResolvedPublicBUG

Description

Somehow on my router the rpki connections are not working all the time. If I remove the configuration and add it again, it works sometimes after a while. But it stays off after the restart at the latest.

The problem seems very similar to T2044, but this one is closed for 1.4.0.

I have changed the IPs, hostname and user. I can ping all IPs.

user@r2.DOMAIN:~$ show version 
Version:          VyOS 1.4.0
Release train:    sagitta
Release flavor:   generic

Built by:         Sentrium S.L.
Built on:         Tue 04 Jun 2024 09:23 UTC
Build UUID:       5e6ae0c4-4d17-4b69-9247-b4ba44a3e3c2
Build commit ID:  35dd8ae6522c78-dirty

Architecture:     x86_64
Boot via:         installed image
System type:      bare metal

Hardware vendor:  To be filled by O.E.M.
Hardware model:   To be filled by O.E.M.
Hardware S/N:     To be filled by O.E.M.
Hardware UUID:    03000200-0400-0500-0006-000700080009

Copyright:        VyOS maintainers and contributors
user@r2.DOMAIN:~$ show configuration commands |grep rpki
set protocols rpki cache 2a0e:IPv61 port '323'
set protocols rpki cache 2a0e:IPv61 preference '201'
set protocols rpki cache 46.IPv41 port '323'
set protocols rpki cache 46.IPv41 preference '202'
set protocols rpki cache 82.IPv42 port '3323'
set protocols rpki cache 82.IPv42 preference '102'
set protocols rpki cache 2001:IPv62 port '3323'
set protocols rpki cache 2001:IPv62 preference '101'
user@r2.DOMAIN:~$ show rpki cache-connection 
No connection to RPKI cache server.
user@r2.DOMAIN:~$
user@r2.DOMAIN:~$ tail -8 /etc/frr/frr.conf 
rpki
 rpki polling_period 300
 rpki cache 2a0e:IPv61 preference 201
 rpki cache 46.IPv41 323 preference 202
 rpki cache 82.IPv42 3323 preference 102
 rpki cache 2001:IPv62 3323 preference 101
exit
!
user@r2.DOMAIN:~$

Details

Version
1.4.0
Is it a breaking change?
Unspecified (possibly destroys the router)
Issue type
Bug (incorrect behavior)

Related Objects

Event Timeline

c-po triaged this task as High priority.

Sorry, but that was my own mistake. When I checked again today, I noticed that the connections were not allowed in the firewall.

I can't quite explain why it sometimes worked anyway, but I suspect it was related to which interface was used for the connection and therefore a different rule happened to be applied. My removal and addition of the configuration probably led to “success” more by chance.