08-01-2011 08:48 AM
Seriously. I've had enough of this pile of useless software. There is not a single day that we don't run into issues.
DMI schema updates failing, GUI clients no longer able to connect, NSM allowing to configure options on devices that these devices don't even support.... the list goes on. Today?
1.) Uploaded an unpacked Junos image (i.e. not the .tgz but the .tar file) to NSM. NSM wouldn't complain. It would let me push the update to a device, which takes forever, because that device is a virtual chassis SRX. 45 minutes into the upload I get an error that the file is not the original .tgz and hence the update process will be interrupted. WHY THE HECK would you even let me upload it to NSM in the first place if you can't use it? Why would you push the image to a device and let me wait 45 minutes? Why are there no checks in place? Oh I forgot, it's 2011. No one needs to expect Software to be intelligent nowadays.
2.) So I go ahead, delete the .tar and replace it with a .tgz and start the upgrade process again. This time it goes through and about 60 minutes later my SRX cluster reboots. But wait... only one node was upgraded, the other one is still on the old version. WTF? Needless to say my cluster went crazy because different software versions are not supported between cluster members. So I start searching the Juniper KB. Ever tried searching that KB? Well, good luck. After a lot of searching I found one PDF document (not even a real KB article or release note) that had one sentence buried deep inside of it. It said software upgrades through NSM are not supported on SRX if you manage them in virtual chassis mode. ARE YOU KIDDING ME? If it's not supported, then why would you let the stupid admin even try it?
You know, just because I am in such a good mood today, I won't say screw you Juniper and I won't say screw you NSM.
What a piece of crap.
08-01-2011 10:45 AM
- You can't manage anything locally and have it sync up to NSM
- If a device goes out of sync, the only way to make it say in-sync is to re-push the latest configs, even though there is no change.
- No tacacs authentication for NSM
- Java Client, there is nothing in here that requires more than a web front end.
- Logging utility is a waste
- API is weak
- No way to just manage the policy
08-01-2011 03:07 PM
[Keith pulls on asbestos coveralls...]
Appreciate the candid feedback and I can only guess at the frustrating prior history that must accompany it.. Apologies for that. We are acutely aware of some longstanding challenges with the platform. I'll see what we can do to help others in the situation you describe.
Some good news - we've got an alternate search for you to try (which includes KB content) - see if http://www.juniper.net/ExternalSearch/search?local
For any further feedback or comments, please post the version you're running.
08-01-2011 05:08 PM
Ooooh, oooh! I've got some!
- Let's say you have 150 address objects configured and need to delete them all, for example, an old IP subnet is retired. There is no way to select all 150 objects and say "delete." Since addresses are horrifically organized in the tree, and you can't select multiple items in the table layout, you're left with "Search -> Global Search" You can't search on IP for a network or range of addresses, for example, I can't enter 192.168.10.0 / 24 to get all address objects (that are typically defined as /32). It will ONLY search for the EXACT match of the network /24 object. Failure. If you happen to name your address objects with their IP address, as I do (luckily), then you can do a name search for the string 192.168.10, and and get the 150 results in the results window under the "address" category. Great, now I have all 150 results. I still can't select them all, or even more than one, and say "delete." I have to click each one, click delete, wait for the thing to find the references, then confirm I want it deleted. Lather, rinse, repeat. I'm somewhere around 600 mouse clicks to delete 150 address objects. That's not even counting the time wasted waiting for NSM to find references and then apply the actual delete every single time. It's a good 15-30 seconds wasted per delete operation. That adds up to a lot of sitting and staring at the screen.
- Let's say you have an address group, and you want to add some new addresses to it. You can't open the group and say "new address" from there and have it show up as a group member. You can't bulk create new addresses. You have to create an address object first, which is around 6 mouse clicks and entering the information. Once it's created, now you have to open your group. If you're lucky, it's visible. If not, you have to search for it by scrolling or doing a inline text search. Then you open your group (two clicks), then you have to scroll through the non-member addresses and find the new address you created. Now, you *can* select multiple items here (three cheers for consistency!), so at least it's not wasting that many mouse clicks for every single address.
By comparison, Cisco's ASDM is not exactly a shiny gem of awesome, either, but these two things are handled MUCH more efficiently and have a MUCH better workflow.
- Schema updates require me to enter my Juniper Support login credentials into NSM so it can log in as me to download the schema updates. Um, what? This is from a *security company,* mind you. We have 5 people who have admin rights in NSM, I'm not real thrilled with the idea of having *my* login credentials stored in the software configuration where 4 other people have access to it. I'm not sure if the login information is stored in client preferences or in the server configuration, but it shouldn't be required in the first place. Is there some compelling reason why NSM can't identify itself to Juniper's servers as a licensed version of NSM, rather than as *me*? NSM can download attack database / IDP updates without my login, why can't it download schema updates?
- Why can't NSM download software images from Juniper? Why do I have to download an image, save it to my local system, then go into NSM and import/upload it into the software manager?
Those are just a few of my major gripes right now.
NSM is honestly one of the most horrible, ridiculously poorly-designed, worst-written pieces of software I have ever seen. I really believe that the folks at Juniper who oversee / develop NSM have never actually had to use it to manage firewalls.
If this solves your problem, please mark this post as "Accepted Solution."
Kudos are always appreciated.
08-02-2011 01:40 AM
Here's my comments to this thread.
Years back when i started using NSM i was exited about it's funtionality. I think it was a good and fairly stable platform for managing firewalls, and with more firewall administrators i gave a good overlook of which changes had been made for the firewalls we manage.
Unfortunately over the last years I feel that the quality has decreased.
My feeling is thas as effort was made to integrate the management of the JUNOS-based productline, the developers forgot that there still was users who were using "legacy"(ScreenOS) platforms.
At the same time the support for JUNOS was pushed forward in a way that the integration was poorly programmed.
The result today is that us(The customers) is left behind with a very unstable product.
Maybe it would have been better if Juiper had made the decision that all support for JUNOS would be made in a new product(SPACE), and then when the time comes to retire ScreenOS then NSM would also be retired.
If this worked for you then please flag my post as an "Accepted Solution" so others can benefit from it. A kudo would be nice if you think I earned it
08-03-2011 04:31 AM
Some good news - we've got an alternate search for you to try (which includes KB content) - see if http://www.juniper.net/ExternalSearch/search?local
e=us_en works any better for you.
So that's your good news after a complaint like this? You offer an alternative search method for the KB? The problem here is not the KB, the problem is NSM. Fix that. There are simply no excuses for what your customers who have bought into NSM have to deal with.
08-03-2011 04:45 AM
So here are some more "joyful" examples:
- NSM does not automatically recognize when a SRX firewall has changed on the device (e.g. someone altered the config through CLI or shut the system down). Even with a shut down firewall NSM keeps hapiliy reporting that the firewall is up and in sync. WHAT?
- When deleting objects or devices in NSM, sometimes it doesn't properly clean up and leaves trails behind in the XDB database. You can't see those trails with the GUI, but you might get a problem if you try to delete an object that has had some sort of reference to one of the deleted objects that NSM didn't clean out. The GUI will give you a generic error, simply saying it can't delete and tells you to go search the error logs. Thanks, I can do that. Eventually you have to use commandline tools (xdbedit) to get rid of the old references. Make sure you got some spare time for that, as it might take a lot of time.
- I have had three completely different NSM installations (all different customers) get completely messed up just by applying a schema updates. Turns out Juniper forgot (yes) to make sure their upgrade scripts change the heap size settings in some file. That heap size needs to be increased because of the ever growing schema updates. If the heap size is not changed and you install a schema update that's too large, your NSM won't load anymore. It can't load the schema and will be completely unusable. That not being enough, they had the same issue with the GUI client, which also needed that heap size adjustment. So if you updated schema on NSM and download that to a client that wasn't changed, the GUI client runs into all sorts of issues.
THE BIGGEST PROBLEM with all of this however is that this stuff is mostly still not fixed, and they don't warn their customers anywhere about the problems they might run into. Try this: Upgrade NSM 2007 to 2009 and then to 2010 or 2011. Then do a schema update. I guarantuee you will run into the issue I described.
Now a couple of days ago they updated one of my JTAC cases I had opened about this to tell me they had released a patch release that would fix the issue. But they only tell me and probably those who had a ticket open for this issue. Go to their website and you will see nothing about it. They let their customers run into open fire. I call this lack of communication.
This issue needs escalation inside Juniper. Some people need to start doing their homework. Now.
08-03-2011 08:08 AM - edited 08-03-2011 08:11 AM
@cryptochrome - KB search regarding the issue you encountered was _one_ complaint - should I ignore that? As you later point out, making sure the issues are known is an important part of moderating customer impact.
I have made sure this thread has executive visibility. Opening a case with JTAC is the proper course of action to resolve specific issues.
REMINDER - Please post your running version -- *ALL* sw issues are version dependent! Complaints/comments without versions (NSM/Junos) are not actionable by us or useful to others.
cryptochrome wroteSo that's your good news after a complaint like this? You offer an alternative search method for the KB? The problem here is not the KB, the problem is NSM. Fix that. There are simply no excuses for what your customers who have bought into NSM have to deal with.
08-03-2011 08:27 AM
Keith, all issues I ever encountered have a corresponding JTAC case. Actually one of those cases resulted in a fix/patch release of NSM. So Juniper does listen, I have to give you that.
However, this discussion thread is not about one particular issue, it's about the overall situation with NSM. So version numbers do not matter here. And I personally no longer think that opening JTAC cases is the only proper course of action. Because what happens? They resolve your issue (maybe) and then it vanishes in the dark. No other customer will benefit from this (see my previous notes that customers still aren't warned about possible issues with DMI schema updates).
Juniper needs to wake up. If you really managed to get executive attention to this thread, I appreciate that. I just hope that it will have some serious impact.
08-04-2011 04:33 AM
I've the same problems as the other poeple complains. Espacially adding a new object in one group.
I can add the followings things:
- Completly misleading predifined objects dedicated to Junos / screenos.
- Why can't we simply enable Junos / Screenos feature into NSM
- NSM is incredibly slow! Add a object, wait. Add object in group, wait. Browse ruleset, wait wait wait. Create the rules with objects, wait. Save the ruleset wait wait wait....... Awfull Note that I use an I7 quadcore with 8Gb of ram as UI client. .
- I buy the new "high perfromance" NSM 3000. Do some test and want to do a factory reset. I run into a bug with raid controller. Ok it exists a KB. But this bug is known and I you just do a factory rest of your box, the bug appear. Juniper really tests his NSM product?
- When you delete objects, it make exceptions, causing you top open one more time a JTAC case because your DB is corrupted.....
I'm really disapointed by this product that cause us lot of trouble and give a poor image of Juniper.
08-04-2011 09:09 AM
The best thing would be to upgrade to NSM 2011.1 with the latest schema and see where things stand for you. It's not going to introduce major functional changes like object management (bulk deletes etc) but it is now managing JunOS devices almost as well as ScreenOS based devices. There are still a quirks but they are minor annoyances rather than major problems that we saw with the NSM releases 2009-2010.
For performance, higher spec hardware does help - especially as logging and device counts increase. If you are on the appliance, it could help by moving the logging onto a mounted external storage array. If you are on the software version, move logging onto an external storage array and allocate 4-8 processor cores to NSM. (hyperthreading should be off).
08-06-2011 02:16 AM
So with the last couple of NSM/SRX integrations I found out that NSM would not recognize if a SRX had changed (e.g. changed config through Junos CLI or device being shut down). So I checked with JTAC and they told me this is normal. Say what? MY device monitoring feature doesn't actually monitor the devices? I can have a major breakdown in my datacenter that causes my SRXs to disappear from the network and NSM wouldn't even see that, and instead tell me the devices are up and in sync?
JTAC say it's normal. NSM can't detect device changes on SRX. Yes folks, that's right.
What's with all this Junos automation power? Why not simply poll the device status at regular intervals?
Are you serious?
08-06-2011 07:39 AM
We will validate whether that is WAD (working as designed). I'm not sure it is since it appears JTAC was unable to reproduce the issue you reported. If it is the case then clearly we need to caveat the documentation better to indicate this.
08-07-2011 11:45 AM
08-12-2011 06:35 AM
08-15-2011 11:25 PM
08-16-2011 12:25 PM - edited 08-16-2011 12:25 PM
Patience is a virtue...
The product team is working on an update I'll post here detailing the "get well" plan for the issues described here and elsewhere. Should have something in a week or so.
08-17-2011 04:08 PM
Here's the update from the product team.
"We acknowledge that NSM management for Junos devices has had some challenges. Juniper is committed to delivering quality products to our customers, and we are working on two focused programs to alleviate these concerns. The first program includes a significant engineering investment to improve the quality of NSM. To that end, there will be two NSM releases this year, one targeting NSM 2010.x customers and one for 2011.x customers. These releases will contain bug fixes, targeted improvements for improving stability and performance, as well as extensive testing. The second program will deliver a security management solution called Security Design that runs on our Junos Space platform. This will provide a transition path for NSM customers and will serve as Juniper’s long-term security management platform."
08-21-2011 09:37 AM
Thank you Keith.
Is there any information available for Space's "Security Design" yet? Is that an existing product?
As for the NSM updates that are supposed to significantly improve stability and performance, are there any ETA dates on when to expect these releases?