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