nLayer IP transit

[marktees at gmail.com (Mark Tees)]

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 <ras at 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 <ras at e-gerbil.net>       http://www.e-gerbil.net/ras
> GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)