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