Last Updated: 24 January, 2014
This document contains updates to the release notes for HP Network Node Manager i-series (NNMi) 9.1x. You can also check for online NNMi 9.1x support matrix updates or the device support matrix.
Other useful links include the following:
The following list contains NNMi 9.1x update information:
HostNameMatchManagementIP property to false
SEVERE: Autopass failure (ClassNotFoundException)
ovjboss.jvmargs fileThe SNMPv1 and SNMPv2 trap handling mechanism in NNMi 9.1x Patch 6 provides an additional option to control the way the trap source address is selected.
Normally, for SNMPv1 traps, the agent address in the SNMPv1 trap Protocol Data Unit (PDU) identifies the trap source address.
In the case of SNMPv2 traps, the source address is identified by the IP header. However, this trap source address may be overridden by either the override varbinds in the trap or
by the NNMi property com.hp.nnm.trapd.useUdpHeaderIpAddress.
The source address varbinds in the traps override the property setting. With
NNMi 9.1x Patch 6, a new option is added
to control the effect of special proxy address varbinds. The new property, com.hp.nnm.trapd.ignoreProxyAddressVarbindOverride, when set to "true", causes the setting of com.hp.nnm.trapd.useUdpHeaderIpAddress to take precedence over the special proxy address varbinds. By default,
com.hp.nnm.trapd.ignoreProxyAddressVarbindOverride is set to false.
To change the value for this property, complete the following steps:
%NnmDataDir%\shared\nnm\conf\props\nms-jboss.properties$NnmDataDir/shared/nnm/conf/props/nms-jboss.properties #! com.hp.nnm.trapd.ignoreProxyAddressVarbindOverride=false#! characters and change the value to "true" . The special proxy address varbinds that are controlled by this new property are:
snmpTrapAddress ( .1.3.6.1.6.3.18.1.3.0)nnmTrapForwardingAddressOid (.1.3.6.1.4.1.11.2.17.2.19.1.1.3.0)securityPackNotificationAddress (.1.3.6.1.4.1.99.12.45.2.1.0)hpOVSecureTarget ( .1.3.6.1.4.1.11.2.17.5.1.0)
Also note that this property does not affect the openviewSourceName (.1.3.6.1.4.1.11.2.17.2.2.0) varbind.
In addition to the introduction of the new property, the value for the custom attribute
cia.orginalAddress is set such that it contains the original trap source address that was obtained prior to
either applying the value from the special proxy source address varbind or choosing the trap source based on the setting of the parameter com.hp.nnm.trapd.useUdpHeaderIpAddress.
The following table that shows the values stored in the custom attributes cia.address and cia.originalAddress, under various scenarios:
| Trap | NNMi 9.1x Parameter Settings | |||||
|---|---|---|---|---|---|---|
| useUdpHeaderIPaddress = false; com.hp.nnm.trapd.ignoreProxyAddressVarbindOverride = false | useUdpHeaderIPaddress = true; com.hp.nnm.trapd.ignoreProxyAddressvarbindOverride = false | useUdpHeaderIPaddress = true; com.hp.nnm.trapd.ignoreSpecialvarbindOverride = true | useUdpHeaderIPaddress = false; com.hp.nnm.trapd.ignoreSpecialvarbindOverride = true | |||
| v1 trap |
cia.originalAddress = source address from IP Header |
cia.originalAddress = agent address in snmp PDU |
cia.originalAddress = agent address in snmp PDU |
cia.originalAddress = source address from IP header |
||
| v1 trap with source address varbinds |
cia.originalAddress = agent address in snmp PDU |
cia.originalAddress = source address from IP Header |
cia.originalAddress = agent address in snmp PDU |
cia.originalAddress = source address from IP header |
||
| v2 trap |
cia.originalAddress = source address from IP Header |
cia.originalAddress = source address from IP Header |
cia.originalAddress = source address from IP Header |
cia.originalAddress = source address from IP Header |
||
| v2 trap source address varbinds |
cia.originalAddress = source address from IP Header |
cia.originalAddress = source address from IP Header |
cia.originalAddress = source address from IP Header |
cia.originalAddress = source address from IP Header |
||
The SNMPv3 USM privacy protocol determines whether encryption is required and indicates the type of privacy protocol used. There are two SNMPv3 USM privacy protocol settings listed incorrectly in the NNMi Help. NNMi supports the following privacy protocols:
In cases where both the ifSpeed and the ifAlias of a specific interface change values between discovery polls, NNMi's default behavior is to
consider these value changes to be complete interface changes. This means that NNMi
deletes the old interface from its database and creates a new one. A result
of this behavior is that NNMi removes any custom attributes or management state assigned to this interface before creating a new one. For customer environments where a pair
of changes like this does not indicate a new interface, you can enable a property to have NNMi consider these value changes as updates to an existing interface.
To configure this property, complete the following steps:
%NnmDataDir%\shared\nnm\conf\props\nms-disco.properties.$NnmDataDir/shared/nnm/conf/props/nms-disco.properties.nms-disco.properties
file: allowSpeedAndIfAliasChangeToUpdateIface.nms-disco.properties file to set the allowSpeedAndIfAliasChangeToUpdateIface property for your environment.nms-disco.properties file, you must restart NNMi for that change to take effect.NNMi uses the Device Credentials settings for the following:
Use of the TripleDES, AES-192, or AES-256 privacy protocols require the intallation of the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 6 library. The NNMi 9.1x Deployment Reference incorrectly states that you must download and install the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files library before you can use the TripleDES, AES-192, or AES-256 privacy protocols. Beginning with NNMi 9.10, this library is installed automatically as part of the NNMi installation process. If you do accidentally delete the library, and need to enable NNMi to use the AES-192, AES-256, and TripleDES privacy protocols for SNMPv3 communication, follow these steps:
local_policy.jar and US_export_policy.jar) to the following location:
%NnmInstallDir%\nonOV\jdk\nnm\jre\lib\security$NnmInstallDir/nonOV/jdk/nnm/jre/lib/securityHostNameMatchManagementIP property to falseIf you plan to upgrade an earlier version of NNMi 9.0x to NNMi 9.1x, and if that same system had been running NNMi 8.1x at some time in the past, the upgrade might incorrectly set the HostNameMatchManagementIP property to false. The HostNameMatchManagementIP property exists in the nms-disco.properties file.
In most cases, you will prefer the value of this property to be true. If you want it to remain true, check this file after the upgrade completes, and correct the value if necessary. The nms-disco.properties file is located in the %NnmDataDir%\shared\nnm\conf\props folder (Windows) or the $NnmDataDir/shared/nnm/conf/props directory (UNIX).
If you change the value of the HostNameMatchManagementIP property, for the changes to take effect, you must restart the NNMi management server as follows:
ovstop command on the NNMi management server. ovstart command on the NNMi management server.
NOTE: When making file changes under HA, you must make the changes on both nodes in the cluster. For NNMi using HA configurations, if the change requires you to stop and restart the NNMi management server, you must put the nodes in maintenance mode before running the ovstop and ovstart commands.
If you install an SNMP MIB Loader hotfix after applying NNMi 9.1x Patch 4 (or later patch), you can load specific MIBs that you could not load prior to installing the SNMP MIB Loader hotfix. After you remove the SNMP MIB Loader hotfix or the patch, you can no longer load or unload a MIB. To avoid this issue, unload all of the MIBs you loaded after applying the patch or installing the SNMP MIB Loader hotfix before you uninstall the patch or hotfix. An alternative approach is to install the newest MIB Loader Hotfix that corresponds to the patch you uninstalled.
NNM9.1x Patch 4 contains the following new custom incident attribute: cia.originaladdress.
NNMi determines this attribute's meaning in conjunction with the com.hp.nnm.trapd.useUdpHeaderIpAddress
property, defined in the $NnmDataDir/shared/nnm/conf/props/nms-jboss.properties file (UNIX) or
%NnmDataDir%\shared\nnm\conf\props\nms-jboss.properties file (Windows). The value of the
com.hp.nnm.trapd.useUdpHeaderIpAddress parameter is false by default, so NNMi normally
ignores the cia.originaladdress attribute. When the value of the com.hp.nnm.trapd.useUdpHeaderIpAddress parameter
is false, the cia.address value is the SNMP Agent IP Address. After you set the
com.hp.nnm.trapd.useUdpHeaderIpAddress value to true, the cia.originaladdress attribute provides the
value of the SNMP Agent Address, and the cia.address value provides the User Datagram Protocol (UDP) header IP Address.
Setting the com.hp.nnm.trapd.useUdpHeaderIpAddress value to true is useful when you want to use the UDP header address as the
source in NNMi and still require access to the actual SNMP address of the managed device.
When the com.hp.nnm.trapd.useUdpHeaderIpAddress attribute is false (the default setting), the cia.originaladdress and cia.address attributes both contain the same value.
You can configure NNMi 9.1x to enforce strict SNMPv3 inform processing. Once you configure this new property, it enables NNMi to enforce strict SNMPv3 inform processing. NNMi does not process any SNMPv3 inform having credentials that do not match those credentials configured in the Trap Forwarding Configuration. This configuration disregards the authentication or privacy configured for a node in the NNMi Communication Configuration screen.
Note: NNMi validates SNMPv3 traps differently than it validates SNMPv3 informs (with this new property). For SNMP traps, NNMi uses the communication configuration currently being used to monitor a node in topology.
To configure the new property, do the following:
%NNM_DATA_DIR%\shared\nnm\conf\props\nms-communication.properties$NNM_DATA_DIR/shared/nnm/conf/props/nms-communication.propertiescom.hp.ov.nms.comm.snmp.enforcestrictv3traps=trueIf the property you just configured is missing, or is set to false, NNMi does not validate SNMPv3 informs against the
configuration set in the Trap Forwarding Configuration (the NNMi behavior before adding this feature). NNMi logs
messages related to rejected SNMPv3 informs and traps to the nnm-trace*.log file.
Important: HP might choose to enforce strict SNMPv3 inform processing (set this property to true) by default. This could happen without providing the ability to disable strict SNMPv3 inform processing. This new default behavior could happen without notice for any full release of NNMi, as strict SNMPv3 inform processing is considered a best practice that all customers should follow. HP advises any customer using SNMPv3 informs, traps, or both to configure devices to send those messages with the correct credentials for each type of trap.
In some cases, it is desirable to have NNMi use FDB information from switches to derive layer 2 connections rather than
using information from discovery protocols such as CDP, LLDP, and others. The default configuration for NNMi
is to use the discovery protocol (xDP) information instead of using FDB information. NNMi has a new property value
called fdbOverrideNodeGroup. The fdbOverrideNodeGroup property is not enabled by default. If
you set this property to be the name of a node group, then any node belonging to that node group has the potential of
having its FDB-based connections override its xDP connections. If NNMi creates a
connection using FDB-based
information, it shows the type of the connection as FDBH rather than FDB. See the documentation for the
fdbOverrideNodeGroup property in the %NnmDataDir%\shared\nnm\conf\props\nms-disco.properties
file (Windows) or $NnmDataDir/shared/nnm/conf/props/nms-disco.properties file (UNIX).
In some cases, NNMi might (accurately) show many administratively down IP addresses. These IP addresses result in
NNMi showing many undesired layer 2 connections on its maps. NNMi has new property value called ignoreAdminDownIPs.
NNMi's default configuration sets this new property value to false. If you set this property value to true, NNMi no longer
discovers IP addresses that are associated with administratively down interfaces. See the documentation for the
ignoreAdminDownIPs property in the %NnmDataDir%\shared\nnm\conf\props\nms-disco.properties
file (Windows) or $NnmDataDir/shared/nnm/conf/props/nms-disco.properties file (UNIX).
Many firewall and loadbalancer devices have duplicated IP addresses, duplicated layer 2 addresses, or both. This is especially true when the device is a virtual instance hosted on a physical device. NNMi often considers such devices to be duplicates of each other when they are not really duplicates. NNMi has new configuration file in which you can list the sysObjectId values of these nodes. Doing so tells NNMi not to consider such nodes to be duplicates when it finds overlapping IP addresses, layer 2 addresses, or both. See the macdedupexceptions.txt.4 reference page, or the UNIX manpage, for more information.
The NOT, EXISTS, and NOT EXISTS options do not function correctly in the Payload Filter Configuration tab.
For instructions about how to do this migration, see http://support.openview.hp.com/selfsolve/document/KM1365577.
SEVERE: Autopass failure (ClassNotFoundException)If you run the nnmlicense.ovpl script to open the Autopass License Manager, and see an error similar to the following, the HPOVLic package has been removed or damaged:
Apr 13, 2012 4:27:23 AM com.hp.ov.nms.autopass.controller.License initializeAutoPass
SEVERE: Autopass failure (ClassNotFoundException):
Can not find Autopass classes; autopass functionality will be bypassed: java.lang.ClassNotFoundException: com/hp/ov/lic/sm/Err
To remedy this, do the following:
HPOvLic package from the NNMi install DVD packages directory to a temporary directory.HPOvLic package is completely removed. Note: If the
HPOvLic package is already removed, you might encounter an
error. HPOVLIC must be all capital letters.HPOvLic package:For NNMi 9.1x, you cannot configure the HP NNMi-HP NA integration for SSL.
When installing NNMi 9.10x Patches 1, 2 or 3 on NNMi management servers configured to use HA in maintenance mode, the installation might not complete,
showing the following error message: Please stop the resource group before proceeding with patch installation.... This problem occurs if
you configured maintenance mode using a file named maintenance. To remedy this, configure the maintenance mode using a file named
maint_NNM instead of maintenance. This problem is fixed in NNMi 9.10x Patch 4.
NNMi 9.1x Patch 3 supports both Red Hat Linux and SUSE Linux operating systems. See the NNMi 9.1x HP Network Node Manager i Software System and Device Support Matrix for the specific supported versions. The Linux patch package NNM910L_00003.rpm applies to both Red Hat Linux and SUSE Linux operating systems.
If you have NNMi 9.0x integrated with NA 9.00 and plan to upgrade NNMi from NNMi 9.0x to NNMi 9.10, you must complete the following steps before upgrading:
Suppose you use NNMi to manage a network that mostly contains equipment reporting layer 2 connections using discovery protocols such as CDP and LLDP. For equipment not supporting these discovery protocols, NNMi relies on a neighboring switch's FDB tables to determine connectivity. In some rare situations, such as a network having a large majority of equipment supporting discovery protocols, NNMi using additional FDB information from neighboring switches might result in inaccurate connectivity displayed in NNMi. In these rare situations, you might not want NNMi to use any FDB-based information to discover connectivity for this equipment.
After installing NNMi 9.1x patch 3, you can completely disable all FDB-based layer 2 connection processing. It is important to understand that disabling FDB-based layer 2 connection processing disables this processing for all nodes currently being managed. It is also important to understand that, after disabling all FDB-based layer 2 connection processing, NNMi does not remove connections previously discovered using FDB-based layer 2 connection processing.
To enable the FDB analysis suppression feature, see the instructions contained in the
nms-disco.properties file. Look for the nms-disco.properties file in
/var/opt/OV/shared/nnm/conf/props (UNIX) or %nnmdatadir%\shared\nnm\conf\props (Windows).
You must restart NNMi after making changes to the nms-disco.properties file.
If you need to delete all FDB-based layer 2 connections from the NNMi management server, run the following
command: nnml2maint.ovpl deleteAllFDBConnections. Look for the nnml2maint.ovpl script in
/opt/OV/support (UNIX) or %nnminstalldir%\support (Windows). You must run the nnml2maint.ovpl
script while NNMi is running.
After you install NNMi 9.1x patch 3, you can use the nnmcreateendpointpollingconfig.ovpl script to add custom attributes to connected interfaces that have endpoints being managed by different NNMi regional management servers. After you load these attributes on the regional NNMi management server or servers that manage the nodes containing the interfaces, you can create polling policies to manage these interfaces so that the global NNMi management station shows the connections correctly.
To configure this feature, do the following:
Do the following on each regional NNMi management server:
customAddrName = com.hp.nnm.capability.iface.forcePolled
or customAddrValue = Force Polled.This information pertains to NNMi configured with NNM iSPI Performance for Metrics, NNM iSPI Performance for Quality Assurance, or NNM iSPI Performance for Traffic. Prior to installing NNMi 9.1x patch 1, NNMi did not support assigning a user both administrator and client roles for NNMi Group Authentication. If you configured an NNMi user to have both roles, either remove that user or assign the user only one role.
For NNMi 9.1x and NNM iSPI customers in the Russian Federation, you might need to update NNMi due to changes in Russian Daylight Savings Time. See http://support.openview.hp.com/selfsolve/document/KM1254990 for more information.
If you have IPv6 discovery configured on NNMi, and are using the HP Universal CMDB (UCMDB) integration, the UCMDB HP Discovery and Dependency mapping (DDM) import task fails. You need to disable IPv6 discovery to use the UCMDB integration with NNMi.
If the need arises to uninstall all NNMi 9.1x patches from the NNMi management server, you must run the removepatchdata.ovpl script after the uninstall completes. This is necessary to revert post-patch-install data so that you can restart the unpatched NNMi successfully.
There is no need to run the removepatchdata.ovpl script in the following situations:
If you are installing NNMi 9.10 on a Linux NNMi management server (including both manual and silent installations), you must import the HP public key into the Linux RPM database before installing NNMi 9.10. To do this, follow the instructions at http://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=HPLinuxCodeSigning.
There is now an interactive version of the NNMi 9.10 installation guide located at http://support.openview.hp.com/selfsolve. You will need to supply your HP Passport credentials. To register for an HP Passport user ID, point your browser to the following URL: http://h20229.www2.hp.com/passport-registration.html.
When upgrading from NNMi 9.0x to NNMi 9.10 in an HA configuration, the secondary node might not successfully start up. To
avoid problems during startup on the secondary node, run the following command prior to starting the upgrade:
cluster res <APP resource> /props DeadlockTimeout=1800000
Substitute the actual value of the HA APP resource for the parameter <APP resource>. The APP resource name is available from the Failover Cluster Manager tool.
NNMi factory-installed automatic incident actions do not work on Linux NNMi management servers. To correct this, add the directory path $NnmDataDir/shared/nnm/actions to the $PATH environment variable for the user that runs ovstart.
The rateCorrelation Management Event does not support Enrichment or Suppression.
The Integration between HP NNMi and HP ArcSight currently intermittently drops Syslog messages flowing from Logger into NNMi through the Logger Forwarding NNMi Connector. It is highly recommended that you use TCP as the protocol for the communication between Logger and the Logger Forwarding NNMi Connector.
These are steps to add indexes to the database that improve GUI performance and resolves contention between parts of ovjboss. There is also a separate script to delete the indexes in the case of issues. While it is not necessary to stop ovjboss during this process, it is recommended that ovjboss be stopped in order to avoid potential database contention when adding or deleting the indexes. For App Failover customers, only the active node needs to have the fix applied.
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:
While very unlikely, it is possible that database corruption issues might exist due to the missing indexes. Applying the indexes might cause ovjboss to have problems resulting in with high CPU or very poor GUI performance if database corruption has occurred. To remove the indexes, do the following:
NNMi 9.1x Patch 1 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.
During upgrade from NNMi 9.0x to 9.10, on the HPUX platform only, the embedded database is upgraded from a 32-bit version to a 64-bit version. Prior to install, the database is backed up, using the NNMi 9.0 (32-bit) binaries. After install the database is re-loaded using the new (64-bit) binaries. This re-load fails if iSPIs are also installed on the same system.
The symptom is that when NNM is restarted after the upgrade, nothing is displayed in the UI and the database is "empty". If this problem occurs, contact HP Support to obtain a hotfix to fix this issue (QCCR1B87930).
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.
When using the Help > System Information > Component Versions menu to view component versions, NNMi shows the
Causal Engine Core component as version 09.00.010.031. This is incorrect, as NNMi contains Causal Engine Core component
version 09.10.000.031.
During an upgrade to NNMi 9.10, Custom Poller collections with threshold settings that contain either high or low thresholds, but not both or neither, do not migrate to the NNMi management server being upgraded. If this issue occurs during the upgrade, the upgrade script displays an error stating that the database schema was successfully upgraded, but that some configuration data might not have upgraded successfully. To avoid this issue, record the threshold settings for each of these Custom Poller collections before upgrading to NNMi 9.10, as they will be lost during the migration. After the migration, open each of these Custom Poller collections and re-enter the threshold values. When you re-enter the threshold values into NNMi 9.10, notice that the form is slightly different. Make sure to set the Threshold Setting Type to Count when re-entering the threshold values. Make sure to select the Enable Custom Poller selection box from the Custom Poller Configuration screen. Save your changes.
ovjboss.jvmargs fileDuring an upgrade from NNMi 9.0x to 9.10, one or more of the parameters contained in the
%NnmDataDir%\shared\nnm\conf\props\ovjboss.jvmargs (Windows) or $NnmDataDir/shared/nnm/conf/props/ovjboss.jvmargs (UNIX)
file are reverted back to their default values. Before upgrading to NNMi 9.10, save a copy of the ovjboss.jvmargs file. After
completing the upgrade, list the differences between the ovjboss.jvmargs file from the upgrade and the saved version of the
ovjboss.jvmargs file, then make the necessary changes to the ovjboss.jvmargs file from the upgrade.
Windows 2003 and Windows 2008 server offer a feature called Internet ESC (Explorer Enhanced Security Configuration) in Internet Explorer 8. After this feature is enabled (which is the case by default) all pop-up dialogs and windows are tested against a list of trusted sites. If the URL associated with the pop-up is not in the list of trusted sites, all of the controls in the dialog or window are disabled. For example, when this happens, clicking on the OK, Apply, and Cancel buttons will have no effect.
Generally, with ESC enabled, whenever the user opens a dialog, the user is prompted as to whether the URL associated with pop-up
should be allow as a trusted site. The user must allow the URL. If the user does not allow the URL, the dialog controls will not
work and the prompt will be seen whenever the dialog or window is opened. Eventually the nagging ceases because all important URLs will
have been added to the list of Trusted Sites. One special URL that must be placed in the list is about:blank.
It is possible for the user to get into a situation where the NNMi Console will not work. If, at some point, the user clicks
the Don’t show me this message again checkbox in the Trusted Sites prompt, subsequent prompts will not be issued. If the
user had done this before installing NNMi, the NNMi Console will hardly function. Dialogs will pop up, but the controls in the
dialog will not work. For example, if the user opens the Help->About dialog, the OK button will not close
the dialog. Also, all table view filter dialogs will not work. In the latter case, this is because the
about:blank URL is not in the list of Trusted Sites.
The are several ways to recover from this:
about:blank.The show mismatched connections functionality now enabled by the HP NNMi-HP NA integration no longer requires an NNM iSPI NET license. The NNM iSPI NET Planning and Installation Guide incorrectly says that an NNM iSPI NET license enables this functionality.