I’ve configured a route map with RPKI validation matches as below and applied it to a BGP neighbor:
set policy route-map IPT1_IN rule 10 action 'deny'
set policy route-map IPT1_IN rule 10 match rpki 'invalid'
set policy route-map IPT1_IN rule 20 action 'permit'
set policy route-map IPT1_IN rule 20 match ip address prefix-list "PL_eBGP_IPv4_IN"
set policy route-map IPT1_IN rule 20 match rpki 'valid'
set policy route-map IPT1_IN rule 20 set local-preference '200'
set policy route-map IPT1_IN rule 30 action 'permit'
set policy route-map IPT1_IN rule 30 match ip address prefix-list "PL_eBGP_IPv4_IN"
set policy route-map IPT1_IN rule 30 match rpki 'notfound'
set policy route-map IPT1_IN rule 30 set local-preference '150'
set policy route-map IPT1_IN rule 40 action 'deny'
However, there was no connection to RPKI cache beforehand. This in turn denied all the routes received from that neighbor. My question is, if there was never a connection to a RPKI cache, what is the initial RPKI state of received routes? Is it mentioned in the documentation somewhere?
I think if it’s not, maybe the documentation can be updated. Or, change the behavior of prefixes that are received without any RPKI cache connection to be defaulted to “notfound“.
Btw, the “PL_eBGP_IPv4_IN“ prefix list is just to filter out routes smaller than /24.
If no connection to an RPKI cache server can be established after a pre-defined timeout, the router will process routes without prefix origin validation. It still will try to establish a connection to an RPKI cache server in the background.
So basically it’ll just process the routes as normal. VyOS uses FRRouting for BGP (that note from the VyOS docs is directly from the FRR BGP page), so any change would need to be an upstream request, but defaulting routes to notfound would likely not be a good idea.
That would in some ways defeat the purpose of RPKI. And if a user were to try to extend RPKI with RFC 8097 extended communities, it could get even worse. Then valid/invalid routes would be treated the same as routes with no ROA.
Gotcha. So if no cache server connection can be made, assumes that route validations states is not available. This means my route map is actually quite dangerous if the RPKI server infra is not resilience enough. Need to remove rule 40 (or change the local pref I think).
Yeah, you can make a rule after your RPKI stuff matching your pfx-list and have it set a community. Then you’ll be able to track learned routes when the RPKI connection is inactive.
So if you wanted to not advertise it somewhere, or set LP or something, you’ll be able to do it easily.