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@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
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@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@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
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@netflight.com> Sent: Wednesday, April 15, 2020 4:29 PM To: Jakob Heitz (jheitz) <jheitz@cisco.com> Cc: nanog@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@nanog.org<mailto:nanog@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@netflight.com<mailto:mpetach@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
participants (2)
-
Jakob Heitz (jheitz) -
Matthew Petach