<div dir="ltr"><br><div>I apologize if I wasn't clear.</div><div><br></div><div>I don't recommend ever using AS_SET.</div><div><br></div><div>So, in rule 3, I use the atomic-aggregate knob </div><div>to announce the single covering aggregate with </div><div>my backbone ASN as the atomic-aggregate origin </div><div>AS, and I don't generate or propagate any AS_SET </div><div>information along with the aggregate.</div><div><br></div><div>That way, no loop is seen by any of the downstream </div><div>networks that are announced the aggregate prefix.</div><div><br></div><div>I hope that helps clear up what I meant in my third</div><div>rule.  :)</div><div><br></div><div>Thanks!</div><div><br></div><div>Matt</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Apr 15, 2020 at 11:26 AM Jakob Heitz (jheitz) via NANOG <<a href="mailto:nanog@nanog.org">nanog@nanog.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Suppose you had a set of customers than all announced to you a set of routes<br>
and all those routes complete an aggregate<br>
and you announce only the aggregate to those customers<br>
and you include an AS_SET with it<br>
then those customers will drop your aggregate, thinking there is an AS-loop<br>
and those customers will not be able to reach each other.<br>
<br>
An AS_SET does not prevent routing loops and can prevent correct routing.<br>
<br>
But you must include the ATOMIC_AGGREGATE attribute, so that someone else<br>
does not disaggregate your aggregate that does not have the AS_SET.<br>
<br>
Regards,<br>
Jakob.<br>
<br>
-----Original Message-----<br>
Date: Tue, 14 Apr 2020 02:32:37 -0700<br>
From: Matthew Petach <<a href="mailto:mpetach@netflight.com" target="_blank">mpetach@netflight.com</a>><br>
<br>
I generally would use the atomic-aggregate knob to<br>
generate aggregate routes for blocks I controlled,<br>
when the downstream ASN information was not<br>
necessary to propagate outside my network<br>
(usually cases where I had multiple internal ASNs,<br>
but all connectivity funneled though a single upstream pathway.)<br>
<br>
If you have discrete downstream ASNs with potentially<br>
different external pathways, you shouldn't be generating<br>
aggregate routes that cover them; that's just bad routing 101.<br>
<br>
Thus, my rules for aggregation always came down to:<br>
1) is there more than one external/upstream pathway for the ASN and prefix?<br>
<br>
    If so, don't aggregate.<br>
2) is redundant, reliable connectivity between all the external gateway<br>
routers that would be announcing the aggregate?<br>
    If not, don't generate a covering aggregate.<br>
3) If there's only a single upstream pathway through you for the ASN and<br>
prefix,<br>
and that won't be changing any time soon (eg, you have a collection of<br>
downstream<br>
datacenter with their own ASNs and prefixes, but they all route through a<br>
common<br>
backbone), then use the atomic-aggregate option to suppress the more<br>
specific<br>
AS_PATH information, and simply announce the space as a single aggregate<br>
coming<br>
from your backbone ASN.<br>
<br>
That way, there's no confusion with RPKI and AS_SETS; all you're ever<br>
announcing<br>
are simple AS_PATHs for a given prefix.<br>
<br>
Best of luck!<br>
<br>
Matt<br>
<br>
<br>
</blockquote></div>