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 < [email protected]> 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 <[email protected]> > > 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 > > >
