HP NNM implementation from the real world perspective
Use Cases and Deployment Scope
Pros
- Automated network discovery. Simple discovery rules and granular settings across regions allow the user to manage what parts of the network are automatically discovered. The user also has a choice not to use automated discovery if they do not want it. They can add lists of devices by CSV file if needed.
- Simple polling architecture. NNM has a single polling source allowing the customer to keep simple ACL rules allowing NNM access to devices across the enterprise. It also supports a hierarchical structure with multiple instances if needed by the user.
- Out of box content. There are multiple dashboards available out of box with the different modules that can be added onto NNM. Key Performance Graphs include Top 10 device CPU utilization, Top 10 Interfaces with Errors, Top 10 Interfaces with packet drops, Top 10 QoS violators.
- Layer 2 and Layer 3 network mapping. NNM is very good at automatically creating network topology maps. It allows the user to group nodes together showing small parts of the topology to entire regions for trouble shooting or NOC monitoring.
Cons
- Most customers would like to see NNM get away from using some Java applets.
- In environments where we see more than 10 different network device vendors in production, we see issues with L2 mapping. Different vendors use different L2 protocols. This can cause an issue with L2 discovery and mapping.
Likelihood to Recommend
A less appropriate scenario is small networks. 50 devices or less. HP NNM is a world class enterprise network fault monitoring solution. Any organization with less than 50 network devices to monitor would find HP NNM is too expensive and too feature rich for their needs. Generally we find smaller organizations just need up/down monitoring. NNMi does MUCH more than that.
Any organization with 100 or more network nodes would find NNMi to be a valuable solution for their network monitoring needs.
