[169539] in North American Network Operators' Group
RE: Filter on IXP
daemon@ATHENA.MIT.EDU (=?iso-8859-2?Q?Vitkovsk=FD_Adam?=)
Sun Mar 2 07:46:10 2014
From: =?iso-8859-2?Q?Vitkovsk=FD_Adam?= <adam.vitkovsky@swan.sk>
To: =?iso-8859-2?Q?J=E9r=F4me_Nicolle?= <jerome@ceriz.fr>, Nick Hilliard
<nick@foobar.org>, "nanog@nanog.org" <nanog@nanog.org>
Date: Sun, 2 Mar 2014 12:45:13 +0000
In-Reply-To: <5310C145.6080402@ceriz.fr>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> On the other hand, if a member provides transit, he will add its=20
> customer prefixes to RaDB / RIPEdb with appropriate route=20
> objects and the ACL will be updated accordingly. Shouldn't break there.=20
And that's a really nice side effect.
However in case of transit providers the problem is that RaDB /RIPE lists w=
hat prefixes you are allowed to advertise.=20
But that does not necessarily fully match with what source IPs can leave yo=
ur network.=20
I mean ISP-A can have a customer that uses PA range of other ISP-B and only=
has a static route towards ISP-A for some TE purposes.=20
I'm not well versed with RIPE myself so I'm not sure whether there's a way =
to handle this situation.=20
adam
-----Original Message-----
From: J=E9r=F4me Nicolle [mailto:jerome@ceriz.fr]=20
Sent: Friday, February 28, 2014 6:03 PM
To: Nick Hilliard; nanog@nanog.org
Subject: Re: Filter on IXP
Le 28/02/2014 17:52, Nick Hilliard a =E9crit :
> this will break horribly as soon as you have an IXP member which=20
> provides transit to other multihomed networks.
It could break if filters are based on announced prefixes. That's precisell=
y why uRPF is often useless.
On the other hand, if a member provides transit, he will add its customer p=
refixes to RaDB / RIPEdb with appropriate route objects and the ACL will be=
updated accordingly. Shouldn't break there.
--
J=E9r=F4me Nicolle
+33 6 19 31 27 14
