The HP NNM iSPI Performance for QA (iSPI for QA), part of the HP Network Node Manager i (NNMi Premium), helps in configuring, monitoring, thresholding and reporting on network performance KPIs (key performance indicators). The iSPI for QA supports the following technologies in network performance monitoring - Cisco IPSLA, Juniper RPM, HP 3Com’s NQA tests and Cisco Class Based Quality of Service (CBQoS).
Note: The term Probes is used interchangeably for the technologies Cisco IPSLA, Juniper RPM or HP 3Com’s NQA tests. Similarly QoS is interchangeably used for CBQoS.
By default the iSPI for QA tries to discover Probes and QoS configurations from every node managed by NNMi. However, in a typical enterprise network there may be some devices with Probes and/or QoS interfaces that you do not want to monitor. To do so you exclude them from discovery and therefore reporting. Configuring a “Discovery Filter” helps you in filtering those Probes and/or QoS configurations from QA iSPI database. It helps to improve the scalability of the iSPI for QA by not monitoring configurations that aren’t necessary for your operation.
The iSPI for QA supports three types of “Discovery Filters”.
Node based Discovery Filters
Probe Discovery Filters
QoS Discovery Filters
Node based Discovery Filtering:
This is best option to choose when the requirement is to filter all Probes and/or all QoS interfaces of a given node. You can configure this filter to work either in ‘Include’ mode or ‘Exclude’ mode.
Exclude Mode: If you wish to filter all the Probes/QoS interfaces of a given set of devices, then you can create a file called “discovery.exclude” and specify the IP addresses of devices that you wish to exclude from discovery.
Include Mode: If there are many devices and you wish to discover Probes/QoS interfaces in only certain devices, then you can create a file called “discovery.include” and specify the IP addresses of those devices. In this case, Probes/QoS interfaces on devices that you specified in “discovery.include” are the only ones discovered by iSPI for QA.
“discovery.include” and “discovery.exclude” are mutually exclusive. If both files exist, entries in “discovery.include” take precedence.
“discovery.include” or “discovery.exclude” needs to be created in the following directory
$NNMDataDir/shared/qa/conf directory in Linux
%NNMDataDir%\shared\qa\conf directory in Windows
Once you create these files, you need to run “nmsqadisco.ovpl –resyncConfig” for the configuration to take effect.
This approach is for scenarios where you would pro-actively know the devices that you wish to exclude or include from discovery.
Wild cards can be used for specifying IP addresses in both the files (for example 192.168.*.*).
Probe Discovery Filters:
Use this option if you wish to filter a subset of probes defined on the devices or if you want to discover only QoS interfaces for a given device. When you configure probe discovery filters and apply them, probes matching the filter conditions are deleted from the database. You can also configure the probe discovery filter(s) prior to discovering probes. The iSPI for QA honors the filter configuration during discovery and does not discover those QoS interfaces.
The iSPI for QA allows you to filter probes with the following attributes as of NNM iSPI Performance for QA v10.01:
Probe’s owner name
Source IP address
Destination IP address
Probe’s type (alternatively called Service type)
AND conditions will be applied when you have defined the filter based on more than one attribute. When all the above attributes are used in a single discovery filter configuration, only probes matching all conditions are filtered by the iSPI for QA.
The iSPI for QA deletes the probes matching the filter conditions from database. This means if you re-discover the probe at a later point in time, you will not be able to see the historical data for the probe in NNM iSPI for Performance reports.
QoS Discovery Filters:
QoS configurations can typically be applied across hundreds of interfaces as not all interfaces or devices may be worthy of monitoring/reporting. Use this option if you wish to filter a subset of QoS interfaces/policies/traffic classes defined on devices or if you wish to discover only probes configured on device(s).
When you configure QoS discovery filters and apply them, QoS configurations matching the filter conditions are deleted from database. You can also configure the QoS discovery filter(s) prior to discovering probes. The iSPI for QA honors the filter configuration during discovery and does not discover the interfaces.
The iSPI for QA allows you to filter QoS configurations with the following attributes as of NNM iSPI Performance for QA v10.01:
Traffic class name
Device IP address
When all the above attributes are used in a single discovery filter configuration, then all are taken into account and only QoS configurations matching all conditions are filtered by the iSPI for QA.
Policy name and Traffic class name attributes support wild cards. You can use multiple wild cards to filter the policies/traffic classes.
Best practices on configuring/using Discovery Filters in a large scale environments:
Both Probes & QoS discovery filters recognize wild cards for IP address and string attributes (except Node Group attribute). You can use multiple wild cards (for example 192.168.*.* AND10.0.10-150 AND so on) while using an IP address filter configuration. Other attributes like Probe owner name, Policy name, Traffic class name etc. that accept string data also recognize wild cards.
If you know in advance the probes or QoS configurations that need to be filtered, it is efficient to create the discovery filters prior to discovering the devices as the iSPI for QA honors filter configurations during discovery and discards any probes and/or QoS configurations matching the filter conditions.
When you use the “Apply Filter Now” option, available in the configuration UI, the filter is applied immediately and all the probes and QoS interfaces that match the filter rule will be deleted immediately from the database. If you are filtering a large set of probes or QoS configurations (say in the hundreds) across many devices then the optimal way is to just save the filter rules and let the next discovery cycle apply the filter. This reduces the performance impact of filtering because the discovery will happen based on a schedule rather than all at once.
The whole network management solution including the iSPI for QA will be on display at HP Discover June 2-4 in Las Vegas. Stop by to get a demonstration, ask questions or just say hello. Uncover the unknown.
About the author: Arun Srinivasan has been testing HP NNM iSPI for Quality Assurance for over three years. He has experience in manual and automated testing and configuring network performance configurations for testing iSPI for QA.
Arun has a Bachelor of Engineering (B.E) degree in Computer Science from SCSVMV University, Kanchipuram, India.