Last Updated: 24 January, 2014
This document contains updates to the release notes for HP Network Node Manager i Software (NNMi) 9.0x. You can also check for online NNMi 9.0x support matrix updates or the device support matrix.
Other useful links include the following:
The following list contains NNMi 9.0x update information:
If you install NNMi 9.0x Patch 5 on a windows system that previously had NNMi 9.0x Patch 4 installed, the JDK files are incorrectly updated. NNMi 9.0x Patch 5 rolls the JDK's rt.jar to a previous version, removing JDK hotfix QCCR1B90093. The described installation sequence causes ovjboss and most command-line tools to fail.
To correct this, reapply JDK hotfix QCCR1B90093 after installing NNMi 9.0x Patch 5.
Complete the following steps to add indexes to the database. Doing so improves NNMi console performance and resolves contention among ovjboss processes. There is a separate script you can use to delete the indexes in case you encounter issues. While it is not absolutely necessary to stop ovjboss before completing these steps, it is recommended that you stop ovjboss to avoid potential database contention when adding or deleting the indexes. For NNMi installations using the Application Failover feature, you only need to complete these steps on the active node.
In order to apply the indexes to Postgres, run the following commands:
Note: Running the ANALYZE command can take many minutes to execute.
To apply the indexes to the Oracle database:
Although highly improbable, you might encounter database corruption issues due to the missing indexes. Applying the indexes might cause ovjboss processes to have problems, resulting in high CPU or very poor NNMi console performance caused by database corruption. To remove the indexes, do the following:
NNMi 9.0x Patch 4 includes some changes that prevent the creation of phantom connections with connection source FDB. However, those connections that already exist in the database will remain. The following steps clean out and re-calculate all FDB connections in an effort to remove those phantom connections.
In order to remove these phantom connections, do the following steps using the new script nnml2maint.ovpl (found in /opt/OV/support on Unix, and %NnmInstallDir%\support on Windows):
The first script example removes all existing FDB connections in the NNMi database. The second script example schedules the FDB connections to be recalculated. This recalculation may take from 15 minutes up to a few hours to complete, depending on the size of the NNMi database.
NNMi 9.0x Patch 3 fails to install on Unix High Availability Systems. The Patch 3 install does not correctly check for the maintenance file when installing. To fix this, create the following files:
Once Patch 3 is installed, these files can be removed.
The installation of NNMi can hang if the loopback entry for 127.0.0.1 is not in the /etc/hosts file. This is mostly on Linux operating systems.
To correct this, add an entry:
127.0.0.1 loopback
at the top of the /etc/hosts file and reinstall the product.
Before installing NNMi, review the HP Network Node Manager i Software System and Device Support Matrix for shared memory requirements. NNMi might not create the embedded database if there is insufficient shared memory.
From the NNMi console, if you select Configuration > Discovery Configuration, then select the For more information, click here link in the Delete Unresponsive Nodes Control section, the Welcome to Network Node Manager help topic displays. To find the correct information, search on Configure Whether to Delete Unresponsive Nodes in the NNMi online help.
If you have NNMi management servers running on Solaris or Linux operating systems and have NNMi 9.0x Patch 2 or later installed, NNMi supports the following high availability product versions:
The following requirements apply:
See QCCR1B49289 or SSO Document ID KM435155 for additional information.
You can change the NNMi trap storage limit and have that change persisted over NNMi restarts by adjusting the com.hp.nnm.events.snmpTrapMaxStoreLimit property in the nms-jboss.properties file. For more information, see Configuring the Auto-Trim Oldest SNMP Trap Incidents Feature in the NNMi Deployment Reference.
NNMi can automatically trim the oldest SNMP trap incidents as the number of traps in the database approaches the SNMP trap persist limit. You can also delete the oldest incidents from the database using the nnmtrimincidents.ovpl script with the –trimOldest option (nmtrimincidents.ovpl –trimOldest). For more information, see Configuring the Auto-Trim Oldest SNMP Trap Incidents Feature in the NNMi Deployment Reference and the nnmtrimincidents.ovpl reference page, or the UNIX manpage.
The nnmcommload.ovpl script now includes options for setting SNMP enabled, SNMP address discovery enabled, and get bulk enabled. For more information, see the nnmcommload.ovpl reference page, or the UNIX manpage.
To reduce incident traffic and avoid a trap storm, use the trapFilter.conf file to block traps based on IP address ranges or trap OIDs. The blocking happens before the trap is written to the trap binary store and before it is analyzed for rate, which means that traps blocked by this filter do not affect trap rate calculations and do not appear when using the nnmtrapdump.ovpl script. For more information, see Blocking Incidents using the trapFilter.conf File in the NNMi Deployment Reference and the trapFilter.conf reference page, or the UNIX manpage.
To determine the switch port connected to a device, use the nnmfindattachedswport.ovpl script. For more information see the nnmfindattachedswport.ovpl reference page, or the UNIX manpage. The nnmfindattachedswport.ovpl script provides the same information as the NNMi console Tools → Find Attached Switch Port... menu action.
NNMi supports a new configuration file that you can use to list the management addresses of the devices for which NNMi should ignore the Discovery Protocol SNMP tables. This configuration file is especially important for customers who have Enterasys devices in their management domain. For more information, see Suppressing the Use of Discovery Protocols for Specific Nodes in the NNMi Deployment Reference and the disco.SkipXdpProcessing reference page, or the UNIX manpage.
NNMi 9.0x has been modified to support the disco.NoVLANIndexing configuration file. This feature existed in NNMi 8.12 as an undocumented feature. For more information, see Maintaining NNMi in the NNMi Deployment Reference and the disco.NoVLANIndexing reference page, or the UNIX manpage.
If the global manager is connected to a regional manager running NNMi 9.0x patch 2 or earlier, certain SNMP queries between the global and regional manager do not work. To remedy this, upgrade the regional manager to NNMi 9.0x patch 3 or later. To achieve the best results, the global manager should be the same version and NNMi patch level as the regional manager.
If you use the nnmsetdampenedinterval.ovpl script to set the dampening interval of the RateCorrelation incident to a value less than 30 seconds, the incident might remain in the dampened lifecycle state. If dampening is enabled on the RateCorrelation incident, make sure the dampening interval is set to 30 seconds or greater.
For the list of supported network devices, see the NNMi Device Support Matrix.
This device support information is based on the latest information available to HP at the time of publication. Note that device vendors can at any time alter a device's MIB usage (for example, in newer IOS or system software versions) and invalidate NNM's interpretation of that device's MIB data.
Newer Windows 2008 R2 systems ship with the 8.3 file naming format enabled on the operating system disk only. Because of this change, NNMi does not install correctly, and the embedded database is not created, on non-operating system disks of newer Windows 2008 R2 systems.
To resolve this situation, before attempting to install NNMi, complete the following steps:
Enable 8.3 file naming by running the following command:
fsutil 8dot3name set 0
One of the fixes in NNM 9.0x Patch 2 can cause the discovery subsystem to get stuck in the case that multiple SNMP manageable nodes in the management domain have been up for more than 248 days and are reporting negative values for sysUpTime. The symptom is that up to 200 nodes remain in the "Rediscovery in Progress" state, and no other nodes get rediscovered. There is a hotfix available for this issue (QCCR1B49172). Contact HP support to obtain this hotfix.
When installing NNMi on the Windows operating system, if NNMi will use an Oracle database instance and the tablespace quota is not large enough, NNMi might install correctly but not create the tables. To prevent this situation, set the quota to unlimited, but no smaller than 1MB before installing NNMi.
Use of the AES-128 privacy protocol for SNMPv3 communication requires the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files library. For more information, see the NNMi Communications chapter of the NNMi Deployment Reference.
During patch installation, the updated NNMi configurations for the IpSubnetContainsIpWithNewMac and SNMPAgentNotResponding incidents are placed on the NNMi management server but are not loaded into NNMi. To import the updated incident configurations into NNMi, do the following:
If you have already imported these incident configurations from an earlier patch, remove them from NNMi:
Import the updated incident configurations by running the following commands:
The NNMi patch delivers but does not install the following MIB files:
After patch installation, these MIB files are available in the following location:
If you want to analyze any VMware ESXi devices using line graphs or the Custom Poller, load all of these MIB files by using the nnmloadmib.ovpl tool.
Some networks use routing protocols such as HSRP (Hot Standby Router Protocol) to provide router redundancy. When routers are configured in an RRG (router redundancy group), as they are when using HSRP, the routers configured in the RRG share a protected IP address (one active and one standby). NNMi does not support the discovery and management of multiple RRGs configured with the same protected IP address. Each RRG must have a unique protected IP address.
In a global network management environment, if the total number of licensed nodes is larger than the NNMi Advanced licenses on the global manager, the global manager does not have a complete inventory of all nodes in all regions. Purchase and install enough NNMi Advanced licenses on the global manager to meet or exceed the number of total licenses installed on the regional managers. Then do one of the following:
Run the nnmnoderediscover.ovpl -all script on each regional manager.
Note: This option causes a lot of traffic on your network and consumes a lot of NNMi resources from the entire set of NNMi managers. This option is not as resource intensive as the initial NNMi discovery, but it is similar to doing the first discovery. The best approach is to space the running of the script for each region by some amount of time or by waiting for the current regional manager’s workload to drop to normal before starting the next regional manager’s rediscovery.
During NNMi 9.00 installation, NNMi prompts you for the location of any NNMi patches you want to include in the installation. If you install these NNMi patches during installation using the original version of the NNMi 9.00 media, the installation might fail. If you use the original version of the NNMi 9.00 media, do not install any NNMi patches during the NNMi 9.00 installation. Install the NNMi patches after you complete the NNMi installation.
Another remedy is to use updated media. For better results, including the ability to install patches during NNMi 9.00 installation, use the following updated media to install NNMi 9.00:
| Product Number | Platform |
| TB765‑15002 | Windows |
| TB766‑15001 | HP-UX |
| TB767‑15001 | Solaris |
| TB768‑15001 | Linux |
If you prefer to download the updated software, visit the NNMi evaluation software web site.
Note: NNMi 9.00 installation supports patch files that come in the following formats:
- <patchfilename>.msi for Windows
- <patchfilename> (shar file) or <patchfilename>.depot for HP-UX
- <patchfilename>.tar for Solaris
- <patchfilename>.rpm for Linux
Do not change the original format of these files.
If the server you plan to install NNMi on is running Windows 2008 or Windows 2008 R2, you can install the patch as part of the NNMi installation or upgrade. However, use the nnmversion.ovpl script to make sure the patch actually installed. If the patch did not install, apply the patch following the NNMi 9.00 installation.
Certain non-Cisco devices have very slow performance with Path View; the status says "Computing Path" with no intermediate updates. The Path View does eventually finish and no errors are reported.
NNMi 9.0x Patch 1 adds an option to prefer the IP address in an SNMPv1 trap's UDP header over the contents of the SNMPv1 trap's agent_addr field.
To use the IP address in an SNMPv1 trap's UDP header instead of the contents of the SNMPv1 trap PDU's agent_addr field, follow these steps:
On Windows systems, upgrading an 8.1x NNMi server with 8.1x patches to 9.00 leaves 8.1x patch information in the Add/Remove Programs list. After the 9.00 upgrade occurs, the 8.1x patch is no longer installed on the system and the 8.1x patch information can safely be ignored.
On the HP NNMi–HP UCMDB Integration Configuration form, the button labels for Submit and Help are not translated in the Japanese and Chinese locales.
The links to reference pages (command line tool documentation) in the Japanese online help do not work. To access the reference pages from a Japanese NNMi installation, click Help → NNMi Documentation Library → Reference Pages.
After installing or upgrading to NNMi 9.0x, you might see exceptions related to certificates in the jbossServer log file. These exceptions can include "java.net.ssl.SSLException: No available certificate or key corresponds to the SSL cipher suites which are enabled". These exceptions can occur because of uppercase characters in the FQDN. The workaround is as follows:
NNMi 8.1x supports two different methods for choosing the name of a node. The com.hp.ov.nms.disco.HostNameMatchManagementIP property in the ovjboss.jvm.properties file determines which method NNMi 8.1x uses. The NNMi 9.00 upgrade does not properly migrate the com.hp.ov.nms.disco.HostNameMatchManagementIP property to the nms-disco.properties file. The result of an incorrect migration is that NNMi might not be able to monitor some nodes or that NNMi might change the node name for some nodes.
The best workaround is to install NNMi 9.0x Patch 1 (or later) as part of the NNMi 9.00 upgrade process. (When the installer gives you the opportunity, identify the previously downloaded patch file.) See also: 06/25/2010: 9.0x patch installation during 9.00 installation/upgrade issues.
If no patch is available during the upgrade process, manually set the property by following these steps:
If you plan to upgrade from NNMi 8.1x running in an NNMi application failover environment, the supported upgrade path is to temporarily unconfigure application failover, upgrade the NNMi management servers to NNMi 9.0x (including any available patches), and then reconfigure application failover. For more information, see the Configuring NNMi for Application Failover chapter of the NNMi Deployment Reference.
Incidents that have been closed in NNMi cannot be unacknowledged in OMW. (The integration re-synchronizes the NNMi Closed state instead of the OMW change to no longer acknowledged.)
The workaround is to change the incident lifecycle state from Closed to Registered on the Incident form in the NNMi console. NNMi then synchronizes with OMW, which moves the message in OMW to the Active messages view.
NNMi 9.0x Patch 2 corrects this behavior.
NNMi drops some of the Netscout traps and does not show them in the SNMP trap table view. The affected trap types are NetScoutServerAlarm (OID: .1.3.6.1.4.1.141.50.2.0.1) and NetScoutServerClear (OID: .1.3.6.1.4.1.141.50.2.0.3).
The workaround is to clear the Discard unresolved SNMP traps check box on the Incident Configuration form. This change causes the NetScoutServerAlarm and NetScoutServerClear traps to be shown in the SNMP traps view. The source object field will be set to none. All unresolved traps (which were previously not shown) also start appearing in the SNMP traps view.
When using nnmconfigexport.ovpl to export the "disco" configuration area, the excluded interfaces filters are not properly preserved in the XML file. When you import (using nnmconfigimport.ovpl), you will lose any filters you have defined of the interface groups that are used in the excluded interfaces configuration.
The workaround is to also export the "ifgroup" configuration area to a separate XML file, and to then import the ifgroup XML file after importing the disco XML file.
After selecting all of the installer settings, and clicking Upgrade, the installer can appear to hang with a status message saying "Executing initialize action: Preinstall Check (II)". This situation can happen if you click in another window shortly after clicking Upgrade. The installer has posted another dialog box, which might be hidden below some other windows. Move the other windows on your screen to look for this dialog box. It is asking about ensuring you have done a backup prior to the upgrade. After you find this dialog box and click the button, the install should proceed normally.