Re: Filter on IXP

[Nick Hilliard <nick () foobar org>]

On 02/03/2014 12:45, Vitkovský Adam wrote:
> > On the other hand, if a member provides transit, he will add its 
> > customer prefixes to RaDB / RIPEdb with appropriate route 
> > objects and the ACL will be updated accordingly. Shouldn't break there. 
>
> And that's a really nice side effect.

and it only works for leaf networks.  The moment your ixp supports larger
networks, it will break things horribly.

It also assumes that:

- all your IXP members use route servers (not generally true)

- the IXP kit can filter layer 3 traffic on all supported port
configurations (including .1q / LAGs) for both IPv4 and IPv6 for both
native layer 2 and VPLS (not generally true)

- the IXP port ASICs can handle large L2 access lists (not generally true)

- there is an automatic mechanism in place to take RS prefixes and
installed them on edge L2 ports (troublesome to implement and maintain)

- there is a fail-safe mechanism to prevent this from causing breakage
(difficult to implement)

- the IXP participants keep their IRRDB information fully up-to-date (not
generally true)

- the IXP operators put in mechanisms to stop both route-leakages and
incorrect IRRDB as-set additions from causing things to explode.

Last but not least:

- there is a mandate from the ixp community to get the IXP operators into
the business of filtering layer 3 data (not generally the case)

There are many places where automated RPF makes a lot of sense.  An IXP is
not one of them.

Nick