[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.  :)



On Wed, Apr 15, 2020 at 11:26 AM Jakob Heitz (jheitz) via NANOG <
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>
> 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/56aee407/attachment.html>