Steps to reproduce:
set protocols rpki cache foo address 1.1.1.1 set protocols rpki cache foo port 80 set protocols rpki cache bar address 2.2.2.2 set protocols rpki cache bar port 90
The rendered FRR config is:
rpki rpki polling_period 3600 rpki cache 2.2.2.2 90 preference 1 exit
but FRR itself supports multiple peers
The problem with preference, it should be different
rpki rpki polling_period 3600 rpki cache 192.168.122.12 90 preference 1 exit hostname r5-roll
Add new one
r5-roll(config-rpki)# rpki cache 192.168.122.11 80 preference 1 Cache with preference 1 is already configured r5-roll(config-rpki)#
Cache with preference 1 is already configured
Adding with preference 2
r5-roll(config-rpki)# rpki cache 192.168.122.11 80 preference 2 r5-roll(config-rpki)# end show run rpki rpki polling_period 3600 rpki cache 192.168.122.12 90 preference 1 rpki cache 192.168.122.11 80 preference 2 exit
There's an easy workaround to hack this into your "configure" scripts:
sudo mv /opt/vyatta/share/vyatta-cfg/templates/protocols/rpki/preference /opt/vyatta/share/vyatta-cfg/templates/protocols/rpki/cache/node.tag
Then your config will look like:
rpki {
cache avalon {
address xxx.xxx.128.2
port 3323
preference 2
}
cache valhalla {
address xxx.xxx.128.4
port 3323
preference 4
}
}But it doesn't survive an upgrade!
This is a config syntax design mistake on our side indeed. The "preference" option should have always been under "cache".
However, we can't "just" move it there because it will break existing configs: the old "protocols rpki preference" option will become invalid! The good thing is that since the old configs could not have more than one peer, there is no undecidable preference mapping problem. A migration script should be quite straightforward, it will just need quite a bit of testing to make sure existing configs keep working fine after migration. I think it's doable for 1.2.8