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@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/