Hi everyone, how exactly do you aggregate routes? When do you add the AS_SET attribute, when do you omit it? How does the latter interplay with RPKI? Best regards, Lars
Don't user as-sets step one. Rpki does not understand how to express an as-sets' authorization. Why do you want to do this? On Mon, Apr 13, 2020, 13:34 Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
Hi everyone,
how exactly do you aggregate routes? When do you add the AS_SET attribute, when do you omit it? How does the latter interplay with RPKI?
Best regards,
Lars
Thanks for all the answers! I think I have one more detail I'd like to know. Lets say you own X/22. You have delegated X/23 to your customer, keeping the other /23 for yourself. For some reason, your customer also owns and announced (to you) all remaining IPs necessary to complete X/21. Do you announce the aggregate X/21 (including addresses not associated with you), the aggregate X/22 (only address belonging to you), or the more specific route X/23 (including only addresses delegated from you to your customer)? Best regards, Lars On 14.04.20 06:07, Christopher Morrow wrote:
Don't user as-sets step one. Rpki does not understand how to express an as-sets' authorization.
Why do you want to do this?
On Mon, Apr 13, 2020, 13:34 Lars Prehn <lprehn@mpi-inf.mpg.de <mailto:lprehn@mpi-inf.mpg.de>> wrote:
Hi everyone,
how exactly do you aggregate routes? When do you add the AS_SET attribute, when do you omit it? How does the latter interplay with RPKI?
Best regards,
Lars
On Tue, Apr 14, 2020 at 3:02 PM Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
Thanks for all the answers! I think I have one more detail I'd like to know.
Lets say you own X/22. You have delegated X/23 to your customer, keeping the other /23 for yourself. For some reason, your customer also owns and announced (to you) all remaining IPs necessary to complete X/21.
(most of this is covered in petach's note actually... his 3 rules look like they cover your cases) Ideally if you have authorization to announce the /22 you do that. If your customer announces the /23 good for them, you can choose to hide this (if you don't think they have other paths where that /23 will be seen), you'd hide it through a bunch of different means, but perhaps simplest is tag customer routes which are part of your aggregates with a community and filter that community on exit to other peers.
Do you announce the aggregate X/21 (including addresses not associated with you), the aggregate X/22 (only address belonging to you), or the more specific route X/23 (including only addresses delegated from you to your customer)?
You don't have authorization to announce the /21 (given your scenario above) so please don't do that. That will make all manner of other people made at you :( I think your choices in your scenario are: 1) announce the covering /22 only (use community example to filter the customer's /23) 2) announce the covering /22 and the customer originated /23 you should never announce a prefix for which you do not have authorization to announce... this way leads to route hijacks.
Best regards,
Lars
On 14.04.20 06:07, Christopher Morrow wrote:
Don't user as-sets step one. Rpki does not understand how to express an as-sets' authorization.
Why do you want to do this?
On Mon, Apr 13, 2020, 13:34 Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
Hi everyone,
how exactly do you aggregate routes? When do you add the AS_SET attribute, when do you omit it? How does the latter interplay with RPKI?
Best regards,
Lars
From: NANOG <nanog-bounces@nanog.org> On Behalf Of Lars Prehn Sent: Tuesday, April 14, 2020 3:02 PM To: Christopher Morrow <morrowc.lists@gmail.com> Cc: nanog list <nanog@nanog.org> Subject: Re: Route aggregation w/o AS-Sets Thanks for all the answers! I think I have one more detail I'd like to know. Lets say you own X/22. You have delegated X/23 to your customer, keeping the other /23 for yourself. For some reason, your customer also owns and announced (to you) all remaining IPs necessary to complete X/21. Do you announce the aggregate X/21 (including addresses not associated with you), the aggregate X/22 (only address belonging to you), or the more specific route X/23 (including only addresses delegated from you to your customer)? Maybe I’m misreading this, but does the customer have LOA for the /21 aggregate? Thanks, Deepak
Hello Lars, As a comment there is a draft that proposes to deprecate AS_SET https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/... Alejandro, On 4/11/20 7:09 AM, Lars Prehn wrote:
Hi everyone,
how exactly do you aggregate routes? When do you add the AS_SET attribute, when do you omit it? How does the latter interplay with RPKI?
Best regards,
Lars
On Tue, Apr 14, 2020 at 1:04 AM Alejandro Acosta <alejandroacostaalamo@gmail.com> wrote:
Hello Lars,
As a comment there is a draft that proposes to deprecate AS_SET https://datatracker.ietf.org/doc/draft-ietf-idr-deprecate-as-set-confed-set/...
Ta, thanks. This completes the work started by RFC6472 - "Recommendation for Not Using AS_SET and AS_CONFED_SET in BGP". W
Alejandro,
On 4/11/20 7:09 AM, Lars Prehn wrote:
Hi everyone,
how exactly do you aggregate routes? When do you add the AS_SET attribute, when do you omit it? How does the latter interplay with RPKI?
Best regards,
Lars
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf
On Mon, Apr 13, 2020 at 10:35 AM Lars Prehn <lprehn@mpi-inf.mpg.de> wrote:
Hi everyone,
how exactly do you aggregate routes? When do you add the AS_SET attribute, when do you omit it? How does the latter interplay with RPKI?
Best regards,
Lars
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 (6)
-
Alejandro Acosta -
Christopher Morrow -
Deepak Jain -
Lars Prehn -
Matthew Petach -
Warren Kumari