|Read more about this book|
(For more resources on Network management, see here.)
NNMi 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)|
|Read more about this book|
(For more resources on Network management, see here.)
iSPI Network Engineering toolset
When an issue on the network occurs, the operator needs to troubleshoot the issue and often a sequence of additional action is required, such as checking the current status of interface, getting node configuration, evaluating outage impact, or collecting information about end nodes connected to switch.
Another headache for system administrators and operators is constant and meaningless SNMP traps, which floods the message browser and cause event storms. This can be caused by some improperly configured settings on group of nodes, or constant and frequent event generation on one node.
All these issues are solved by iSPI NET. It is a set of tools, which helps in troubleshooting network issues. In general, there are three major features in this iSPI:
- Troubleshooting tools, attached switch port troubleshooting
- Trap analytics
iSPI diagnostics helps to collect additional configuration data from network devices, such as:
- Current configuration for Cisco router, Cisco switch, or Nortel switch
- Diagnostic checks on a specified interface on Cisco router
- Gather routing information
To configure this automatic diagnostics gathering, you need to complete following steps in SNMP Trap Configuration, Remote NNMi 6.x/7.x Event Configuration, or Management Event Configuration forms:
- Specify node group in Configuration Per Node Group form
- In the Diagnostic Selection, select which diagnostics you want to use
Diagnostic must be valid for a node which runs diagnostics. That is, Cisco configuration can run only on Cisco devices.
Incident's lifecycle state must match state which was configured. That is, if lifecycle state is closed, then diagnostics will run only when incident's state would be closed.
This tool examines switches, detects and maps switch ports with end nodes connected to them. End nodes don't need to be discovered by NNMi, as this data is queried from the switch's ARP table. Using this data collection method, the troubleshooting tool provides the following information:
- Which switch port the node is connected to. It can be searched by IP address, node name, or MAC address.
- All nodes attached to switch.
This functionality is very useful for troubleshooting LAN issues. Many NNMi users were complaining about the lack of this feature in previous NNMi versions (7.x and earlier).
By default, NNMi measures the rate of incoming traps (incoming trap rate for each device and rate of each incoming trap for each trap OID). If the rate of incoming traps exceeds the defined threshold, NNMi blocks such traps until the rate decreases below the minimum threshold limit.
Thresholds can be configured by the administrator using nnmtrapsconfig.ovpl script.
SNMP trap analytics allows you to get reports based on this trap information, by the following criteria:
- Amount of traps within a specific time period
- Trap amount for specified node
- Trap amount to a specific trap identifier—OID
All data is logged to trapanalytics.0.0.log file. This file provides following data for specific time intervals:
- Traps per second
- TOP 10 trap generator sources
- TOP 10 generated traps
This data is useful in making analysis of SNMP traps, which allows us to optimize messages from your managed network. Many administrators are complaining that they receive too many messages. In many cases, administrators say they have no idea where to start. So, start from the largest troublemakers—TOP 10 OIDs and TOP 10 sources. If you fix at least TOP 5 OIDs, you will reduce the amount of alarms by 40-80%. So, even if the situation looks hopeless, there is a small and easy way to make the step between a messy and shining browser.
iSPI IP Telephony
HP NNMi Smart Plug-in for IP Telephony extends the functionality of NNMi, providing more detailed information about the VoIP telephony infrastructure. iSPI for VoIP discovers, monitors, and presents additional views of VoIP specific parameters, such as:
- IP address, hostname, version, model, type, and status of device
- Phone model, registration state, extension number, and supported protocol controller
- VoIP network health
First of all, your VoIP devices will be discovered automatically and presented on a map as VoIP-specific devices, so that you can easily recognize VoIP phone, PBX, or voice gateway on a map.
The NNMi SPI for IPT provides comprehensive monitoring for an IP telephony service. It includes features, which are VoIP specific: voice gateway, calls, and path control.
Using iSPI for IPT monitoring is more detailed than IP generic monitoring, and gives an advantage for VoIP-specific issues against plain NNMi monitoring of IP network. iSPI for IPT helps detect outages in their early stage.
The quality of calls has been reduced, so more calls are dropped or being provided with long voice delays. Using plain NNMi, you wouldn't recognize such behavior and you would have green map with no incidents regarding this issue, while your IPT users are struggling and complaining about poor quality. iSPI for IPT would notify you about such (and even more) service decreases, so the only thing you should take care of is to fix a problem.
(Move the mouse over the image to enlarge.)
The following list provides a detailed feature list, which is supported by iSPI IPT:
- Infrastructure management:
- Call Manager 5.x, 6.x inventory, detail views, and status/incident.
- Cisco GK inventory, detail views, and status/incident.
- Cisco ICT inventory, detail views, and status/incident.
- Nortel CS 1000, Nortel SS, and Nortel VGMC/MGC/MC inventory, detail views, and SNMP trap-based alarm status.
- IP phone management:
- Inventory and detail view of Cisco IP phones (SCCP/SIP), their registration status and their relationship to Call Managers.
- Inventory and detail view of Nortel IP phones, their relationships to Nortel CS.
- Detailed Cisco Voice Gateway management:
- Cisco DS0 channel inventory, detail view, alarm status, usage status.
- Cisco DS1 (T1/E1 CAS/PRI/BRI, E&M, FXS, and FXO) Circuit Switched interface inventory and detail view, alarm status/incident, and usage incident/status.
- Cisco VGW inventory and detail view, alarm status/incident, usage status/incident, H323 and MGCP support.
- Voice quality monitoring and diagnostics:
- CDR/CMR-based Jitter, latency, delay, MOS monitoring for calls in Cisco IPT networks and incidents.
- Nortel QoS zone inventory, detail view with 32 QoS metric values for Nortel QoS zones and incidents.
- Nortel QoS SNMP trap-based monitoring of quality of calls in Nortel IPT network and incidents.
- Voice path draws L2/L3 path between two Cisco IP Phones for media.
- Control path draws L2/L3 path between a Cisco IP Phone and its Call Manager.
No localization support on iSPI for IP Telephony.
iSPI for MPLS
iSPI for MPLS helps to monitor MPLS-specific parameters. It uses NNMi's node inventory and provides MPLS-specific, real-time data for MPLS-enabled devices:
- MPLS Virtual Private Networks (VPN) on provider edge devices.
- MPLS Pseudo Wire Virtual Containers (VC).
- Traffic Engineering (TE) tunnels.
- Monitors status and displays VPNs, VRFs, TE tunnels, and Pseudo Wire VCs attributes.
- Generates incidents for the MPLS-specific faults or changes in the topology.
The following figure represents the difference between managing MPLS-enabled network using plain NNMi (left-hand side picture) and using iSPI MPLS (right-hand side picture):
iSPI MPLS automatically discovers MPLS devices and presents MPLS-specific data like L3-VPN/VRF, L2VPN (Pseudo Wire), and MPLS traffic engineering. MPLS specific views and implemented correlation are provided on MPLS specific incidents.
MPLS is supported only on Cisco IOS, IOS XR.
iSPI MPLS does not support localization.
The detailed feature list of iSPI for MPLS is as follows:
- L3-VPN Management:
- Inventory view of L3-VPNs.
- Details views for an L3-VPN including VRFs, VRF-details.
- Monitoring of VRF state and incident/status-propagation for L3-VPNs.
- Label Switched Router (LSR) views:
- LSR core view.
- Launch from LSR view to other views showing node-centric MPLS-services.
- Traffic Engineering management:
- Inventory view of TE Tunnels.
- TE Tunnel details view.
- Monitoring of TE tunnel status and incidents.
- Pseudo-wire management:
- Inventory view of pseudo-wires.
- Monitoring of pseudo-wire status and incidents.
- As any other iSPI, it can be installed at any time, even if your deployment is completed a long time ago.
IP multicast is a technique for one-to-many communications over an IP infrastructure in a network. It scales to a larger receiver population by not requiring prior knowledge of who or how many receivers there are. Multicast uses network infrastructure efficiently by requiring the source to send a packet only once, even if it needs to be delivered to a large number of receivers. Multicast mostly is used for services such as video or audio broadcasting, when many users may be watching/listening for the same content. The nodes in the network take care of replicating the packet to reach multiple receivers only when necessary. The most common low-level protocol to use multicast addressing is User Datagram Protocol (UDP). By its nature, UDP is not reliable—messages may be lost or delivered out of order. Reliable multicast protocols such as Pragmatic General Multicast (PGM) have been developed to add loss detection and retransmission on top of IP multicast (source—Wikipedia).
This article described what smart plugins are and should be chosen when designing NNMi.