Way to store ROA info so we can accept but view?

[Douglas Fischer]

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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://trubka.network.cz/pipermail/bird-users/attachments/20220530/e8bddb28/attachment.htm>