Route aggregation w/o AS-Sets

Mailman List Mirror (Read Only)
1

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

2

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?

3

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/?include_text=1

Alejandro,

4

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

5

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/?include_text=1

Ta, thanks.
This completes the work started by RFC6472 - "Recommendation for Not
Using AS_SET and AS_CONFED_SET in BGP".

W

6

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

7

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 :frowning:

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.

8

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