On Fri, May 05, 2017 at 10:51:41PM +0000, Jakob Heitz (jheitz) wrote: > Thanks Robert. > > I did it without using ios-regex or other time consuming string conversion > stuff. > Still, this method cannot scale to cover every one of several thousand AS > neighbors that some ISPs have. > IOS cannot handle that many as-path access-lists. > I can see that the simple rule of "do not allow peer routes from a customer" > doesn't cut it, because some tier-1's have a lot of customers with over 10000 > routes each. > My filters will certainly cover all the major peers as well as major > customers of ISPs. > I included a limit on the number of policies to write: > so that it will just get the major ones. > Also, if a routing table includes leaks, then the resulting policies will > continue to allow the leaks. > Also, some of the filters may need to add some upstreams that are not in the > table of the day. > Basically, it is a start that may require a bit of tweaking. > I have a better idea of what to commit to the IOS. > It will be far more efficient, but I want to gauge interest first.
I built something very similar using Juniper commit scripts many years ago, and used it at GTT, a very large Tier 1 network. It was fairly straight forward, all you had to do was feed it an ASN list of your "tier 1" peers (ASNs which should never be heard behind anyone other than ^asn.*), and "tier 2" peers (ASNs which can be heard as ^asn.* as well as ^(tier1|list|here) asn.*). It would then automatically create custom as-path filters for each BGP peer, based on the individual session and where it found the neighbor asn on the list. For customer sessions, it was also easy to incorporate simple as-path filters for the most common leaks, e.g. you should never here anything on the tier 1 list from any of your customers under any circumstances. I'd be happy to release the code if anyone is interested. For a well-connected well-peered network, this was absurdly effective at preventing huge numbers of the most common routing leaks. In my experience, the VAST majority of leaks are caused by simple human typos, and/or mistakes caused by things like the (IMHO incredibly poor) default behavior to announce everything on a new BGP session with no configured policy. That said, I have great difficulty imagining how you would successfully create any kind of 100% automated as-path filter system based on observed behavior in the routing table, based on my many years of experience running some of the largest Tier 1 networks on the planet. It's simply not practical in the real world. I WOULD highly encourage you to pursue building better as-path filtering tools similar to the scenario I described above though. It would be great if you could easily feed your router some as-path-lists, and configure your policy to build the filters described above without needing a script to create a per-as as-path filter expression. I wouldn't recommend trying to turn it on automatically, but you'd probably help a large number of ISPs by giving them the ability to build these filters without requiring complex scripting, of offline config automation tooling. But the one thing I think every vendor COULD do to vastly improve the accidental route leak situation is precisely what this draft suggests, default to reject for EBGP neighbors with no configured policy. That's one of the very first things I've baked into every one of my configs, a default DENY-ALL policy for all BGP neighbors (which was easy to do at the top level "protocols bgp" with Juniper), and I have no doubt that it saved ME from making countless mistakes over the years. To err is human (just look at our routing protocols :P), and a default policy of "announce everything, and hope the other side is doing perfect filtering" simply has no place in THE global routing protocol. I certainly understand the need for caution when making such a major change in default behaviors, and would absolutely suggest a multi-year phased approach with large numbers of warnings for neighbors which lack configured policies leading up to the default knob switch. I'd also suggest that every router vendor start by adding a simple knob which can change the default behavior globally, and then encourage everyone to turn that on as a best practice starting immediately. But I'd also argue that none of this should get in the way of trying. Yes it will take many many years, and it won't solve anything, but the sooner we start the sooner the change can happen. I'd also argue that this change will be vastly more beneficial than many of the other more dubious efforts we've collectively wasted FAR more time and energy, such as RPKI. Accidental origination almost NEVER happens in the real world, but accidental leaks due to default allow policies happen every day. That makes this one of the most practical and sensible changes I've seen proposed to BGP in a long, long time. -- Richard A Steenbergen <[email protected]> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC) _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
