[56546] in North American Network Operators' Group
Re: 69/8...this sucks -- Centralizing filtering..
daemon@ATHENA.MIT.EDU (Russell Heilling)
Mon Mar 10 16:39:26 2003
Date: Mon, 10 Mar 2003 21:38:48 +0000
From: Russell Heilling <russell@ccie.org.uk>
To: Jack Bates <jbates@brightok.net>
Cc: nanog@merit.edu
In-Reply-To: <015601c2e73c$c2920a40$b66e1ece@brightok.net>
Errors-To: owner-nanog-outgoing@merit.edu
--J2SCkAp4GZ/dPZZf
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Mon, Mar 10, 2003 at 01:39:26PM -0600, Jack Bates wrote:
>=20
> Oh, I agree that there are times when BGP is used in a single uplink
> scenario, but it is not common. However, someone pointed me to ip verify
> unicast source reachable-via any which seems to be available on some of t=
he
> cisco Service provider releases. It's an interesting concept and I'm itch=
ing
> to play with it. If you aren't in my routing table, then why accept the IP
> address?
I've been using this method to do "loose source verification" for a while=
=20
now, and it's certainly better than nothing, but it doesn't really do as=20
much as it should when you only receive a partial table from a peer. I've=
=20
been toying with the idea of supporting strict reverse path verification=20
on peering links by using vrfs. It works really well in the Lab, but=20
migrating the whole network into an MPLS VPN just to get some extra=20
source filtering ability seems a little extreme to me for some reason...=20
;)
It'd work really well if Cisco allowed the global table as a vrf
import/export target though.
--=20
Russell Heilling
http://www.ccie.org.uk
PGP: finger russellh@bela.homeunix.net
--J2SCkAp4GZ/dPZZf
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)
iD8DBQE+bQXoBMttZdT/dSURAtRLAJ9vTo5ieoSidgOXpFQMI5B0cNmtLwCgmaHr
Doy3DtlnHRaM6uIf5ppWykc=
=0rXE
-----END PGP SIGNATURE-----
--J2SCkAp4GZ/dPZZf--
