Filter on IXP
Nick Hilliard
nick at foobar.org
Sun Mar 2 13:00:51 UTC 2014
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
More information about the NANOG
mailing list