Want some examples why NSM is a piece of junk?

[cryptochrome]

We are still unhappy with NSM 2011. Even with the major bug fix release 2011.1s1, which really helped, the main concerns are still there. Juniper have released 2011.4 a couple of weeks ago, which we haven't tried yet. It seems to be just another name for the 2011.1s1 release (judging from the release notes). NSM will never be a good product. Even if you fix all the bugs and make it much faster, it's architecture is fundamentally flawed. It used to be ok back in the days where you would only use it to manage Netscreen devices, but it's just not up to the task of managing all the new device types they added over the years. It just wasn't built for Junos. In my opinion, trying to make NSM the management tool for basically the whole security product portfolio was a bad decision. One that can not be fixed. It's done. Only hope is the new Space product.

[tbehrens]

I think you'll find Juniper agrees with you. SPACE is where all new development will take place. NSM is receiving stability releases to tide customers over until SPACE is fully ready in the security arena.

[tbehrens]

@kbfan: Is there word on what the "stability release" post 2010.3r2 is? I see 2011.1s3, and it seems that 2011.1 is getting all the bugfixes with regards to SRX management. 2011.4 is out, but hasn't received the same kind of attention.

Are both of these still to be considered interim?

[cryptochrome]

"me too". What's the difference between the rollup 2011.1s1 release and the new 2011.4? Does 2011.4 contain the same bug fixes as in 2011.1s1 plus new features? Or is this just a completely different branch? Confused!

[Randy Harrison]

2010.3s1 was the first "stability release" that was to focus on stability without adding new features.

2011.4s1 is the second "stability release" and also adds the features that came after 2010.3.  (2010.4, 2011.1 features)

2011.4s1 can be considered a "rollup" release.

2011.1s1 was not considered a "rollup" patch but an incremental patch based on the bugs that had been found in 2011.1.

2011.4s1 was released yesterday.

[cryptochrome]

Thanks Randy, much appreciated. So it's safe to say 2011.4s1 is the holy grail everyone should be upgrading to? Or is 2010.3 still the recommended release for IDP systems and 2011.x for everything else (one of my customers runs two NSM systems because of that...). Also, do the release notes of 2011.4s1 cover everything in terms of what's been fixed and added since 2010.3 or should one go through all the release notes incrementally to get to know about it all? (if it's the latter I am going to have to take a day off I guess ). Thanks Sascha

[cryptochrome]

Reading through the release notes of 2011.4s1. Juniper, are you serious? 

Example:

The following features added in Junos OS 11.2 Release are not supported in NSM 2011.4
Release:
• Global Address Object
• Global Policy
• Nested Address-Set

 Junos 11.2 was released over a year ago and you STILL do not support ESSENTIAL firewall features like these?

At the same time, you announce the addition of new features in 2011.4s1:

Starting from 2011.4s1 release, NSM supports WXC Series devices. The WXC Series
device can be added to NSM using the Web UI workflow (under the Device Manager).

This is hilarious. What exactly are your priorities here?

How about fixing broken features and completing incomplete features before implementing even more new features and devices?

[tbehrens]

Thank you, Randy. It's good to see stability work on NSM while SPACE matures.

In my environment(s), I still have my customers on 10.4r8/9, and will stay there until JTAC recommends 11.4. Luckily, I don't have any Checkpoint conversions, which means global policy is not important to me. Global address book and nested address sets are nice-to-haves, but not essential. Also not available on 10.4, which makes it easy to dismiss them with a flick of the wrist.

That tune may change when customers start using 11.4 and expect these features to work at that time. Let's see where we are Q3.

[Edit] Crypto, I understand your frustration. You are stuck between an NSM that works so-so, and SPACE which isn't useable yet. At the same time, you are calling for features - support of SRX features you care about - and blast Juniper for adding a feature, instead of focusing on stability.

What I see in the NSM work that Juniper is doing is an almost exclusive focus on stability, deliberately not introducing major new features such as the ones you are asking for, or support for AppSecure.

Whether that will continue this way I do not know. I do know I'd prefer all feature work to flow into SPACE, and for NSM to receive stability work for the most part, which is what appears to be happening right now.

[cryptochrome]

---

tbehrens wrote:

[Edit] Crypto, I understand your frustration. You are stuck between an NSM that works so-so, and SPACE which isn't useable yet. At the same time, you are calling for features - support of SRX features you care about - and blast Juniper for adding a feature, instead of focusing on stability.

What I see in the NSM work that Juniper is doing is an almost exclusive focus on stability, deliberately not introducing major new features such as the ones you are asking for, or support for AppSecure.

---

Well as I said earlier, NSM 2011.4s1 saw major new features. They added the ability to manage a whole new class of devices. While managing older devices (SRX) is incomplete. That's where my frustration sits.

[vencour]

I have 3 unresolved issues with NSM and SRX ... if can someone else check and confirm this behavior ... ?

1. if I use any-ipv4 as source-address or destination-address, NSM does not recognize this parameter. And if I do update from NSM, then relevant security policies are deleted from SRX ...

2. I use apply-groups for logging in security policies  ... 

groups {
  global_policy_and_logging {
        security {
            policies {
                from-zone <*> to-zone <*> {
                    policy global-permit-ping {
                        match {
                            source-address any-ipv4;
                            destination-address any-ipv4;
                            application junos-ping;
                        }
                        then {
                            permit;
                            inactive: log {
                                session-init;
                            }
                        }
                    }
                    policy global-deny-policy {
                        match {
                            source-address any-ipv4;
                            destination-address any-ipv4;
                            application any;
                        }
                        then {
                            deny;
                            log {
                                session-init;
                            }
                        }
                    }
                }

and when I import such config into NSM and try update SRX from NSM ... NSM does not knows such policies

3. when I have some deactivated zones in config on SRX, import config from SRX and update config from NSM back, then NSM gets again some error ...

Error Code:

Error Text:
   Update fails UpdateDevice Results
sanityCheckCmd Success.
lock Success.
GenerateEditConfig Success.
confirmedCommit Failed .
<?xml version="1.0" encoding="UTF-8" ? >
<commit-results xmlns="urn:ietf : params:xml:ns:netconf:base:1.0" xmlns:junos="http://xml.juniper.net/junos/10.4R8/junos" xmlns:nc="urn:ietf : params:xml:ns:netconf:base:1.0">
   <rpc-error>
      <error-severity>error</error-severity>
      <error-path>[edit security policies]</error-path>

      <error-info>
         <bad-element>from-zone some_specified_zone to-zone some_specified_zone</bad-element>
      </error-info>
      <error-message>mgd: Missing mandatory statement: 'policy'</error-message>
   </rpc-error>

So I deleted apply-groups of security policies (I needed logged all) and deleted all deactivated components and NSM detects no problem ...

 Btw. the problematic security zone is stored in rescue config and nowhere else now

So has someone positive experience on such scenario?

Thanks and best regards

Vencour