[j-nsp] SRX hardware acceleration caveats

[Pavel Lunin]

2012/6/19 Benny Amorsen <benny+usenet at amorsen.dk>

>
> > To be honest, by now it looks like a feature for a particular customer.
>
> To me it seems like a feature for every customer... Without offloading,
> how would you do stateful firewalling at 10Gbps+?
>

Em… isn't 10G+ possible on SRX HE without offloading?

Well, don't get me wrong. I nowhere said the offloading idea itself is bad
of whatever. But yes, I said it has challenges when it comes to scaling (we
saw it in the past), and I really don't know whether it can be solved these
days by commercially reasonable means, or maybe the current semi-software
(MS-PIC/SPU-like) approach is still easier and chipper. Again, I'm not
saying I know the answer and the second way is better.  But if any vendor
announces an offload-based stateful device able to do tens and hundreed of
gigs, first thing I want to ask is "what about scaling?". And by now I
don't see much answer for this in the context of SRX-HE. In addition I see
lots of other quite serious limitations.

And what I mean with "a feature for a particular customer" is not a
feature, which other people don't need, but a feature that was implemented
for a key-customer, who can use it with current limitations. If it were at
least Trio LU, I'd more optimistic, but investing into the EZChip-based
offload really seems like a temporary solution. Well, IMHO.