Route aggregation w/o AS-Sets

Matthew Petach mpetach at netflight.com
Tue Apr 14 09:32:37 UTC 2020


On Mon, Apr 13, 2020 at 10:35 AM Lars Prehn <lprehn at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20200414/b5249817/attachment.html>


More information about the NANOG mailing list