Last Updated: 14 August, 2015
This document contains updates to the release notes for HP Network Node Manager i Software (NNMi) 9.2x. You can also check for online NNMi 9.2x support matrix updates or the device support matrix.
Other useful links include the following:
The following list contains NNMi 9.2x update information:
Path View or Smart Path doesn't work in a multi-tenant environment.
NNMi 9.2x supports the following versions of Red Hat Enterprise Linux Server:
When using Management Address Selection settings with an interface that has multiple IP addresses, NNMi now selects the management address based on ascending order of IP addresses, beginning with the lowest IP address.
Northbound integration is disabled under the limited capacity license. After a full license is installed, northbound integration can be re-enabled by reconfiguring a northbound destination.
Both NNMi management servers in an application failover cluster must have identical patch installations. You must always install the same patches in the same sequence on each NNMi management server in the cluster. For example, if you install NNMi 9.2x Patch 1, NNMi 9.2x Patch 2, and NNMi 9.2x Patch 3 on one NNMi management server, you must install NNMi 9.2x Patch 1, NNMi 9.2x Patch 2, and NNMi 9.2x Patch 3 on the other NNMi management server. Skipping the installation of 9.2x Patch 2 on the second NNMi management server will cause NNMi Cluster Setup Wizard errors.
If you use the NNMi MIB browser (Action > MIB Information > Browse MIB menu) to obtain information about a node, and provide an optional SNMP community string for that node, the NNMi MIB browser uses MIB browser parameters located in the nms-ui.properties file for MIB Browser SNMP communication. By default, the MIB browser will use SNMP v1 for communication (for commands such as nnmsnmpget.ovpl and nnmsnmpwalk.ovpl).
The NNMi online help incorrectly references the readonlynodegroupselector parameter.
When using URLs for direct access to various NNMi views, disable the node group selector in the views using the parameter readonlygroupselector NOT readonlynodegroupselector.
NNMi 9.23 (patch 3) now provides Custom Incident Attributes (CIAs) in the order of the original trap varbinds for traps received after applying the patch. You can observe the new CIA ordering in the NNMi console as well the Northbound Interface and NNMi SDK.
The NNMi Console displays an empty file when the Trap Analysis log is viewed using Tools → Trap Analytics → Trap Analysis Log. To resolve this issue, do the following:
ovstop command on the NNMi management server.%NnmInstallDir%\NNM\server\deploy\jboss-logging.xml/opt/OV/NNM/server/deploy/jboss-logging.xml<!-- trap analysis -->
<logger category="com.hp.ov.nms.trapd.TrapAnalysis" use-parent-handlers="false"><!-- trap analysis -->
<logger category="com.hp.ov.nms.trapd.WideTrapAnalysis" use-parent-handlers="false">ovstart command on the NNMi management server.The NNMi integration with BSM returns the following error message in the NNMi log if BSM 9.22 is configured for Smart Card authentication using SSL:
Exception occured attempting to connection to BSM server.: com.hp.ucmdb.api.CommunicationException: Got response code 403 for URL ...
If you require BSM 9.22 configured for Smart Card authentication using SSL, see
QCCR1B115394 on the HP Software Support online site.
If NNMi services running inside ovjboss start up slowly, the nnmaction process might stop shortly after it starts up. This is because nnmaction depends on certain event services in the NNMi ovjoss server, which continue to start up after ovjboss has completed its startup. The event services must be fully initialized for nnmaction to function normally. After nnmaction starts up, it monitors the event services, and if the event services are not fully initialized after a certain period of time, the nnmaction process exits. To resolve this issue, run the following from the command line to restart the nnmaction process:
ovstart -c nnmactionThe NNMi console might time out and report an error if you try to delete a node having a large number of interfaces. Before deleting the node, you must first unmanage the node regardless of method for deletion. After you successfully unmanage the node, delete the node using the NNMi console. Alternately, use the nnmnodedelete.ovpl script to delete nodes having a large number of interfaces. For more information, see the nnmnodedelete.ovpl reference page or UNIX manpage.
NNM9.22 (patch 2) includes changes to Lightweight Single Sign On (LW-SSO) that require several NNM iSPIs and integrations using LW-SSO to install a patch or hotfix in order for LW-SSO to continue to work with NNMi. Below is a table showing the NNMi iSPIs and the required hotfixes or patches:
| NNMi iSPI | Required Hotfix/Patch |
|---|---|
| NNM iSPI Performance for QA | HOTFIX_NNMISPI_QOS_9.21_2012-12-20_1B |
| NNM iSPI for IP Multicast | IP_MULTICAST_9.20_HOTFIX |
| NNM iSPI for IP Telephony version 9.20 | HOTFIX1_NNMISPI_IPT_920_OCT2012 |
| NNM iSPI for MPLS version 9.20 | HOTFIX_NNMISPI_MPLS_9.2_2012-11-21_1 |
| NNM iSPI Performance for Traffic version 9.20 | HOTFIX_NNMISPI_TRAFFIC_9.20.010_2013-03-20_1 |
Contact HP Support for information on how to obtain these hotfixes.
When creating filters for NNMi, pay special attention to the values returned by the SNMP Agent before applying your changes. For example, some SNMP agents might return
illegal characters for filterable attributes (such as returning null bytes for the ifDescr value). Generally, these illegal characters cause the filter to fail.
Filtering on null characters or non-Unicode characters might not work, as NNMi interprets each of these characters as the Unicode Replacement Character (such as
? at Unicode codepoint U+FFFD). If you encounter this problem, work with your SNMP Agent vendor to correct the instance of illegal characters when it does not
match the MIB specification.
Note: Illegal characters can be defined as a character that meets one of the following criteria:
You must configure non-global Solaris zones with extra privileges for some commands to work. If the zone only has default privileges, non-root users cannot use
the ping or traceroute commands. This is due to the default zone configuration not having certain privileges such as net_rawacces,
net_privaddr, or net_icmpaccess. To resolve this issue, do the following:
ppriv $$ command. net_rawaccessnet_privaddrnet_icmpaccess zonecfg –z <zone_name> zonecfg:<zone_name> set limitpriv=default,net_rawaccess
zonecfg:<zone_name> verifyzonecfg:<zone_name> commitzonecfg:<zone_name> exit zlogin <zone_name> shutdownzoneadm –z <zone_name> bootWhen upgrading an NNMi 9.0x NNMi management server to NNMi 9.2x, there are extra steps required if you configured the NNMi management server as follows:
protectedDomains values in the lwssofmconf.xml file.protectedDomains
values located in the lwssofmconf.xml file to the nms-ui.properties
file. You will find these files in the following locations:
%NnmDataDir%\shared\nnm\conf\lwssofmconf.xml%NnmDataDir%\shared\nnm\conf\props\nms-ui.properties$NnmDataDir/shared/nnm/conf/lwssofmconf.xml$NnmDataDir/shared/nnm/conf/props/nms-ui.propertiesIf you install an SNMP MIB Loader hotfix after applying NNMi 9.2x Patch 2 (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.
Created
Date and time the Node object instance was created. NNMi uses the locale of the client and the date and time from the NNMi management server.
NOTE: This value does not change when a node is rediscovered. This is because the Node object is modified, but not created.
Last Modified
Date and time the Node object instance was last modified. NNMi uses the locale of the client and the date and time from the NNMi management server.
Note the following:
HostNameMatchManagementIP property to falseIf you plan to upgrade an earlier version of NNMi 9.0x or NNMi 9.1x to NNMi 9.20, 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.
Before installing NNMi 9.21 (patch 1) on an NNMi management server configured with High Availability (HA), you must put both cluster members in Maintenance Mode.
The NNMi 9.21 Deployment Reference tells you to create a maintenance file to put these cluster members in maintenance mode.
However, when installing NNMi 9.21 (patch 1), maintenance is the wrong file name to use. To successfully put these cluster members into maintenance mode
before installing NNMi 9.21 (patch 1), create the following file:
%NnmDataDir%\hacluster\resource_group\maint_NNM$NnmDataDir/hacluster/resource_group/maint_NNMmaint_NNM
file, you must stop the resource group prior to installing NNMi 9.21 (patch 1).
Windows Only: Do not use the NNMi silent installation instructions on Windows servers configured for non-English locales. For Windows servers configured for non-English locales, you must install NNMi using the interactive installation wizard as described in the NNMi 9.20 Interactive Installation Guide.
If you plan to install HP NNMi on a server that has HP SIM installed, HP NNMi might cause port conflicts. Before installing and running HP NNMi on this
shared server, identify any ports being used by both HP NNMi and HP SIM. To remedy the port conflicts you identify, edit the nms-local.properties
file and make port configuration changes as described in the nnm.ports reference page. After you remedy these port conflicts, HP NNMi should run
with no port conflicts.
The standby node in an NNMi cluster can remain stuck in the standby state while it is trying to receive transaction logs from the active node. This can occur when the active node has recently generated a new database backup that took a long time to create, send to standby, or both. The standby has already acknowledged receipt of database transactions (through the continuous database updates sent through a separate socket), and the corresponding transaction log files, which are pending, have already been deleted from disk. The workaround is to run the “nnmcluster –dbsync” operation.
If the SNMP Minimum Security Level is set to "Community Only (SNMPv1)", the new community string priority feature fails. This causes exceptions in the log and the node is discovered as a non-SNMP node. To work around this problem, either do not set priority on the community strings or use the Regions tab to create regions for the nodes that have the same community string and use the Ordering attribute to set the priority on the region.
After upgrading to NNMi 9.20, some RAMS traps show IP address as Hex string in the NNMi Incident views. To workaround this problem, update the Incident Configuration for RAMS traps that are forwarded to NNMi:
"Path Change for $4 from src $5 to dest $16/$17
newMetric-$12 : newHops-$14 : oldMetric-$11 : oldHops-$13"
"Path Change for $4 from src $5 to dest $8/$9 newMetric-$12 : newHops-$14 :
oldMetric-$11 : oldHops-$13"
"Adjacency state Up in $4 for src $16 dest $18 srcType $13 destType $14"
"Adjacency state Up in $4 for src $5 dest $6 srcType $13 destType $14"
"Adjacency state Down in $4 for src $16 dest $18 srcType $13 destType $14"
"Adjacency state Down in $4 for src $5 dest $6 srcType $13 destType $14""Prefix $11/$12 Up announced by node $8"
"Prefix $5/$6 Up announced by node $8"
"Prefix $11/$12 Down announced by node $8"
"Prefix $5/$6 Down announced by node $8"