[161928] in North American Network Operators' Group
Re: BCP38 - Internet Death Penalty
daemon@ATHENA.MIT.EDU (Leo Bicknell)
Thu Mar 28 13:59:33 2013
Date: Thu, 28 Mar 2013 10:58:03 -0700
From: Leo Bicknell <bicknell@ufp.org>
To: nanog@nanog.org
Mail-Followup-To: nanog@nanog.org
In-Reply-To: <CAP-guGX+oPDU_Z719DRMAB3NohGZ4AyhKQbM65x+k3tLaJtFdQ@mail.gmail.com>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
--s/l3CgOIzMHHjg/5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In a message written on Thu, Mar 28, 2013 at 01:10:53PM -0400, William Herr=
in wrote:
> Since you've configured a prefix list to specify what BGP routes
> you're willing to accept from the simple multihomed customer (you
> have, right?) why set a source filter from the same data instead of
> trying to build it from routing table guesswork?
In the simplest case I described (user has for instance one netblock)
the packet filter will match the routing filter, and doing what you
described would not be a huge extra burden. Howver, it is still a
burden, it's writing everything twice (prefix list plus ACL), and
it's making configs longer and less readable.
But the real power here comes by applying this filter further up the
food chain. Consider peering with a regional entity at an IX. Most
people don't prefix filter there (and we could have a lively argument
about the practicality of that), so the prefix list might be something
like:
deny my_prefix/foo le 32
permit 0.0.0.0/0 le 24
With a max-prefix of 100.
That doesn't turn into a useful packet filter for the peer, but using my
method the peer could be RPF filtered based on what they send,
automatically.
--=20
Leo Bicknell - bicknell@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/
--s/l3CgOIzMHHjg/5
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (FreeBSD)
iQIVAwUBUVSEq7N3O8aJIdTMAQLobA/7BN3t6FUL5wmZffYeifJyW6gLmv7xdXsz
eh9t8sDVqzfh7xoEtcdnzSazJdYuqSEiVzCjhu36nOYWQTLLGi9bJnDZQYluB+RY
3MqrsK+y56NsTqHG8gzQaU9UTVeTUdG58ifu5RQQ7qHWkQwQsg3zG5/8q4jIHkL0
8R8zGWWtHXh6nN8N7mAIEPltSi96OFb95TFPYwccwuFULVh/Ng/VO8lmR4rPMT5P
BHlngUpt97yBkaaRNHyNtNieEi5Wc7eSuUoSlabpR0WnKjMDremoVceuhqAZec45
Ah4afzCIp1LxrAD+BJvAeFpZSI3GvarhJhsQ/cLAViHskmmCcdtQZBq08Hj7nTwF
+UvvBjWYJeq9u7gMRC15Nc9zKOfXQQoXetZddpWd33VY/CQsvgqo4Ur5KUr7RqMX
f2DQqySAeTxarjZ5RMfWNNGIEhVHpy3+zF3LoMCpnjJVZrENQAnsrRynkDluRpWn
gkWXUshgjfnbaPu7nArVLKoNlN5N2HvEscCcfkfS6ZHbEmFQt2rpXvnr+Ht4Jecv
AeJ1SgxsTIS0vMu2/xPBqDXbqFCAkrS8fvfsxS4m6eyKas16Cu6XTxQmqrqFvHh6
fUeqQ9unw6RrvuhufDDXsKMDcf2RNKpQMUwDg/JnDVp3De2zRKvLrKTcLtcd+7TQ
6i3gm1e1hiQ=
=t3eB
-----END PGP SIGNATURE-----
--s/l3CgOIzMHHjg/5--
