That made me curious... "Note: REALLY DONT store the validation state inside a bgp_community or bgp_large_community or bgp_ext_community variables. It can cause CPU & memory overload resulting in convergence performance issues." Why that ( CPU & memory overload ) would happen? Why is that different from a lookup against a Prefix List? Em sáb., 28 de mai. de 2022 às 09:57, Dan Mahoney (Gushi) < danm@prime.gushi.org> escreveu:
Hey all,
We're using RPKI in testing at the day job, and for a given route, it seems the best we can do is apply a community to it so we can see that it's invalid.
A howto I've found says that this is a bad idea and can cause problems. (https://bgpfilterguide.nlnog.net/guides/reject_invalids/)
When you look at routes with something like "show route all", there's no field for the RPKI status or the ASes for which ROAs are allowed.
So, the questions here is:
1) My understanding of the way RPKI-RTR works is that it's basically handed a tuple of prefix and AS, and RTR says "valid", "invalid", or "unknown". It feels like to check for AS 0 ROAs, we'd basically have to do two lookups for each route that's otherwise invalid, which feels inefficient. Is there a better way?
2) Can the output of "show route" be extended to include user defined fields, or are we locked into what's there?
3) If not, we're limited to adding communities or MEDs or local prefs or something like that, which is a hack, but at least gives us some info we can view. Is that a dangerous trade off?
-Dan
--
--------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC FB: fb.com/DanielMahoneyIV LI: linkedin.com/in/gushi Site: http://www.gushi.org ---------------------------
-- Douglas Fernando Fischer Engº de Controle e Automação