Network Node Manager has a pretty long list of features, especially when we consider the information it provides in regards to network topology and all other information related to it. Every network is unique in terms of technologies it uses and purposes it is designed to. For example, carrying voice over IP, where voice converges with IP networks. MPLS is another unique technology, which in some terms can be treated as a separate science and needs additional management approach. Multicast is another story, with its own features and headaches from an operations perspective.
All these technologies and features are not rocket science, but it is really an additional effort to be developed as a management tool. Most of NNMi users have hardly any of these technologies, so why should they pay for features they never use?
Mostly, SPIs use NNMi’s discovered nodes and their configuration as a primary source of information. Also, iSPI provides some information back to NNMi, that is, additional features or technology configuration, configuration changes, performance parameters, or alarms.
Here is a list of major SPIs:
- iSPI for MPLS: Allows users to discover and monitor MPLS-specific objects and parameters. For example, L2/L3 VPNs, MVPN, Pseudo wire VC, VRF, PE-CE, PE-PE links, and so on.
- iSPI for IP Telephony: This iSPI discovers and monitors VoIP-specific objects and parameters. It supports VoIP monitoring from Avaya, Cisco, and Nortel vendors.
- iSPI Network Engineering toolset: This iSPI is a set of additional tools, which allows NNMi operator to initiate some routine actions, which helps in troubleshooting issues.
- iSPI for Performance: After NNMi version 8.11, this iSPI has been divided into two separate iSPIs: iSPI Performance for Metrics and iSPI Performance for Traffic. These iSPIs collect and report performance specific data—Network Engineering Toolset (NET). This iSPI provides additional troubleshooting and diagnostics tools for network engineers.
- iSPI for Multicast: This iSPI provides multicast network specific features, such as discovering and monitoring IP multicast routing topology, multicast enabled nodes, PIM interfaces and neighbors, and so on.
Questions such as “Do I need SPI? If so, which one of these to choose? Will it do what I expect?” are ones commonly asked while designing NNMi. Let’s take a look at the major SPIs.
iSPI for Performance
Before NNMi 8.11, there was iSPI Performance, which was introduced as two separate iSPIs on later NNMi versions. Legacy iSPI performance was collecting performance metrics based on SNMP queries on managed nodes. Later on, HP introduced the ability to collect data from flows, as flow data has a different list of features than performance data collected by SNMP. These iSPIs are:
- iSPI Performance for Metrics: Legacy iSPI performance with few improved features.
- iSPI Performance for Traffic: iSPI, which collects, analyzes, stores, and presents flow data.
Let’s take a look at both in detail.
iSPI Performance for Metrics
The iSPI Performance for Metrics adds the performance management capability to NNMi by analyzing, processing, and aggregating metrics collected by NNMi from different network elements. This release of the iSPI Performance for Metrics includes the following features:
- Path health reports
- omponent health reports
- Interface health reports
- Custom polled reports
Also, unlike in previous NNM versions (7.x and earlier), we cannot trigger alerts based on performance data in basic NNMi versions. That is, we need to receive alarms when the device CPU load exceeds 95%, the interface utilization exceeds 70% or comes below 5% for longer than one hour. Default NNMi can’t handle it. iSPI performance brings this feature into NNMi. Now, we can say that NNMi and iSPI Performance both together cover fault and performance monitoring areas.
The network performance data adds more functionality for network management. It improves your network management by:
- Allowing operators to retrieve more data during investigations
- Enriching your monitoring by providing alerts based on performance data
- Providing information to network planners and analysts, where they can see long-term statistics, which makes future planning more accurate
iSPI Performance collects, stores, arrays data, and presents it in drill-down reports. Using data mining in reports, we can drill down until we reach the node or interface, which causes issues.
Users have relative flexibility in creating their own reports, as custom SQL queries can be created on reports by user-specific needs, such as a report with custom time period, or metrics, which are monitored. iSPI reports are reached from the NNM console, and no additional logins and passwords are needed as iSPI recognizes usernames or passwords used by NNMi. Reports running after they are selected and take up to 15 to 20 seconds. To eliminate this query at runtime, you can schedule the report to run in advance, as the scheduled report is displayed immediately.
All monitored metrics can trigger threshold alarms, so operators can be notified before real impact occurs. Performance-based alarms also reflect the status of the nodes, which makes the map status more accurate for monitoring.
Earlier NNM versions used to cause a lot of confusion when performance-based alarms indicated possible outages or upcoming service impacts, and map icons remained in a normal (green) state.
NNMi iSPI Performance for Metrics may be licensed to monitor a smaller number of nodes than its corresponding NNMi. Consider, if you are a service provider and only a small part of your managed nodes has a requirement to be monitored features, which are supported by iSPI performance for metrics. Buying licenses for all the nodes would be a waste of money. Another wasteful example would be, if your NNMi, except routers and switches, also monitors a Users have relative flexibility in creating their own reports, large number of workstations or servers which don’t need to be covered by iSPI Performance for Metrics.
As HP changes licensing policy on a regular basis, please contact your HP representative to check the most current licensing policy. Please refer to http://support.openview.hp.com/selfsolve/manuals.
NNMi can be configured to poll vendor proprietary MIBs, issue a threshold incident, set status on the map to alert operations, report on values and with NNMi iSPI performance for metrics.
iSPI is not a replacement to HP Performance Insight (OVPI), but depending on particular requirements, sometimes iSPI Performance for Metrics may be used as an alternative to OVPI. The following table provides high-level comparison of iSPI Performance for Metrics and OVPI:
| NNMi iSPI Performance for Metrics | Open View Performance Insight |
| Tightly integrated with NNMi | May be integrated into NNMi as well as can be a separate product |
| Short to medium term data is stored | Long-term data is stored |
| Collects MIB data using SNMP | Customized data collection methods can be used, that is, Operations Manager or Performance Manager agent |
| Designed to be used for proactive monitoring and generating alarms | Designed for long-term reporting |
| Tool very handy for operations | Tool for operations, analysis, planning, and reporting to management |
If you are, or plan to be an NNMi system administrator, you should be prepared to be asked whether or not iSPI Performance for Metrics loads a network with extra ICMP or SNMP traffic. Although the answer is yes, iSPI queries extra information, but on the other hand, it wouldn’t load a network as much as it would separate a tool from a third party vendor, because iSPI uses the same SNMP process to collect performance and status information. It means that it eliminates extra polling, as the data is queried and responded using same packet bulks.
iSPI Performance for Traffic
By introducing this iSPI, NNMi took a step into network service monitoring. This iSPI uses flow data and can detect reports such as performance issues, like separate traffic types HTTP, mail, and FTP traffic. It can report about top sources or destinations, and so on. So now, the NNMi operator can take a look on what’s happening inside IP traffic, as iSPI Performance for Traffic analyzes flow data. The following flow versions and vendors are supported:
- NetFlow: version 5, version 9
- S-Flow: version 5
iSPI Performance for Traffic is very useful for troubleshooting network issues, such as:
- What kind of traffic utilizes my bandwidth most or fills it up?
- What sources or targets generate most traffic?
These issues are a headache not only for operators, but for network or service analysts and planners as well. If your data channel is divided into traffic classes based on traffic type (that is, 20% of traffic for HTTP, 30% for mail, and so on), this iSPI will also tell you about your traffic classic behavior.
Example: Why is my HTTP browsing is so slow, while my interface utilization is below 70%? Answer: HTTP traffic is configured to take max 30% of your bandwidth, and HTTP takes all of it while other traffic classes are less loaded, which makes total bandwidth utilization less than 100%. So, instead of constant questions and unclear situations, iSPI Performance for Traffic gives a clear answer, with evidence, that it is time to change traffic class allocation limits. This can be seen in the following diagrams:
This iSPI can be used in conjunction with iSPI Performance for Metrics, which provides navigation between Metric and Traffic data.
iSPI Performance for Traffic cannot trigger an alarm.
Traffic generates performance reports from the IP flow records as follows:
- Aggregates the IP flow record.
- Correlates obtained IP flow records with NNMi topology for context-based analysis.
- Enriches the IP flow records by providing the ability to add or update the available fields in the flow records. For example, DNS name resolution and application mapping.
Flow data is collected using flow collectors, which can be designed as two tier collectors: local and master. NNMi supports either of the two scenarios: co-located and non-co-located deployment of leaf, master collectors, and NNMi, as well as NNMi iSPI Performance server. The following figure represents the two-tier, hierarchical flow collection and processing:
- Leaf collectors: They are responsible for flow filtering, application mapping, DNS name resolution, and summary data feed to master collector.
- Master collector: This collector is responsible for collecting and correlating all summary records as central point from all leaf-level collectors.
- Common NNMi iSPI Performance Reporting Server: This server is responsible for building traffic analysis reports, which are done on the same server as iSPI Performance for Metrics.
Multiple leaf collectors per physical machine can be supported.
Can this iSPI be used as a replacement to OVPI? General answer is no. However, there may be some cases when iSPI Performance for Traffic may cover the required features. The following table provides a general comparison between iSPI and OVPI:
| iSPI Performance for Traffic | Open View Performance Insight |
| Tightly integrated with NNMi | May be integrated into NNMi as well as can be separate product |
| Short to medium term data is stored | Long-term data is stored |
| No alarms can be triggered | Alarms can be triggered based on threshold settings |
| Focused on flow collection | Focused on long term trending, forecasting and capacity planning |
| Tool, very handy for operations | Tool for operations, analysis, planning and reporting to management |
| Supports Net Flow (v5, v9) and sFlow (v5) | Supports Net Flow (v5) and sFlow (v5, with IUM collector) |