SSG vs. SRX

[SomeITGuy]

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.

[BruceCampbell]

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

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

Technical Support

Closed

2009-1222-0542 IpSec phase 1 not renegotiating / Improper Timers?

UNIVERSITY OF WATERLOO (1-75Z-80)

BruceCampbell

2/17/2010 0:53:5

Support

4 - Low

[SomeITGuy]

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!

[Hedia]

Hello,

Same conclusion for me !

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

Bye

Hedi

[CrytpoManiac]

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.

[Gorf]

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. 

[mwdmeyer]

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.

[Hedia]

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]

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.

[mawr]

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