Route aggregation w/o AS-Sets

Wed Apr 15 23:32:30 UTC 2020

Sorry, I did not intend to imply that you were.
I should have prefaced my post with "to add".

Regards,
Jakob.

From: Matthew Petach <mpetach at netflight.com>
Sent: Wednesday, April 15, 2020 4:29 PM
To: Jakob Heitz (jheitz) <jheitz at cisco.com>
Cc: nanog at nanog.org
Subject: Re: Route aggregation w/o AS-Sets

I apologize if I wasn't clear.

I don't recommend ever using AS_SET.

So, in rule 3, I use the atomic-aggregate knob
to announce the single covering aggregate with
my backbone ASN as the atomic-aggregate origin
AS, and I don't generate or propagate any AS_SET
information along with the aggregate.

That way, no loop is seen by any of the downstream
networks that are announced the aggregate prefix.

I hope that helps clear up what I meant in my third
rule.  :)

Thanks!

Matt

On Wed, Apr 15, 2020 at 11:26 AM Jakob Heitz (jheitz) via NANOG <nanog at nanog.org<mailto:nanog at nanog.org>> wrote:
Suppose you had a set of customers than all announced to you a set of routes
and all those routes complete an aggregate
and you announce only the aggregate to those customers
and you include an AS_SET with it
then those customers will drop your aggregate, thinking there is an AS-loop
and those customers will not be able to reach each other.

An AS_SET does not prevent routing loops and can prevent correct routing.

But you must include the ATOMIC_AGGREGATE attribute, so that someone else
does not disaggregate your aggregate that does not have the AS_SET.

Regards,
Jakob.

-----Original Message-----
Date: Tue, 14 Apr 2020 02:32:37 -0700
From: Matthew Petach <mpetach at netflight.com<mailto:mpetach at netflight.com>>

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/20200415/9285ab30/attachment.html>