it doesn't matter two. beta.

Some more NSM joy.

Well, as I mentioned a couple of days ago, there is not a single day that we don’t run into issues on NSM.

So today we import some new SRX firewalls into a freshly installed NSM. Everything is looking good except for… well… NSM does not recognize when the device has changed. So if you log into the SRX and do some config changes directly on the device, NSM will happily keep reporting to you that the device is in sync.

Hours later NSM still tells me the device is up, managed and in sync. But guess what, I had shut down the SRX firewalls. NSM didn’t even notice that.

So no matter what you do to your device, change config, shut it down, drop a bomb on it… NSM will tell you the device is up, running and in sync.

Only way to get NSM to recognize that something has changed is to actually use the “Check Config Sync” option or run a delta config summarize.

So that’s what they call Network & Security Management these days.

Can’t delete objects in Juniper NSM? You’re not alone.

So the other day I wasn’t able to delete some objects (devices and policies) from NSM anymore. When trying to delete it first said there are no references to the object and it’s safe to delete. So I hit “continue” just to receive a generic error message with no real info whatsoever.

Checked the error logs and it turns out those objects did in fact still have some references to objects that didn’t even exist anymore. Looks like NSM isn’t doing a proper cleanup when deleting stuff.

Opened a JTAC case. They invited me to a secure meeting and started hacking through our NSM database using the CLI based xdbedit utility. Took them four hours to get rid of all the references that were still in place.

So. Did this happen the first time? Nope. Happened to me two times before. At different customer sites with different NSM installations.

Go figure.

Juniper NSM schema updates - Problems all over the place

So today I am in the mood of sharing some experience I had the last couple of weeks using Juniper’s NSM. See other posts.

NSM’s DMI schemas have grown ridiculously large lately. Sure. They keep adding all sorts of devices they need to support, and along with that all the different versions of the OS that NSM needs to handle. So an unpacked schema today has several GB of data.

To make NSM support these large DMI schema updates, it needs to adjust some heap space (don’t make me swear I get this right) related to the Java backend of NSM. Turns out that they forgot to handle this in their upgrade scripts. So if you upgrade NSM from an earlier version to a more current version (say you go from 2007 to 2009 to 2011) the heap size value is not touched and left behind by the upgrade script.

Result: Next time you try to update the DMI schema you run into all sorts of issues. One of them is that the GUI client is no longer able to connect to the GUI server, telling you it’s waiting for the server to load the schema. Which never happens (not enough heap memory). Once you get that fixed (make sure you have a couple of hours spare time to get this done), your client is still unable to connect because it turns out the GUI client has similar issues.

The client’s nsm.lax file also has a heap size setting that needs adjustment. So you fix that too. Try to connect… still doesn’t work. Why? Because of the too small heap size, the schema download from the GUI server to the client failed and now you got half a schema on your hard drive that the client can’t interpret. So now all you need to do is manually copy the schema from the GUI server to the client, replacing the failed automatic download. Now you’re done.

Still with me? Having fun? I didn’t.

I’ve seen 3 different installations where this happened.

Fortunately, they seem to have finally fixed this with the patch release 2011.1a10, so they say. I haven’t tried that yet, because upgrading NSM doesn’t seem to be a safe procedure anymore.

You know, I used to be a Juniper advocate but these things really make me think twice before I recommend Juniper products to a client again.

Why Juniper Networks NSM is a piece of junk.

Seriously Juniper. Yes, this is directed at you. 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 about it 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.