09-15-2010 06:09 PM
I did not say that the customer prefers a SSG over a SRX means that the SSG has more features and is more stable.
I said that the customer is happy now with SSG because he saw SRX cluster instability in 9.6 and 10.0. What should I say to the customer? "Oh, I'm sorry, but lets wait until Juniper solves this cluster problem" if SSG clustering works very well!!!
And talking about features, how can i implement link failover in a SRX cluster? Using a f!@#%$%¨$% JUNOS script???
C'mon, with SSG I can implement link failover in just one minute!!!
Sincerely, as a Juniper partner, we are very disappointed with SRX family.
09-16-2010 07:54 AM - edited 09-16-2010 08:26 AM
Update from two months ago, I am a customer with Government. We have many SSG and ISG firewalls all managed by NSM (which works very well). After over 4 months with juniper tech support and over 2200 minutes logged on phone calls to juniper we gave up. Juniper acknowledged that the problems cannot be resolved between NSM and SRX and clustering SRX. To junipers credit they gave us two SSG320m and two 8 port gig modules. In the future Juniper will be releasing a new product to replace NSM, it is suppose to be able to manage both netscreen and junos product lines. Netscreen does everything we need, I hope Juniper will provide a long support time for the SSG & ISG products I have but nothing lasts forever. We were a Check Point shop before Juniper and we may have to go back if the netscreen line ends. The Junos OS appears to have much more flexibility however we are not the CIA, NSA or any other super security type of department. Netscreen provides the basics we need; firewall, VPN and DMZ zones all with good logging, keep it simple Juniper.
09-16-2010 08:47 PM
I completely agree. I cannot see the point in beta testing the SRX's for juniper when the SSG range does everything I want and takes like 25% of the time to setup.
I do like JunOS, and if they were to fix some of the major issues I would have no problems using them. But I run a small IT business and don't have time to deal with **bleep**ty products that require me to log a support ticket for every issue.
My main concern is the stability of the devices. I have a couple of SRX210s for testing and I still find that PPPoE is unreliable. It seems whenever the connection drops for whatever reason the Juniper doesn't reset the sessions or connections properly and nothing routes. Normally a "restart routing" fixes it.
I logged a support ticket about it many months ago, Juniper logged into the device and where unable to see anything wrong. I have tried ever different configuration I can think of (and external modem, mini-pim module etc). I would have spent probably 50 hours looking at it. I was still having this issue in 10.1r2. I've just upgraded to 10.2r2, so we'll see how that goes.
The device also takes soooo long to upgrade compared to the SSG range. This is mainly because the SSG was a nice small firmware package. While JunOS is this massive BSD operating system that takes up heaps more space. The SRX can still take 10 minutes to boot up and finally see the ADSL module.
No local IP pools makes setting up VPNs even slower.
The web interface is like 100 times worse than the SSG interface. Crappy slow AJAX style thing that looks like a 12 year old designed it. Fix it now, it is unusable even in 10.2.
I really don't know what else to say. It is nice to finally have some flow IPv6 in 10.2, but the SSG did that too!!!
I think Juniper should have left the SRX branch devices for another generation.
For example an SSG 5 with Gig would be awesome. I also like the wireless options the SSG5 & 20 had. Now you need to buy yet another box.
Juniper seriously you guys need to do some major work on the lower end SRX devices before anyone would want to use them.
09-17-2010 02:21 AM
>>>>>>>>>>>>>>>>>>>>>My main concern is the stability of the devices. I have a couple of SRX210s for testing and I still find that PPPoE is unreliable. It seems whenever the connection drops for whatever reason the Juniper doesn't reset the sessions or connections properly and nothing routes. Normally a "restart routing" fixes it.
Can you pls try to configure the "set interfaces pp0 unit 0 pppoe-options auto-reconnect 120" in CLI and pls check whether PPP automatically reconnects without restarting of routing.
Your input is very important for us to understand in details.
09-17-2010 03:21 AM
Thanks for the reply. It is currently set to
I can try changing it.
The interface comes up and has an IP address, I can even ping the ISP default gateway but nothing else.
09-17-2010 04:06 AM
regarding pppoe, does it work sometimes or did it never work ?
(ie nothing can be reached except the other end of the ppp).
do you try to ping from the srx itself or from a device in the lan ?
09-17-2010 06:17 AM
Oh no it works *most* of the time but if there is ever an ISP issue or something and the PPPoE connection drops, once it reconnects you can only ping the ISP gateway on the SRX. Nothing else.
Sometimes you can ping the ISP gateway from the LAN, which is odd. But a restart routing fixes it and I didn't have the issue with my SSG5.
09-27-2010 08:38 AM
My main concern is the stability of the devices. I have a couple of SRX210s for testing and I still find that PPPoE is unreliable.
I was still having this issue in 10.1r2. I've just upgraded to 10.2r2, so we'll see how that goes.
Did upgrading to 10.2r2 help with PPPoE stability? I'm looking at the SRX line to help consolidate (e.g. remove) a tier of Cisco ISR routers doing nothing but PPPoE emulation. If the SRX cannot perform this function, that would be a huge problem for us.
10-17-2010 08:33 AM
Around Aug 14 I had posted our issues on a pair of SRX 650's and SRX 3600's, used
at the University of Waterloo, for main campus wireless NAT, and data centre firewall.,
The pair of 650's have been problem free since about April 27, after upgrade to 10.0R3.10.
The pair of 3600's have been essentially problem free since about Aug 19, after upgrade to 10.0R3.10
We use stateful firewall and/or NAT features only.
I say "essentially" for the data centre firewall, as we twice we cannot figure out protocol/timeout
issues between specific clients/servers where traffic passes through firewall. e.g. we set "allow all" in both
directions, set timeouts to infinite or very long, turn off strict tcp checks, and still issues, until we
move host outside firewall, or move everything to same side of firewall. Wireshark will show tcp
session breaking and re-establishing. But hundreds of other servers, and thousands of services working fine.
One such issue appears to be Microsoft RPC, we've been advises there is protocol awareness in a later
version. We just moved hosts as we don't want to upgrade right now. Another issue was Hirsch door
controllers, we never opened a case, and moved host.
What might help is something like Cisco ASA "TCP Bypass" which I understand to blindly
forward traffic with no protocol, sequence, or any other checks, when configured. This could
help immensely to prove/disprove firewall is issue when needed.
10-26-2010 01:58 PM
Regarding Cisco ASA "TCP Bypass," couldn't you use packet-based processing instead of flow-based processing?
I've never used it or needed it myself, but it sounds like what you're looking for?
10-27-2010 01:58 PM
fwiw, in our testing, JunOS 10.2r3 works well w/ MSRPC applications such as Exchange and AD replication. JunOS 10.3r2 has been promised to have the same stability. As none of the features in 10.3 are all that compelling to us, we're sticking with 10.2r3 as the "go to" release for now, and we'll likely move to 10.4rx (1 or 2 depending on how brave we feel ) as the next "go to" release when that has been released.
It's not been all that long for 10.2r3. So far, it's been stable. 10.2r2 was stable w/ regards to clustering, it just had some massive ALG issues and an annoying memory leak in web filtering.