Hi,
On 17/08/2018, 12:21, James Bensley <[email protected]> wrote:
> For example - AS51551, I want to peer with them so I want their AS-SET
> so that I can accept their routes, and all downstream customer routes.
There’s a couple of subtleties missing from existing replies to the comments in
the thread you started, so I hope it’s ok to make some comments now.
Firstly, the Internet thanks you for your secure approach to routing
configuration by filtering based on their IRR data. For configuring prefix
filtering of your peers, in order to limit the effect of routing leaks on end
user enjoyment and security. You are a knight of the peering realm and my
horse is forever at your disposal.
Secondly, the AS-SET is something that the peer should communicate to you,
rather than something that you should ‘detect’. It is possible that one peer
may wish to indicate that they wish to send you different prefixes to what they
send to someone else. For example they may send their global customer routes to
knights of the peering realm like you, so you should use AS-65534:GLOBAL,
whereas gutterick serfs should expect the regional or local prefixes and
therefore a different filter. Or perhaps there is a product/partner
relationship that means they want to signal deaggregates or additional
transited networks to you which they do not want to send to other peers. The
point I am trying to make is that your peering partner should indicate the
as-macro that they wish you to filter against in your BGP setup. That said,
it’s reasonable to expect that if you are not negotiating anything special to a
peer’s usual behaviour you should get the peer’s usual as-macro, but again they
should explicitly communicate that rather than have you detect it. The usual
place to explicitly communicate your peering preferences as a peering network
is peeringdb and Job has made this point already in this thread.
Lastly, remember RPKI, especially if you want to build filters containing
prefixes being originated by networks in regions where there is poor IRR
adoption but more wide RPKI adoption.
Best wishes,
Andy
