Thanks for the replies. I think I saw somewhere around the Cloudflare outage post someone mentioning that since the person at Juniper that was responsible for Flowspec left it all went down hill.
I take it then Flowspec is still used internally then? I am still wondering if its best to avoid Flowspec and roll your own firewall rules applied via Netconf for transit interfaces to achieve the same sort of functionality. On 02/08/2013, at 3:30 AM, Richard A Steenbergen <r...@e-gerbil.net> wrote: > On Thu, Aug 01, 2013 at 10:00:49AM +1000, Mark Tees wrote: >> Howdy listers, >> >> I remember reading a while back that customers of nLayer IP transit >> services could send in Flowspec rules to nLayer. Anyone know if that >> is true/current? > > We were forced to stop offering flowspec connections to customers, after > we started experiencing a rash of issues with it. Among other things, we > found ways for flowspec generated rules to easily cause non line-rate > performance on Juniper MX boxes, and we had a couple of incidents where > customer generated routes were able to cause cascading failure behaviors > like crashing the firewall compiler processes across the entire network. > > I previously mentioned some of this here: > > http://mailman.nanog.org/pipermail/nanog/2011-January/030051.html > > There have also been a few other high profile outages caused by bugs in > the Juniper implementation, for example: > > https://support.cloudflare.com/entries/23294588-CloudFlare-Post-Mortem-from-Outage-on-March-3-2013 > > As a concept I still very much like Flowspec, and wish we could continue > to offer it to customers, but as with any "new" routing protocol there > are significant risks of network-wide impact if the implementation is > not stable. > > IMHO Juniper has done a horrible job of maintaining support for Flowspec > in recent years, and has effectively abandoned doing the proper testing > and support necessary to run it in production. Until that changes, or > until some other major router vendors pick it up and do better with it, > I don't expect to see any major changes in this position any time soon. > > -- > Richard A Steenbergen <r...@e-gerbil.net> http://www.e-gerbil.net/ras > GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)