[169545] in North American Network Operators' Group
RE: Filter on IXP
daemon@ATHENA.MIT.EDU (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=)
Mon Mar 3 04:25:50 2014
From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= <adam.vitkovsky@swan.sk>
To: Nick Hilliard <nick@foobar.org>, =?iso-8859-2?Q?J=E9r=F4me_Nicolle?=
<jerome@ceriz.fr>, "nanog@nanog.org" <nanog@nanog.org>
Date: Mon, 3 Mar 2014 09:25:18 +0000
In-Reply-To: <53132B83.7020707@foobar.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> - the IXP participants keep their IRRDB information fully up-to-date
Geez anything else but the fully up-to-date IRRDB please. That just won't f=
ly.=20
That's why I said that an up to date IRRDB would have been a nice side effe=
ct of IXP filtering.=20
> - the IXP operators put in mechanisms to stop both route-leakages=20
> and incorrect IRRDB as-set additions from causing things to explode.=20
Yes this is a valid point
I think the technicalities of how to implement this kind of filtering at th=
e IXP equipment is out of scope for this discussion.=20
Anyways I believe IXPs should not be responsible for this mess and that BCP=
38 should be implemented by the participants of an IXP.=20
As Saku Ytti mentioned several times Tier2 ISPs are in the best position fo=
r a successful BCP38 filtering at their network boundaries.=20
adam
-----Original Message-----
From: Nick Hilliard [mailto:nick@foobar.org]=20
Sent: Sunday, March 02, 2014 2:01 PM
To: Vitkovsk=FD Adam; J=E9r=F4me Nicolle; nanog@nanog.org
Subject: Re: Filter on IXP
On 02/03/2014 12:45, Vitkovsk=FD Adam wrote:
>> On the other hand, if a member provides transit, he will add its=20
>> customer prefixes to RaDB / RIPEdb with appropriate route objects and=20
>> the ACL will be updated accordingly. Shouldn't break there.
>=20
> And that's a really nice side effect.
and it only works for leaf networks. The moment your ixp supports larger n=
etworks, 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 configuratio=
ns (including .1q / LAGs) for both IPv4 and IPv6 for both native layer 2 an=
d 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 installe=
d them on edge L2 ports (troublesome to implement and maintain)
- there is a fail-safe mechanism to prevent this from causing breakage (dif=
ficult to implement)
- the IXP participants keep their IRRDB information fully up-to-date (not g=
enerally true)
- the IXP operators put in mechanisms to stop both route-leakages and incor=
rect 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 t=
he 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
