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) < d...@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
