[169540] in North American Network Operators' Group
Re: Filter on IXP
daemon@ATHENA.MIT.EDU (Nick Hilliard)
Sun Mar 2 08:01:22 2014
X-Envelope-To: nanog@nanog.org
Date: Sun, 02 Mar 2014 13:00:51 +0000
From: Nick Hilliard <nick@foobar.org>
To: =?ISO-8859-2?Q?Vitkovsk=FD_Adam?= <adam.vitkovsky@swan.sk>,
=?ISO-8859-2?Q?J=E9r=F4me_Nicolle?= <jerome@ceriz.fr>,
"nanog@nanog.org" <nanog@nanog.org>
In-Reply-To: <61DC6BC4ABA10E4489D4A73EBABAC18B011CCF4E@EX01.swan.local>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.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
