On Mon, Apr 13, 2020 at 10:35 AM Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
Hi everyone,

how exactly do you aggregate routes? When do you add the AS_SET
attribute, when do you omit it? How does the latter interplay with RPKI?

Best regards,

Lars


I generally would use the atomic-aggregate knob to 
generate aggregate routes for blocks I controlled, 
when the downstream ASN information was not 
necessary to propagate outside my network 
(usually cases where I had multiple internal ASNs, 
but all connectivity funneled though a single upstream pathway.)

If you have discrete downstream ASNs with potentially 
different external pathways, you shouldn't be generating 
aggregate routes that cover them; that's just bad routing 101.

Thus, my rules for aggregation always came down to:
1) is there more than one external/upstream pathway for the ASN and prefix?  
    If so, don't aggregate.
2) is redundant, reliable connectivity between all the external gateway 
routers that would be announcing the aggregate?  
    If not, don't generate a covering aggregate.
3) If there's only a single upstream pathway through you for the ASN and prefix, 
and that won't be changing any time soon (eg, you have a collection of downstream 
datacenter with their own ASNs and prefixes, but they all route through a common
backbone), then use the atomic-aggregate option to suppress the more specific
AS_PATH information, and simply announce the space as a single aggregate coming
from your backbone ASN.

That way, there's no confusion with RPKI and AS_SETS; all you're ever announcing 
are simple AS_PATHs for a given prefix.

Best of luck!

Matt