Since my name was mentioned I thought I better post here..
We have been running ScreenOS units for a fair number of years along with NSM, as far as on paper the SRX series appeared to be a clear winner and upgrade path, however our experience has us seriously concerned being long time Netscreen fans.
Here are my pros and cons of migrating from ScreenOS to JUNOS and the SRX platform in general.
Pros:
- Although it is more verbose I really like the syntax and auto complete features in the command line
- True Structured configuration files are consistent and easier to do diffs on as well as copy and past in compared to the list of CLI commands the old files used.
- There are some great configuration life savers for remote management, such as having a rescue config bound to the reset button
- commit features that let the device auto roll back if you loss contact
- the fact that when you edit, you are not editing LIVE, allowing you to check syntax
- Lots of throughput even in the low end units
- our locations are running SRX210 units doing minor filtering and tagging of traffic and haven't given us any issues yet.
Cons:
- Simply not as reliable as ScreenOS
- UN SAFE SYSTEM DEFAULTS if you do not explicitly set a value in your config. IE some session time outs are unlimited and will kill your box if not set, on a screen OS device there is a default of 30 min that it falls back on
- Logging works in a completely different and UN SAFE WAY on an SRX.. IN ScreenOS logs are held in memory and roll over no matter what you set your logging level to. In JUNOS if enable local logging (you must to log to NSM) logs grow on the storage volume, if they grow too large and fill it, services fail and the box stops. The log file limits are enforced on a timer it was 1hr in earlier releases and now is 15min, if you debug or run traffic logging settings there is a very good chance you will fill storage WAY before the timer kicks in and prunes the logs
- NAT is different than ScreenOS and in the SRX it is even different from other JUNOS devices. The documentation is VERY lacking most of what you find is for the J series. The new NAT may be more flexible but at the same time it is more difficult since the documentation is not all there.
- the default MTU for the ST (TUNNEL) interfaces is 9000, this is likely since the boxes support gigabit interfaces but this is a crazy default since you are more likely to need something like 1500 or less when doing tunnels over the internet.
- HA clustering is not reliable....we seem to have discovered a new bug where BOTH nodes die at the same time!
- HA clustering is strange to manage in NSM, you end up with 3 devices a cluster and each node, when you update the cluster you actually see the commands go to both nodes with one, stating it doesn't need the update since it is not the master, compare this with a set of JUNOS switches in a Virtual Chassis and they look like one devices?
- Our Cluster of SRXs have been in production for only about 1 maybe 2 weeks since they where first rolled into production, we keep having to put our ScreenOS firewall back in place as we DISCOVER new issues, this has being going on for about two months!
- Just another little thing.. The rack mount for the SRX 210 is ridiculously expensive...