[j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
leigh.porter at ukbroadband.com
Thu Jul 22 18:11:17 EDT 2010
I absolutely agree with the posts on the J-series boxes. I need lots of small(ish) boxes that will do a reasonable throughput of MPLS (PWEs, L3VPN etc) and I was really liking the J-series, but I need some QinQ stuff that they dont support, so I thought about the SRX would be ideal, but these recent JUNOS releases have been less than stable and after spending days trying to make stuff work that suddenly got fixed with a 10.1 release just reminds me a little too much of Cisco.
Now, I would never use Cisco in anything but a switch any more, but this whole flow mode thing and recent JUNOS releases have made me get other vendors into my labs and I would rather use Juniper.
I have J-series boxes that have to run code bloated by this crazy flow thing, SRXs that, well, dont seem to be all they could be (I was going to use SRX100s for a load of CPE till I watched one boot up....)
From: juniper-nsp-bounces at puck.nether.net on behalf of Chris Whyte
Sent: Thu 7/22/2010 8:59 PM
To: Amos Rosenboim
Cc: juniper-nsp at punk.nether.net
Subject: Re: [j-nsp] J series users bitten by the massive memory useincrease with flow mode add, please file jtac cases.
I understand. I was specifically addressing the high-level comment/concern
that Juniper might do the same (ie implement flow mode) on M/MX/T series.
SRX serves this purpose. That's all.
My concern is that not everyone seems to understand the high-level decisions
behind architecture, product and feature direction. I personally find it
difficult that anyone can understand specific details without understanding
these fundamental decisions first. Hence I was just trying to chime in with
that type of information. By injecting some of this commentary it is also
likely that the decision makers at certain BUs at Juniper will see some of
your concerns first hand. My intention is a positive one. I promise you. :-)
Another way to look at it: It's akin to understanding the why Juniper chose
the one OS architectural approach vs Cisco choosing the N x OS architectural
approach. Why choose a vendor until you fully understand the benefits of
their architectural decisions?
On 7/22/10 12:36 PM, "Amos Rosenboim" <amos at oasis-tech.net> wrote:
> The discussion is about J series routers, not SRXs.
> The J series are marketed as routers not security devices and turning
> them to security devices all of a sudden is a decision I still don't
> If you want to open a discussion about SRX we can do that.
> I have no experience with the high end SRXs but a lot of experience
> with the lower end SRX devices (210-650) and I can honestly say that I
> consider them to be the worst piece of networking/security hardware I
> ever worked with.
> The software quality for these devices is catastrophic, including many
> stability related bugs which crashed devices time after time.
> The logging of the devices is so inconvenient and also affect
> performance significantly, to a level where logging advised by JTAC
> killed a device.
> I heard this not only from colleagues but also from advanced JTAC
> It came to a point where my company stopped selling SRX devices and
> talking to the local distributer I understand that the overall Juniper
> security sales (in our small country) declined significantly.
> It's important to mention that I'm a big Juniper fan (especially for
> the Junos line of products), and I'm not looking to flame the product
> for nothing.
> On Jul 22, 2010, at 9:49 PM, Chris Whyte wrote:
>>> IMO Juniper has royally screwed up in the small router/CPE market.
>>> One can hope that they won't perform similar stunts on the M/MX/T
>> There's absolutely no reason why this would be considered. The fact
>> that you
>> would make that statement leads me to believe that people might not
>> understand why the SRX product line was created in the first place.
>> The entire SRX product line (branch and high-end) covers the
>> spectrum across M and MX series but were created specifically as
>> purpose-built security devices and therefore should be implemented
>> as such.
>> In addition, in order to do high-end processing of (stateful) flows
>> you need
>> dedicated and specific hw to achieve desired performance. That hw
>> exist on MX and T series. It only exists on high-end SRX (ie SPUs).
>> Thanks, Chris
>> juniper-nsp mailing list juniper-nsp at puck.nether.net
juniper-nsp mailing list juniper-nsp at puck.nether.net
More information about the juniper-nsp