When you mention HP and “network management” to most people, they think of OpenView – one of the earliest players in the network management market. Love it or hate it, it was a dominant player in the enterprise network management space. Times change, and it’s moved on – the “OpenView” brand has been phased out, even if it’s still there in most of the commands. The clunky X11-based GUI has been replaced by a not quite so clunky web-based interface. The core product is now called NNMi, part of the NMC suite, under the HP Software umbrella. If you ask an HP Software salesman about network management, this is probably the product they’ll steer you towards.
But HP has another network management product, which came from the 3Com acquisition – IMC, or Intelligent Management Center. This is not so widely known, but is starting to receive a bit of attention. It’s being actively developed, with significant new features added recently. If you ask an HP Networking hardware salesman about how to handle multi-vendor management when you add their tin to your network, this is the product they’ll be pushing.
Recently I’ve been deploying the latest version (5.1 E0202) for one of my customers, so I thought I’d share a few things I found along the way, and my opinions on the product.
According to the marketing blurb, IMC is:
…a standalone, comprehensive management platform that delivers next-generation, integrated, modular network management capabilities that efficiently meet the needs of advanced, heterogeneous enterprise networks. IMC Enterprise Edition is designed on a service-oriented architecture (SOA) using a business application flow model as its core and featuring an on-demand, modularized structure. The allows the efficient implementation of end-to-end business management, while IMC software’s modular design allows for the effective integration of traditionally separate management tools.
So we know that it’s 98% buzzword-compliant (points lost for failure to mention cloud). Let’s ignore that, and just try a quick list of features I can understand:
- Network Montoring and Management System, with web-based interface. And sorry, but there is some Java in there too.
- Runs on either Windows or Linux
- Does the ICMP+SNMP fault and performance monitoring you would expect
- Also does configuration management – backup, restore, compare. etc.
- Compliance policy checking of configurations (with remediate option)
- VLAN/ACL management of devices from different vendors – don’t need to learn different CLIs, manage all devices in the same way
- Creates topology view, showing the L2 and L3 links between devices
- Hierarchical model – can scale out. Manages up to 5,000 devices/server
- NetFlow data collection and analysis
- Syslog capture and analysis
- Virtual Network Management – can connect to VMware or Hyper-V, and view/control your virtual network environment
- Extensible – can be extended to support other devices. Write your own expect scripts, and you can manage other device configs too.
- Auto discovery, with multiple options for discovery methods. Not as granular as NNMi’s discovery rules, but fine for most environments.
Unfortunately, I can’t give you any screenshots of my customer’s network, and my main demo environment is a bit broken right now. My only instance is a local VM, but this is a flavor of what the interface looks like – here’s the main page:
It’s a bit boring, since it’s only got a few ICMP-only devices on my home network. The main page is made up of “widgets” which you can change, move around, resize, etc. These next few shots show how you can build up physical layout views, showing data centers, rooms, down to rack layouts. The icons are configurable – again, because it’s only my home network, it doesn’t look that great here. Looks better when you’ve got icons that look vaguely like some real devices.
There’s also the typical alarm browser view you’d expect. Alarms can be “recovered” – which happens automatically if the device comes back online – or “deleted” to get rid of it altogether from the DB.
It’s hard to know exactly how many devices IMC supports. Some sources say 2,600, some say “over 3,000” while The Register has an awfully precise number of 5,786. There’s two issues here: one is that they have different levels of support for devices, from simply being able to poll it, through to configuration backups, and full component management (ACLs, users, VLANs, etc). The second problem is that HP won’t publish exactly what that list is! Support can tell you what the support status of specific devices is, but they can’t just give you the list. I have heard that they plan to publish a list later this year. I can understand some reluctance to publicly commit to supporting large numbers of devices from many vendors, but if you’re going to make the marketing claims, you have to back them up.
Stuff I liked:
- (Relatively) Simple to get up and running. Once you’re past the installation stage, the initial setup and configuration is pretty straightforward. It doesn’t take long to get some SNMP+SSH templates, and you can quickly begin adding devices. Soon after that, you’ve got a topology showing up, and you can get configs backed up, and performance alerts and graphs. Having most components deployed with the main installation package makes it easy to get up and running. Other products require a bit of time to get all the different components installed and integrated. With IMC, all the main components are integrated as soon as they’re installed.
- Device firmware management – want to pull a firmware image off a device, to add it to your library, for later deployment? Two clicks and it’s done. Easy. It seems to work better for HP devices, but if you have a newer image in your library, each device will tell you if there is a newer image available in the library.
- Configuration backup/restore/comparison – this all works pretty well (apart from some issues I had with SSH – see below). It’s not well documented, but it will try and range of methods to backup a device. It can use SNMP read-write to tell the device to copy its config to a TFTP location, or if that fails it can login and do a “show run” and capture that output. It can also use FTP, or SSH+SFTP. If the device is configured for SFTP, it will try SFTP first, then if that fails, it will use SSH to login and do a “show run.”
- Physical maps – if you’ve got the time, you can set up 3D maps of your data centers, showing the exact location of devices within a rack. Would probably take a fair while to set it all up, but it can give quite good visual impact. We all know that a big part of network management is getting the nice blinky lights and pretty pictures. You can even have things like walls, windows, etc in your 3D maps.
- Virtual Network Management – IMC can talk to vCenter and Hyper-V, to get full maps of your virtual networks and systems. You can even use it to migrate virtual machines around.
- Compliance checking – what’s nice here is that compliance policies are more complex than simply “Config must include the line ‘logging buffered 8192 debugging’” – it’s no good just running that check across all devices. Instead it’s clever enough to be able to associate policies with certain classes of devices. You could have an overall compliance policy, that has sub-policies for different vendors. Then you apply the top-level policy to all your devices. Nice thing is that as your vendor/model mix changes, your compliance policies can keep up.
Issues I came across:
- Installation failed for latest version, due to some missing readme files. Luckily it does have detailed logs, so you can see the name of the missing file. I just created some dummy files, and deployment proceeded. I’ve reproduced this bug in 3 different installations now. How on earth something as simple as this got past QA is beyond me, since it was a basically vanilla installation.
- In a similar vein, if you do a clean install of the latest version, telnet.exe is missing from C:Program FilesiMCserverbin. If you install the previous version, and upgrade, then it will be there. This breaks any device configuration management where it can’t use SNMP read-write, or SSH.
- Installation pretty much assumes it will have its own dedicated database, and it will have SA access to that database. Guess what? Most shops don’t like having a hundred different little databases all over the place and want to consolidate, with proper DBAs to look after things. Proper DBAs don’t like giving out SA access to anyone. And rightly so. Rather than having a pretty installer that sets up all the databases, they’d rather they were given the setup script, so they could look over it, and run it manually. We were able to get it installed by giving it an account with temporarily elevated privileges, and then dropping it back down. We also had to fix up some of the DB settings, to move the logs to a different disk.
- Backup via SSH is unreliable. SFTP works for HP systems, but where SSH is used, it tends not to work. Since it’s just XML, TCL/Expect and Perl scripts, I was able to make some changes and get this working. But it would be nice if I didn’t have to do that. I’m a script hacker, not a programmer. I don’t mind doing it for random unsupported devices, but I’d really rather not have to muck around to get SSH backup of a Cisco 3560G working.
- Odd characters added to SNMP get-requests. This is a weird bug I seem to have hit. For some devices, for some polls (say once every 10 minutes), IMC will add “@xyz” to the community string it uses for a device, where “xyz” is 3 digits. Obviously the device doesn’t like this, and sends an SNMP authentication failure. It is not that reassuring that something as simple as normal SNMP polling has bugs in it. I’ve got a support case logged, and others have been able to reproduce it, but I don’t have a fix yet. I suspect it’s a parsing error related to having an “@” in the community string in use. Hopefully I’ll get a patch soon.
- If you’ve got a large number of devices, and say half use Telnet and half use SSH, it’s a right pain managing the file transfer mode settings. You can have a default mode of TFTP, FTP or Telnet. iMC includes a TFTP daemon by default, but you’ll need to install your own FTP daemon. You can over-ride the default mode for individual devices, to set it to whatever you want. If you’ve used SSH as the login mode for a device, then it must use SFTP (which also means SSH if SFTP fails). Problem is, if the transfer mode is set to FTP, and the login mode is SFTP, then the backup will start, but fail, because it knows it can’t use FTP. Well if you knew that in the first place, why not just automatically use SFTP? No, you need to manually set it. Yes, I know what you’re thinking out there, “Why doesn’t he just use SSH everywhere anyway?” Well, it wasn’t my network, OK? I couldn’t go and re-configure all their systems, much as I might have liked to.
- iPhone interface. The marketing literature and product documentation make references to iPhone and Android interfaces, but I have not yet found out how to install the IOS client. The installation includes a file called “IMC_IOS_Client.zip” but no installation instructions. There are instructions in the manual about how to deploy the Android package, but I’m an iFruity kinda guy.
Future Direction, and IMC vs NNMi:
There’s a lot of overlap between IMC and the combination of NNMi+iSPI Performance for Metrics+Network Automation+iSPI for Traffic+iSPI for MPLS et al. NNMi has the feel of greater scalability, and potentially greater functionality. For really large networks, NNMi is probably a better bet. But for most small-medium enterprises, IMC is easier to get running, and offers more functionality in one package, without the need to install and integrate numerous components. I personally prefer the interface of IMC, and really like the customizability. It’s relatively straightforward to add support for new devices – not just simple polling, but configuration management. Right now, a lot of it is Expect scripts, but I can see how their architecture would allow you to plugin more robust device management interfaces – e.g. Netconf or similar. I also like the fact that application modules can be added to it. There’s been some recent development of this around Virtual Network Management, and I expect future versions to offer improved wireless network management tools. They have those right now, but it needs to be extended to support more vendors/devices.
I would desperately like to know what the future roadmap is going to be. I can’t see how they can bring IMC together with their other network management products, given that the development teams, software architectures, cultures and pricing are quite different. I work for an HP Software Partner, so I’ve seen a few things around product positioning, but I haven’t seen how the long term strategy will play out. Nor could I tell you if I had seen it of course…but I actually suspect that no-one yet knows exactly what it will be. It’s a bit frustrating, since no-one wants to pick a product that will get killed off in a few years. I think both products will exist in the medium term, and that we will see some more integration. But will they combine to become one suite? Or will HP keep up parallel development streams forever? Anyone from HP in the audience able to tell me?
IMC has a lot of good features, at what I consider a reasonable price (No, don’t bother asking me about the price – there’s too many variables as to what discount you can get. I’m pretty sure if you tell them you want to buy enough switches in one order to make the salesman’s total annual commission, they’ll give you an exceptionally good deal on IMC). There’s also a lot of development going on, with multiple significant new features released in the last year. But at times it feels like IMC has just escaped from the lab – some parts are very well documented, other bits are quite unclear. Occasionally it feels like it was an internal-only tool, but the developers have been told to dress it up and publish it. There’s still a few rough edges, and things like the support process don’t seem to be as slick as they should be, for a company with as much software support experience as HP.
I’ll write some more posts in future focussed on specific technical things, such as how to add configuration management support for Exinda devices. Once you’ve seen how it works, it’s pretty straightforward to add support, especially if you’ve got some scripting experience.