03-03-2011 11:03 AM
Here is some good news for a change
NSM2011.1 is being published on the website right now and so far it seems pretty good. Hidden in the release notes you'll see this interesting new feature: "Receiving data plane sd-syslog messages from DMI devices using stream mode"
Yes, thats right.. pushing logs from SRX to NSM directly from the forwarding plane instead of sending it through the routing engine and crashing the device under load.
It does require a change to the devSvr config, but thats explained in the admin guide. From my initial testing the logs do need to be sent from the same source-ip which is used by NSM to manage the device, which is a bit strange for clusters and you may need to run Junos 10.2 for the logs to be parsed properly. Neither are documented yet though, just my experience.
Another interesting change is they seem to have rolled back the change that caused 2010.2 to push policy names to SRX instead of the unique policy IDs. I didn't see this in the release notes but thats a fantastic change as well as it makes the upgrade path from pre-2010.2 releases easier. One less major change to worry about.
This is also the first release that managed to import my entire SRX config without problems. I haven't done any extensive testing yet but so far its looking pretty good. The only thing I found is that they messed up the implementation of "permit uac-policy captive-portal redirect", but that won't affect all that many people.
03-14-2011 05:51 AM
Thank for the update , I would have not seen this feature without your post.
Could you tell me how many logs you receive on your NSM / days ( adverage ) ? I m also curious to know if this option has improved the SRX/NSM/admin UI performance & stability.
03-14-2011 12:49 PM
I started with a small cluster that only generates about 10 logs/second on average. The large clusters are next, but not done yet. We did however experiment with stream logging to other targets before and that was a lot more stable as suddenly the RE had a lot more resources available. The commits were faster as well.
The NSM ui is still the same as before, its never been fast and requires a huge amount of RAM. But from what I heared it is no longer required to update the NSM.lax file manually when installing the newer schema versions. It should automatically increase the memory reservations, but I haven't verified that yet.