BCP38 - Internet Death Penalty

Thu Mar 28 17:58:03 UTC 2013

In a message written on Thu, Mar 28, 2013 at 01:10:53PM -0400, William Herrin 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.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 826 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20130328/9885e88c/attachment.sig>