Way to store ROA info so we can accept but view?
Ondrej Zajicek
santiago at crfreenet.org
Mon May 30 15:35:12 CEST 2022
On Mon, May 30, 2022 at 02:52:21PM +0200, Job Snijders wrote:
> Hi Douglas,
>
> Rejecting a route *and* tagging it with a community is not what causes
> problems: because you are *rejecting* the route (for example because
> bogon, or rpki-invalid), there is no routing churn problem further
> downstream.
>
> The problem Dan Mahoney writes about is when you attach a BGP community
> to "valid" or "not-found" routes: if your validator/RTR server ever has
> some kind of issue (for example when it crashes), all "valid" routes
> would flip to "not-found" state, causing BGP churn for 37%+ of routes in
> a full table view. Of course, after the crashed validator restarts
> (comes back online), those hundreds of thousands of routes *again*
> require new BGP UPDATE messages to remove the "not-found" and attach the
> "valid" community.
>
> In short:
>
> * Reject RPKI-invalid routes (optionally using the BIRD trick to attach
> a community to a rejected route)
> * Do NOT attach communities to routes that are "valid" or "not-found"
> merely because they are valid/not-found.
>
> Does the above description make sense?
Hi
I think that important point here is that if your RPKI infrastructure is
OK, you cannot have two routes for one prefix where one is 'valid' and
the other is 'not-found' (because the prefix is either covered leading to
'valid' or 'invalid', or not leading to 'not-found'), so for routing
purposes the distinction between 'valid' and 'not-found' is irrelevant.
If your RPKI infrastructure has some consistency issues (say one RTR
server crashed that is used by half the border routers, while other half
still doing ok, or perhaps something less dramatic like some border
routers have received BGP routes from peers, but not yet loaded RPKI
records from cache), then there is a point in marking 'valid' routes
distinctly from 'not-found' routes:
If one border router receives invalid route, but due to RPKI issues mark
it as 'not-found', while some other border router receives a valid route
and mark it as 'valid' (does not matter whether by communities or directly
by local_pref), then internal routers would prefer the valid route,
while if there is no marking they can switch to the invalid.
--
Elen sila lumenn' omentielvo
Ondrej 'Santiago' Zajicek (email: santiago at crfreenet.org)
OpenPGP encrypted e-mails preferred (KeyID 0x11DEADC3, wwwkeys.pgp.net)
"To err is human -- to blame it on a computer is even more so."
More information about the Bird-users
mailing list