06-07-2012 11:41 PM - edited 06-07-2012 11:50 PM
My feedback so far on Security Design (and only that, I am not speaking about the whole Space platform) is this: It's a huge step forward. The interface is so much better than NSM. It's fast, it's easy, it's less complex, it's modern. It has a fantastic search engine built in (think Google for your address object, firewall rules etc.). People knowing other firewall management systems will feel right at home. It has some very nice features.
I immediately fell in love with the object merger, which finds duplicates and offers you to merge them into a single object. This is great for "housekeeping". I also like the fact that you can export and import objects in CSV format, which is great for bulk operations. Automatic device re-sync is another feature I noticed. If you enable that, it will automatically re-import devices that you have configured out-of-band (e.. through CLI). No more competing configs!
It's those little details that give you the impression that Juniper have done their homework.
Security Design has an option to import your NSM configuration. I tried it and it worked really good. Do a database export on NSM, import the resulting xdiff file into Space and voila, you have all your objects and firewall policies. Really well done.
The fact that the user interface is basically HTML doesn't feel like a drawback. The interface is quick, even on 500+ rule policies. I am not a web expert, but I guess they are using things like AJAX or HTML5. You do have right-click context menus everywhere. The only thing that is missing compared to a native GUI client is drag and drop support. Maybe that's coming at a later date, who knows (and it never really worked in NSM anyways).
Note that these observations were made in a lab and not in a production environment. I can't say much about actual device management, although the process of pushing firewall and NAT policies to devices seemed straight forward.
There are a couple of things that I am missing though:
Space does not have a logging module, which is a huge drawback in my eyes. People with high end SRXes are probably logging to STRM or something else anyways, but as usual, Juniper does not seem to have the small to mid-size business in mind who have limited ressources and need an integrated solution. In my eyes, that's something Juniper really needs to address. Sooner than later.
The other thing I didn't quite like was the fact that you can not manage "legacy" firewalls, e.g. ScreenOS (SSGs). There is a huge SSG install base out there and those devices are left in the dust. I really don't understand that move, given the fact that at least in Space 11.2 there was a ScreenOS adapter which let you manage those beloved "netscreens". I hope Juniper will allow this in future updates (the DMI schema repository in Space 12.1 still lists ScreenOS 6.3 so who knows....). ScreenOS support would also mean that migrations from ScreenOS to Junos could be made easier.
One other thing I believe needs improvement is device configuration outside of Security Design. If you open a device in Space you are basically presented with a raw XML tree of the device configuration. Not very intuitive and very tedious to work with. Need to change the IP address of 15 interfaces? You're in for a bad afternoon. That part basically looks the same as on NSM (although it is much faster in terms of interface resposivness).
Oh and one more little thing. It's really not important, but the design of Space looks a little dated in some areas. For example, you have dashboards wth widgets that you can drag around like windows. The window borders are blown up and use fat gradient colors. This could use some cleanup. Make the whole design less fat, flatten it. But again, this is just eye candy so it's not important.
All in all I can say I am very impressed so far and despite the lack of logging and ScreenOS support, Space SD is a huge step up compared to NSM. In it's current state (12.1) it already has the potential to completely replace NSM if you have a separate logging solution. In other words: I love it so far.
To Juniper: If you will offer some sort of upgrade path for NSM users in terms of "special pricing", I think you can win back a lot of customers. I think NSM users deserve to get an upgrade to Space as in free beer. *hint*.
06-08-2012 10:21 AM
Thanks for the feedback, cryptochrome. Your analysis is helpful, and luckily the drawbacks you mentioned aren't relevant to my installation (no legacy ScreenOS, and logging is taken care of).
06-08-2012 11:53 AM
07-09-2012 08:35 AM
Tried to use the Space 12.1 space-12.1R1.8.ova virtual appliance from VMWare Workstation 6 (on a Windows XP station) ;
when trying to open this .ova from VMWare Workstation, I got the following error message "Failed to query source for information" ;
1) Can this VA run on VMWare Workstation ?
2) any idea about this error message ?
07-09-2012 09:43 AM
07-10-2012 01:45 AM
I installed ovftool 2.1 (from https://my.vmware.com/group/vmware/get-download?do
and converted the "space-12.1R1.8.ova" file to "space-12.1R1.8.vmx" and associated .vmdk successfully, with --lax option
but, when trying to power on the VM from the .vmx, I got the following error :
Invalid configuration file. File "D:VMWARE\VMWare Virtual Appliance\JunosSpace-12.1\space-12.1R1.8.vmx" was created by a VMware product with more features than this version of VMware Workstation and cannot be used with this version of VMware Workstation.
Cannot open configuration file D:\VMWARE\VMWare Virtual Appliance\JunosSpace-12.1\space-12.1R1.8.vmx.
I tried to use ovftool 1.0 instead but got same message as stated previously in this thread :
- Virtual machine has 8,192 megabytes of memory, which is outside the range of 4 to 3,600 megabytes supported on the host. This m
ay be a general limitation of the host software, or specific to the guest OS selected for the virtual machine.
and ovftool v1.0 does not support --lax option, so, can't get rid of it
any idea ?
07-10-2012 01:51 AM