Re: BGP FlowSpec support on provider networks
I am trying to compile data on which providers are currently supporting BGP Flowspec at their edge, if there are any at all. The few providers I've reached out to have indicated they do not support this and have no intention of supporting this any time in the near future. I'm also curious why something so useful as to have the ability to advertise flow specification information in NLRI and distribute filtering information is taking so long to gain a foothold in the industry...
<shamelessplug> nLayer has offered flowspec support to customers for many years now. </shamelessplug> It's really quite simple to use and support too, if you happen to have a largely Juniper based network that is. I'm not aware of any other router vendor who currently supports it, but the loss is entirely theirs. We do have a fair bit of Crisco in the network, with Juniper primarily in the core and peering/transit edge, so we use a route-server to feed the flowspec routes into the Juniper core. Customers set up an ebgp multihop session with it, and can announce flowspec routes (or standard blackhole via bgp communities) for anything in their register prefix-list. It's also quite handy for distributing internal use packet filters too. As for why something so (insanely) useful is slow to be adopted... There are a few reasons, but mostly: 1) A healthy dose of inter-vendor politics. 2) A silly religious belief that bgp shouldn't be used to carry firewall information, and that some other protocol should be invented instead. I think the counter-argument to that is the ability to do inter-provider filtering is precisely why it should be done via bgp. and the success of the current implementation proves how well it works. 3) Another large network who shall remain nameless once used a third party flowspec speaking piece of software which shall also remain nameless, and managed to blackhole their entire network for a noticeable amount of time. As with anything combining the words "network wide protocol" and "packet filter", a healthy amount of user discretion is advised. -- Richard A Steenbergen <ras@e-gerbil.net> http://www.e-gerbil.net/ras GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)
participants (1)
-
Richard A Steenbergen