On Fri, Jun 12, 2015 at 12:53:13PM -0300, jim deleskie wrote:
Filtering has been a community issue since my days @ MCI being AS3561, often discussed not often enough acted one, I suspect the topic has come up at every "large" NSP I've worked at. Frequently someone complains its "hard" to fix, or router X makes it hard to fix, or customer Y won;t agree, and not enough people stand up to force fix the issues. I've did a preso on it ( while working at TATA) with some other "smart folks" but for all the usual reasons it died on the vine.
Next time around put up more of a fight? :-) In all seriousness not all hope is lost: Even on the crappiest platforms, an operator can do better then nothing with little effort. The simplest protection mechanism of all: maximum prefix limits. If you turn up a peer or customer, confirm with them how many routes you should expect, add 15% and configure that. In this day and age AS_PATH filters are still underutilized, if you apply them on egress they are a very easy way to prevent sending routes from your upstream to your peers, or accepting your upstreams routes from peers/customers. Vote with your wallet, talk to your vendors how to make your life easier. Once example: ask Cisco to implement https://tools.cisco.com/bugsearch/bug/CSCuq14541 ("Add "bgp enforce ebgp-outbound-policy" knob to prevent route leaks" - this is a PR asking that if a new neighbor is configured you don't immediatly send all routes & accept everything). There are actively maintained open source tools such as bgpq3 which can help you generate filters to apply on your customer sessions: it takes 2 seconds to generate an effective IOS prefix-list for 4788: Vurt:~ job$ time bgpq3 -h rr.ntt.net -A AS-TMNET-CUSTOMERS | wc -l 6884 real 0m1.947s (source: https://github.com/snar/bgpq3 - can output in BIRD, XR, IOS, JunOS or JSON syntax) Today there are plenty of networks which use the above techniques successfully on a variety of devices. Kind regards, Job