SRX Services Gateway
Reply
Trusted Contributor
SomeITGuy
Posts: 330
Registered: ‎01-08-2010
0

Re: SSG vs. SRX

I am hopeing that with the number of serious crashes you have had that you have opened a case with juniper and have uploaded your crash dump files so they can debug them or give you an internal fix if the dump matches a known issue.

 

Visitor
BruceCampbell
Posts: 3
Registered: ‎08-14-2010
0

Re: SSG vs. SRX

 

yes, cases below.  Also please note the one crash April 3 of SRX 650 was our configuration error afterall.

 

 

Technical SupportOpen2010-0728-0203
in-service upgrade unable to complete, cluster not active
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell8/12/2010 5:0:54Support4 - Low
Technical SupportClosed2010-0608-0227
Device Crash
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell7/6/2010 1:13:55Support4 - Low
Technical SupportClosed2010-0518-0576
flows using wrong interface, sometimes...
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell6/4/2010 16:30:15Support3 - Medium
Technical SupportClosed2010-0428-0412
IP Redirects
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell4/29/2010 8:24:33Support3 - Medium
Technical SupportClosed2010-0405-0087
OSPF ABR Routing Issues
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell5/23/2010 23:45:29Support2 - High
Technical SupportClosed2010-0311-0579
Cluster failing
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell8/3/2010 7:31:12Support2 - High
Technical SupportClosed2010-0127-0258
Unable to upgrade firmware on SRX-3600
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell2/17/2010 0:53:5Support4 - Low
Technical SupportClosed2010-0118-0159
DHCP request TTL of 1
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell3/4/2010 10:51:3Support4 - Low
Technical SupportClosed2010-0111-0718
Attempted downgrade leaves SRX210H with u-boot errors.
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell2/17/2010 0:53:5Support4 - Low
Technical SupportClosed2010-0106-0197
Upgrade failed
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell2/17/2010 0:53:5Support4 - Low

Technical SupportClosed2009-1222-0542
IpSec phase 1 not renegotiating / Improper Timers?
UNIVERSITY OF WATERLOO (1-75Z-80)BruceCampbell2/17/2010 0:53:5Support4 - Low
Bruce Campbell
Director, Network Services
Information Systems and Technology
MC 1018
(519)888-4567 x38323
University of Waterloo, Waterloo, ON
Trusted Contributor
SomeITGuy
Posts: 330
Registered: ‎01-08-2010
0

Re: SSG vs. SRX

It seems to be that the ScreenOS platform is a proven platform with years of stability improvments..

 

The SRX platform on JUNOS is new, fragile and honestly I am hard pressed to see advantages anymore..

 

My latest issue came with just how much easier it is to do QoS tasks in ScreenOS.. In ScreenOS you can juse add a DSCP tag to your policy and all traffic that hits it is tagged... The only ways to do tagging in the SRX at the moment are firewall filters, or licencing IDP to due it in an IDP rule.. Policies in ScreenOS seem much more powerfull than JUNOS and at no extra cost as they are base funtionality..

 

The NEW UTM features that are not available in low end ScreenOS devices, just DO NOT WORK in the SRX... It seems proven again and again that if you enable UTM features you will have stablity problems. Hell even my SRX boxes running NO UTM have had flowd core on them...

 

I could not and will not recommend the SRX plaform to anyone... it is a shame since we LOVED the ScreenOS platform for years!

Contributor
Hedia
Posts: 93
Registered: ‎05-28-2008
0

Re: SSG vs. SRX

Hello,

 

Same conclusion for me !

Move to Fortinet and Sonicwall for firewall that need UTM features...

 

Bye

 

Hedi

Contributor
CrytpoManiac
Posts: 16
Registered: ‎05-20-2009
0

Re: SSG vs. SRX

Regarding the quote:


John_Burns wrote:

 

have a partner at work who also is an engineer, his only experience with Juniper prior to the SRX platform was netscreen ISG and SSG firewalls. He continues to complain about why he has to use the cli and he goes behind me and turns the GUI back on. I guess this is normal for a lot of firewall admins, bad people trained in the checkpoint / netscreen ways of doing things....  If you are hiding behind a GUI you are not proficient with the product, plain and simple. The GUI shields you from what is happening on the box, in some cases it even prevents you from understanding the true flow of traffic and how the devices logically process traffic and rules. 

 


 

First, I'm not sure Checkpoint/Netscreen-trained firewall admins are bad people ;-)

 

Secondly, I'm in the exact opposition situation as you: I'm a security manager trying to teach Juniper to Cisco poeple who live and die by the CLI. For the record, our IOS guys are not impressed with JunOS for a variety of reasons... Mostly due to extremely "long-winded" or verbose JunOS commands and general instabilities.

 

The bottom line with CLI vs GUI isthat  the two should compliment each other. It's not "one or the other." The two lived in perfect harmony in ScreenOS platforms. On Netscreens, I can easily look at a massive policy that's nicely color-coded in the GUI, or use the CLI for troubleshooting, searching for policy elements, etc. I used both on a regular basis.

 

I agree the J-web on SRX platorms is not up to par. However, I'm not going to manage dozens of firewalls individually via the CLI either. Again, I depend on the GUI (NSM) to help automate policy updates and foster object re-use. It's not a preference, but rather a requirement for efficiency within an organization that runs on very thin staffing levels.

 

 

Contributor
Gorf
Posts: 43
Registered: ‎08-04-2010
0

Re: SSG vs. SRX

Would have been nice to see this thread before throwing away $20K.  These SRX650's have been a nightmare to use.  And frankly whoever wrote most of the documentation needs to be beaten with a blunt stick. 

 

We've been at our migration to these SRX650's now for almost 3 months and I can say without a doubt that this has been one of the worst migrations I have ever done.  The sheer over complexity associated with doing things in Junos just bogles my mind.  8 commands to make a destination nat??  The logical flow behind how to do things is insane.  I've used other closed and open-souce products that are infinitely more simple and intuitive to setup. 

Trusted Contributor
mwdmeyer
Posts: 179
Registered: ‎03-11-2008
0

Re: SSG vs. SRX

We still haven't started selling the SRX range to customers yet because of all the issues.

 

I'm very seriously thinking about ditching Juniper completely, the SRX range has been the most unreliable platform I have used in a long time.

 

I like the idea of running JunOS on branch devices but not when it is so unstable and feature limited compared to the SSGs.

Contributor
Hedia
Posts: 93
Registered: ‎05-28-2008
0

Re: SSG vs. SRX

Hi all,

 

I'm also very disappointed with SRX.

Does anybody has already ask to Juniper to replace the SRX with SSG because the SRX simply does NOT WORK properly.

I have implemented two cluster of SRX 240 (with ton of problems) and the customer ask me if it's possible to swap them with two clusters of SSG 140 (even if I loose IDP features).

 

Regards,

 

Hedi

pkc
Contributor
pkc
Posts: 111
Registered: ‎09-24-2008
0

Re: SSG vs. SRX

I'd suggest to compile the screenos code for srx branch office devices,

and let you choose at boot time which os to run,

so you can wait until srx for branch is at the same level.

Trusted Contributor
mawr
Posts: 236
Registered: ‎06-11-2010

Re: SSG vs. SRX

[ Edited ]

In my opinion this discussion needs to shift from referencing the SRX family as a whole to discussing specific builds of the JUNOS-ES software for it.  Saying that a you or a client had problems doesn't seem fair since even inside of this year there have been tremendous improvements between 10.0 and 10.2, for example.  If you're having problems with an SRX, and using old code, I'd strongly encourage upgrading to the most recent 10.2 and 10.3 code before drawing any conclusions for the near future.

 

mawr

Copyright© 1999-2013 Juniper Networks, Inc. All rights reserved.