Integrate > Integrate NNMi with Network Automation

Integrate NNMi with Network Automation

Network Automation software (NA) is an enterprise-class network device change and configuration management tool. It eliminates human error in device configuration changes while also maintaining compliance standards through a policy-based change management model. NA maintains a complete audit trail of all device changes, including a key stroke log of command line changes made through the NA telnet proxy.

The NNMi–NA integration combines the NA configuration change detection capabilities with the NNMi network monitoring capabilities, placing more information at your fingertips when problems occur.

This topic includes the following sections:

Components of Integration

The NNMi–NA integration requires the following components:

  • NNMi 10.30
  • NA 10.30, 10.21

Prerequisite Tasks

  1. Install NNMi.
  2. Install NA.

  3. Configure secure communication between NNMi and NA.

    You can skip this procedure if you do not plan to use the HTTPS mode for the NNMi-NA communication.

    1. On the NA core server, export the NA certificates from the truecontrol.keystore file:

      • Windows: <NA_HOME>\jre\bin\keytool.exe -export -alias <alias> -file C:\temp\na.cer -keystore <NA_HOME>\server\ext\jboss\server\default\conf\truecontrol.keystore -storepass sentinel
      • Linux: <NA_HOME>/jre/bin/keytool -export -alias <alias> -file /tmp/na.cer -keystore <NA_HOME>/server/ext/jboss/server/default/conf/truecontrol.keystore -storepass sentinel

      In this instance, <alias> is the alias of the NA certificate. For the self-signed certificate, the alias is sentinel.

    2. Copy the NA certificate file (na.cer) that you created in the above step to the NNMi management server.

      If NNMi is installed in an application failover or HA cluster, copy the certificate to each node on the cluster.

    3. Import the NA certificate on the NNMi management server. Perform the following tasks on each node in an application failover or HA cluster.

      1. Check the NNMi certificate repository type:

        To check the type of certificate repository:

        1. Log on to the NNMi console.
        2. Click Help > System Information, and then go to the Server tab.

        3. Check the value of the javax.net.ssl.keyStore property.

          If the property points to the nnm-key.p12 file, your environment has a PKCS#12 repository.

          If the property points to the nnm.keystore file, your environment has a JKS repository.

        Alternatively, do the following:

        1. On the NNMi management server, as root or administer, run the following command:

          • On Windows: %nnminstalldir%\bin\nnmprops -l
          • On Linux: /opt/OV/bin/nnmprops -l

        2. From the command output, note the value of the javax.net.ssl.trustStoreType property.

          The value of this property indicates the type of certificate repository.

      2. Log on to the NNMi management server.

      3. Run the following command to import the NA certificate to the NNMi truststore.

        • For PKCS#12:

          • Windows:%NnmInstallDir%\bin\nnmkeytool.ovpl -import -alias <alias> -file "<certificate file directory>\na.cer" -keystore %NnmDataDir%\shared\nnm\certificates\nnm-trust.p12 -storetype PKCS12 -storepass ovpass
          • Linux:/opt/OV/bin/nnmkeytool.ovpl -import -alias <alias> -file <certificate file directory>/na.cer -keystore /var/opt/OV/shared/nnm/certificates/nnm-trust.p12 -storetype PKCS12 -storepass ovpass

        • For JKS:

          When you use a JKS repository, you must use the keytool utility of the JDK that is configured to work with NNMi. The keytool utility is available in the bin directory under the home directory of the JDK.

          For easy access to the keytool utility:

          1. Determine the home directory of the JDK . The value of the com.hp.ov.nms.jdk.dir property in the nms-local.properties file indicates the directory path.

            The nms-local.properties file is available in the following directory on the NNMi management server:

            • On Windows: %nnmdatadir%\conf\nnm\props
            • On Linux: /var/opt/OV/conf/nnm/props

          2. Create an environment variable that points to the bin directory under the JDK home directory.

            For example, if the com.hp.ov.nms.jdk.dir property in above step shows /opt/OV/nonOV/jdk/zulu/zulu8.21.0.1-jdk8.0.131-linux_x64, set a new environment variable—for example, NNMi_JDK_BIN— that points to the /opt/OV/nonOV/jdk/zulu/zulu8.21.0.1-jdk8.0.131-linux_x64/bin directory.

          After setting the NNMi_JDK_BIN variable, run the following command:

          • Windows: %NNMi_JDK_BIN%\keytool.exe -import -alias <alias> -file "<certificate file directory>\na.cer" -keystore %NnmDataDir%\shared\nnm\certificates\nnm.truststore -storepass ovpass
          • Linux: $NNMi_JDK_BIN/keytool -import -alias <alias> -file <certificate file directory>/na.cer -keystore /var/opt/OV/shared/nnm/certificates/nnm.truststore -storepass ovpass

        In this instance, <alias> is the alias of the NA certificate. For the self-signed certificate, the alias is sentinel.

        Make sure you answer yes when asked whether to trust this certificate. The following text is an example of the output that appears after you run this command.

        Owner: CN=localhost, OU=Software Company, O=Software Company, L=Sunnyvale, ST=CA, C=US
        Issuer: CN=localhost, OU=Software Company, O=Software Company, L=Sunnyvale, ST=CA, C=US
        Serial number: 484e9d84
        Valid from: Tue Jun 10 09:28:04 MDT 2008 until: Fri Jun 08 09:28:04 MDT 2018
        Certificate fingerprints:
        MD5: 65:94:D1:A0:44:84:E2:69:A4:23:DC:B9:5E:EB:91:A8
        SHA1: 05:DE:DC:68:58:45:CA:EA:88:FF:16:05:E7:65:A9:5B:23:29:D7:65
        Trust this certificate? [no]: yes
        Certificate was added to keystore

    4. Run the following command to restart NNMi:

      1. ovstop -c
      2. ovstart -c

    5. On the NNMi management server, run the following command to determine the alias of the NNMi certificate:

      • For PKCS#12:

        • Windows:%NnmInstallDir%\bin\nnmkeytool.ovpl -v -list -keystore%NnmDataDir%\shared\nnm\certificates\nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass
        • Linux:/opt/OV/bin/nnmkeytool.ovpl -v -list -keystore /var/opt/OV/shared/nnm/certificates/nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass

      • For JKS:

        • Windows: %NNMi_JDK_BIN%\keytool.exe -v -list -keystore %NnmDataDir%\shared\nnm\certificates\nnm.keystore -storepass nnmkeypass
        • Linux: $NNMi_JDK_BIN/keytool -v -list -keystore /var/opt/OV/shared/nnm/certificates/nnm.keystore -storepass nnmkeypass

    6. Export the NNMi certificate to a file (nnm.cer) by using the following command:

      • For PKCS#12:

        • Windows:%NnmInstallDir%\bin\nnmkeytool.ovpl -v -list -keystore%NnmDataDir%\shared\nnm\certificates\nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass
        • Linux:/opt/OV/bin/nnmkeytool.ovpl -v -list -keystore /var/opt/OV/shared/nnm/certificates/nnm-key.p12 -storetype PKCS12 -storepass nnmkeypass

      • For JKS:

        • Windows: %NNMi_JDK_BIN%\bin\keytool.exe-export -alias <nnmi_alias> -file <directory>\nnm.cer -keystore %NNMDataDir%\shared\nnm\certificates\nnm.keystore -storepass nnmkeypass
        • Linux: $NNMi_JDK_BIN/keytool -v -list -keystore /var/opt/OV/shared/nnm/certificates/nnm.keystore -storepass nnmkeypass
    7. Copy the NNMi certificate file (nnm.cer) to each NA core server.

    8. On each NA core, import the NNMi certificate to the truecontrol.truststore file by running the following command:

      • Windows: <NA_HOME>\jre\bin\keytool.exe -import -alias <nnmi_alias> -file <Directory>\nnm.cer -keystore <NA_HOME>\server\ext\jboss\server\default\conf\truecontrol.truststore -storepass sentinel
      • Linux: <NA_HOME>/jre/bin/keytool -import -alias <alias> -file <Directory>/nnm.cer -keystore <NA_HOME>/server/ext/jboss/server/default/conf/truecontrol.truststore -storepass sentinel

      Make sure you answer yes when asked whether to trust this certificate.

    9. On each NA core server, restart the NA services:

      • Windows:

        Open the Services control panel. In the list of services, right-click each of the following services, and then click Restart:

        • TrueControl ManagementEngine
        • TrueControl FTP Server
        • TrueControl SWIM Server
        • TrueControl Syslog Server
        • TrueControl TFTP Server

      • Linux:

        Run the following command:

        /etc/init.d/truecontrol restart

  4. Decide which managed nodes to synchronize to NA. If you do not want to synchronize the complete NNMi inventory with NA, create one node group containing the nodes to synchronize with the NA inventory.

  5. Verify and make sure the following limitations do not apply to your environment:

    • The NNMi–NA integration does not support devices using IPv6 addresses as management addresses or dual-stacked devices with the SNMP management address preference set to IPv6.
    • The NNMi–NA integration cannot distinguish among duplicate IP addresses. For this reason, the integration is not supported in overlapping address domain (OAD) environments.

  6. The integration can synchronize NNMi security groups to NA partitions. Before enabling this feature, do all of the following:

    • Prepare a user security plan and evaluate the user security implications of enabling the mapping of NNMi security groups to NA partitions.

    • Ensure that each NNMi node is in the correct security group.

    • In NA, configure which NA users can see which of the NA partitions that map to the NNMi security groups.

Enable the Integration

To enable the NNMi–NA integration:

  1. Create NA device password rules for the nodes in the NNMi inventory. In the NA console, follow these steps:

    1. Open the Device Password Rule page (Devices > Device Tools > Device Password Rules).
    2. Create one or more device password rules that specify how to communicate with the nodes in the NNMi inventory.
  2. Note the number of devices in the NA inventory.

  3. In the NNMi console, configure the connection from NNMi to NA:

    1. Open the NNMi–NA Integration Configuration form (Integration Module Configuration >  NA).
    2. Select the Enable Integration check box to make the remaining fields on the form available.
    3. Optional. Select NNMi SSL, NA SSL, or both.

    4. Type the information for connecting to this NNMi management server.

      The following table lists the parameters for connecting to the NNMi management server from NA. You can determine many of these values by examining the URL that invokes an NNMi console session. Coordinate with the NNMi administrator to determine the appropriate values for this section of the configuration form.

      Table: NNMi Management Server Information in the NNMi Console

      Field

      Description

      NNMi SSL
      NA SSL

      For SSL communication, verify that you exchanged certificates in step 2 before selecting either of these check boxes.

      NNMi User

      The user name for connecting to the NNMi web services. This user must have the NNMi Web Service Client role.

      NNMi Password

      The password for the specified NNMi user.

    5. Type the information for connecting to an NA core.

      The following table lists the parameters for connecting to the NA core server.

      Table: NA Core Server Information in the NNMi Console

      NA Core Server Parameter

      Description

      NNMi SSL
      NA SSL

      Select these check boxes if you want to use HTTPS communication between NNMi and NA.

      NA Host

      The FQDN or the IP address of the NA core server.

      NA Port

      The port for connecting to the NA web services.

      NA User

      A valid NA user account name with the NA Administrator role.

      NA Password

      The password for the specified NA user.

    6. Specify values for the remaining fields.

      • In an NNMi multi-tenancy environment, clear the Topology Filter Node Group field and select the Map NNMi Security Groups to NA Partitions check box.
      • In other environments, set these field according to your needs.

      The following table lists the NNMi console parameters for configuring the behavior of the NNMi–NA integration.

      Table: Integration Behavior Information in the NNMi Console

      Parameter

      Description

      Topology Filter Node Group

      The NNMi node group containing the set of nodes to synchronize with the NA inventory. The integration populates the NA inventory with information about every node in this node group.

      Select the node group from the list of node groups on this NNMi management server. The default selection is the Networking Infrastructure Devices node group.

      If no node group is specified, the integration synchronizes the entire NNMi inventory into the NA inventory.

      Topology Synchronization Interval (hrs)

      The frequency with which NNMi performs a complete inventory synchronization with NA. The default interval for the connection check is 24 hours.

      To disable periodic inventory synchronization, set this value to 0.

      Discover Device Drivers in NA

      The NA configuration specification.

      If the Discover Device Drivers in NA check box is selected, NA automatically discovers the device drivers for the devices added to NA as a result of inventory synchronization with NNMi. The default setting is selected.

      When the Discover Device Drivers in NA check box is cleared, you can initiate device driver discovery manually. If the NA inventory already contains the NNMi inventory, the integration does not need to discover device drivers again.

      Map NNMi Security Groups to NA Partitions

      If the Map NNMi Security Groups to NA Partitions check box is selected, a device synchronized from NNMi to NA is always added or updated to an NA partition of the same name as the NNMi security group that contains the node.

      If the Map NNMi Security Groups to NA Partitions check box is not selected (the default), the NNMi nodes not currently in the NA inventory are added the NA Default Site partition and NNMi nodes currently in the NA inventory remain in the partition assigned in NA.

      If the Topology Filter Node Group field specifies a node group, it is possible that only some nodes in each NNMi security group are synchronized to the corresponding NA partition. To synchronize the entire NNMi inventory to the NA inventory, clear the Topology Filter Node Group field.

      NA Connection Check Interval (hrs)

      The frequency with which NNMi verifies with NA the interface data for all layer 2 connections in the NNMi topology. The default interval for the connection check is 24 hours.

      To disable the periodic connection check, set this value to 0.

      Minimum NNMi Role for Analysis Pane Data

      The NNMi access level for viewing NA information in the NNMi analysis pane. The available options for the Minimum NNMi Role for Analysis Pane Data field are as follows:

      • Disable Feature: Disables NNMi from showing NA data in the NNMi analysis pane.
      • NNMi Administrators: Shows NA data in the NNMi analysis pane to NNMi users having the Administrator role.
      • NNMi Level 2 Operators: Shows NA data in the NNMi analysis pane to NNMi users having the Operator Level 2 or Administrator role.
      • NNMi Level 1 Operators: Shows NA data in the NNMi analysis pane to NNMi users having the Operator Level 1, Operator Level 2, or Administrator role.
      • NNMi Guest Users: Shows NA data in the NNMi analysis pane to all NNMi users.

      Minimum Object Access Privilege for Analysis Pane Data

      The NNMi object access level for viewing NA information in the NNMi analysis pane. The available options for the Minimum Object Access Privilege for Analysis Pane Data field are as follows:

      • Object Administrator: Shows NA data in the NNMi analysis pane to NNMi users having the Object Administrator privilege for the NNMi node.
      • Object Operator Level 2: Shows NA data in the NNMi analysis pane to NNMi users having the Object Operator Level 2 or Object Administrator privilege for the NNMi node.
      • Object Operator Level 1: Shows NA data in the NNMi analysis pane to NNMi users having the Object Operator Level 1, Object Operator Level 2, or Object Administrator privilege for the NNMi node.
      • Object Guest: For all NNMi nodes, shows NA data in the NNMi analysis pane to all NNMi users who pass the minimum role filter. If security groups are not configured in NNMi, select this option.
      Activate/Deactivate Device in NA

      If you select this option, the integration controls the management status of the devices in NA. That is:

      • When a node is re-seeded in NNMi, the integration manages the corresponding device in NA.
      • When a synchronized node is deleted from NNMi , the integration stops managing the corresponding device in NA.

      If you clear this option, , the integration does not control the management status of the devices in NA. That is:

      • When a synchronized node is deleted from NNMi, the integration does not deactivate the corresponding device in NA.
      • When a synchronized node is re-seeded in NNMi, the integration does not activate the corresponding device in NA.

      This option is selected by default.

    7. Click Submit at the bottom of the form.

      A new window displays a status message. If the message indicates a problem with connecting to the NA core server, click Return, and then adjust the values for connecting to the NA core server as suggested by the text of the error message.

  4. If the NA menu items are not available on the NNMi consoleActions menu, log out of the NNMi console, and then log back in.

  5. Optional. Wait for initial inventory synchronization to complete.

    Compare the number of nodes in the NNMi inventory with the number of devices in the NA inventory. The number of devices in the NA inventory should increase relative to the number of nodes in the NNMi inventory (or in the NNMi topology filter node group) that were not already in the NA inventory before integration.

  6. Optional. In the NA console, follow these steps:

    1. Open the Administrative Settings - NA/NNMi Integration page (Admin > Administrative Settings > NA/NNMi Integration).

    2. Change the selections for any of the fields on this page:

       

      Field

      Description

      Tasks That Place Device Out-of-Service

      The NA tasks that request NNMi to place the device out-of-service. NNMi does not generate incidents for out-of-service devices. After the task completes, the integration waits for the time shown in the Out-of-Service Completion Delay field and then requests NNMi to resume managing the device.

      The NA tasks for which the integration sets a device to the DISABLED state while the task occurs. The default selections are:

      • Update Device Software
      • Deploy Passwords
      • Reboot Device

      To disable this feature, clear all selections from the task list.

      If the device task fails

      The device task failure recovery specification for out-of-service events. The default setting is to return the device to service in NNMi.

      If device compliance check fails

      The device compliance check failure recovery specification for out-of-service events. The default setting is to return the device to service in NNMi.

      The device compliance check is only available for the NA Ultimate or NOM Ultimate license.

      Out-of-Service Completion Delay

      The delay (in minutes) between completion of a task that placed a device out-of-service and restoring the NNMi device management mode. This delay provides time for devices to recover after NA completes the task.

      The default value is 10 minutes. The maximum value is 1440 minutes (24 hours).

      To change the maximum value, add the nnm/integration/max_out_of_service_delay option to the NA adjustable_options.rcx file.

      Tasks That Request NNMi Config Poll

      The NA tasks for which the integration triggers an NNMi device discovery on task completion. The default selections are:

      • Update Device Software
      • Deploy Passwords
      • Reboot Device
      • Discover Driver
    3. Click Save.

  7. Optional. Configure single sign-on.

    To be able to seamlessly switch between NNMi and NA, it is recommended that you configure single sign-on. To configure single sign-on between NNMi and NA:

    1. Open the following file in a text editor:

      • Windows:%NNM_PROPS%\nms-ui.properties
      • Linux:$NNM_PROPS/nms-ui.properties

    2. Look for a section in the file that resembles the following:

      com.hp.nms.ui.sso.isEnabled =

      Make sure the com.hp.nms.ui.sso.isEnabled property is set to true.

    3. Search for the string initString.

      The initialization string is the value of the initString parameter without the quotation marks.

    4. Copy this string.

    5. On each NA core, follow these steps:

      1. Open the following file in a text editor:

      2. In the enableLWSSO tag, set the enableLWSSOFramework attribute to true:

        enableLWSSOFramework="true"
      3. In the lwssoValidation block, set the value of the domain tag to the full domain name of the NA core server. For example, if the host name of the NA core server is na.location.example.com, set <domain>location.example.com</domain>.
      4. If NNMi and NA are not in the same domain, you must add a DNSDomain element for the NNMi management server’s domain to the trustedHosts block.

      5. In the crypto tag, verify or set the initString attribute to the value of the initString property in the NNMi nms-ui.properties file (copied in step d).

      6. In the trustedHosts block, set the DNSDomain tag to the value of the domain tag in the lwssoValidation block; for example: <DNSDomain>location.example.com</DNSDomain>.

      7. If NNMi and NA are not in the same domain, remove the <!-- and --> characters shown in the following example, and then add DNSDomain entries for both domains:

        <multiDomain>
        <trustedHosts>
        <!--
        <DNSDomain>gmx.com</DNSDomain>
        <DNSDomain>companydomain2.com</DNSDomain>
        <NetBiosName>myserver</NetBiosName>
        <IP>192.168.12.13</IP>
        <FQDN>myserver.companydomain.com</FQDN>
        -->
        </trustedHosts>
        </multiDomain>
      8. In the NA console, on the Admin > Start/Stop Services page, restart the Management Engine.

Use the Integration

With this integration, you can extend NNMi to perform the following additional tasks:

Use new Action Menu Items

  1. Log on to the NNMi console.

  2. The following new items appear in the Actions menu:

    • Show NA Diagnostic Results—Displays a list of the NA tasks that have been scheduled for the device in an NNMi incident. Select a task to view the task results.
    • Rerun NA Diagnostics—Runs any NA actions that are configured for the device in an NNMi incident.

    • Show mismatched connections—Displays a table of all layer 2 connections with possible speed or duplex configuration differences.

      When the NNMi– NA integration is enabled, NNMi periodically queries NA for the speed and duplex settings of the two interfaces on either end of each layer 2 connection in the NNMi topology. Additionally, NNMi queries NA for the speed and duplex settings of the interfaces for any new connection added to the NNMi topology and, when the NNM iSPI Performance for Metrics is running, for any connection with performance threshold exceptions that might indicate a mismatched connection. NNMi uses a mismatch detection algorithm to determine whether the values might result in a mismatched connection.

      NNMi can perform the mismatch analysis only when the NA inventory includes the MAC addresses for both interfaces that form a layer 2 connection. Therefore, if the NA interface records do not include valid MAC addresses, run the NA Topology Data Gathering diagnostic to update the MAC address fields. For devices that use the same MAC address for multiple ports, enable storing duplicate MAC addresses in NA.

      In the NNMi console, click Actions > Show mismatched connections to view a table of all mismatched connections, which includes speed mismatches, duplex mismatches, or both speed and duplex mismatches.

      • POSSIBLE_MISMATCH indicates that the speed values, the duplex values, or both speed and duplex values might conflict, resulting in a poor or non-performing connection.
      • MISMATCH indicates that the speed values, the duplex values, or both speed and duplex values most likely conflict, resulting in a poor or non-performing connection.
    • View NA Device Information—Opens the current NA Device Details page for the device selected in NNMi.

    • View NA Device Configuration—Opens the NA Current Configuration page for the device selected in NNMi.

      If real-time change detection is disabled for a device, the information shown is the configuration NA captured at the last device polling interval. If configuration changes were made following that capture, the information on the Current Configuration page might not be the actual current configuration.

    • View NA Device Configuration Diffs—Opens the NA Compare Device Configuration page for the device selected in NNMi.
    • View NA Device Configuration History—Opens the NA Device Configurations History page for the device selected in NNMi.
    • View NA Policy Compliance Report—Opens the NA Policy, Rule and Compliance Search Results page for the device selected in NNMi.
    • Telnet to NA Device—Opens a Telnet window for connecting to the device selected in NNMi.
    • SSH to NA Device—Opens an SSH window for connecting to the device selected in NNMi.
    • Launch NA—Opens the NA console.
    • Launch NA Command Scripts—Opens the New Task—Run Change Plans page in NA. The page is pre-filled for the node or incident selected in the NNMi console.
    • Launch NA Diagnostics—Opens the New Task—Run Diagnostics page in NA. The page is pre-filled for the node or incident selected in the NNMi console.

View NA details in the NNMi analysis pane

The NNMi analysis pane contains NA information for nodes and for interfaces on nodes synchronized through the NNMi– NA integration. The following table lists the NNMi views that can include the integration-provided analysis pane tabs.

NNMi View Analysis Pane Tab Name
  • Node inventory view
  • Node details form

  • Node Configuration

  • History of Node Configuration

  • Node Policy Compliance (requires the NA Ultimate or NOM Ultimate license)
  • Incident browsing view
  • Incident form
  • Node Configuration
  • History of Node Configuration
  • Interface inventory view
  • Interface details form
 Interface Configuration
  • Incident browsing view
  • Incident form
 Interface Configuration

The following table provides details of each NA-specific tab in the Analysis pane:

Tab Name Description
Node Configuration

The Node Configuration tab displays the current running configuration of the node.

The Node Configuration tab is available in the Analysis pane for the following NNMi views:

  • Node inventory view
  • Node details form for a synchronized node
  • Incident browsing view
  • Incident form for an incident related to a synchronized node

The tab is also available with the following incident types:

  • AddressNotResponding
  • NodeDown
  • NodeOrConnectionDown
  • SNMPv1 NA Config trap
  • SNMPv2 NA Config trap
  • BackplaneOutOfRangeOrMalfunctioning
  • BufferOutOfRangeOrMalfunctioning
  • CpuOutOfRangeOrMalfunctioning
  • DiskOutOfRangeOrMalfunctioning
  • MemoryOutOfRangeOrMalfunctioning
  • NodeTraffic
  • RoundTripTimeHigh
  • TestFailed
History of Node Configuration

The History of Node Configuration tab displays a table of times that the node configuration changed.

The History of Node Configuration tab is available for the following NNMi views:

  • Node inventory view
  • Node details form for a synchronized node
  • Incident browsing view
  • Incident form for an incident related to a synchronized node

The tab is also available with the following incident types:

  • AddressNotResponding
  • NodeDown
  • NodeOrConnectionDown
  • SNMPv1 NA Config trap
  • SNMPv2 NA Config trap
  • BackplaneOutOfRangeOrMalfunctioning
  • BufferOutOfRangeOrMalfunctioning
  • CpuOutOfRangeOrMalfunctioning
  • DiskOutOfRangeOrMalfunctioning
  • MemoryOutOfRangeOrMalfunctioning
  • NodeTraffic
  • RoundTripTimeHigh
  • TestFailed
Node Policy Compliance (requires the NA Ultimate or NOM Ultimate license)

The Node Policy Compliance tab displays a table of the active configuration policies that apply to the node with an indication of whether the node is in compliance with each policy.

Possible values for the In Compliance column in this tab are as follows:

  • Yes—The device’s configuration is in compliance with all applicable policies.
  • No—The device’s configuration is not in compliance with one or more applicable policies.
  • Unknown—No policies have been run against the device or an applicable policy contains an error. This value corresponds to the Not checked yet value in the output of the show policy compliance command in the NA API.

The Node Policy Compliance tab is available for the following NNMi views:

  • Node inventory view
  • Node details form for a synchronized node
Interface Configuration

The Interface Configuration tab displays the current running configuration of the interface as determined from the device configuration.

The Interface Configuration tab is available for the following NNMi views:

  • Interface inventory view
  • Interface details form for an interface on a synchronized node
  • Incident browsing view
  • Incident form for an incident related to an interface on a synchronized node

 

The Interface Configuration tab is available for the following NNMi views:

  • Interface inventory view
  • Interface details form for an interface on a synchronized node
  • Incident browsing view
  • Incident form for an incident related to an interface on a synchronized node

View the result NA diagnostics triggered by NNMi

Enabling the integration modifies some out-of-the-box NNMi incidents to include incident actions that access NA diagnostics each time the associated incident type occurs. The following table lists the NNMi incidents that trigger NA diagnostics:

NNMi Incident NA Diagnostic
OSPFNbrStateChange Show Neighbor
OSPFVirtIfStateChange Show Neighbor
OSPFIfStateChange

Show Neighbor

Show Interfaces
InterfaceDown Show Interfaces
CiscoChassisChangeNotification Show Module

Configure NA Diagnostics and Change Plans as Incident Actions

You can add an action in an NNMi incident to NA. You can modify the default incident actions. To use this funtion:

  1. In the NNMi console, go to the Actions tab for an incident.
  2. Add a new lifecycle transition action with Command Type of ScriptOrExecutable.
  3. In the Command text box, type either naruncmdscript.ovpl or narundiagnostic.ovpl with the appropriate arguments.

Launch the NNMi Console from the NA Console

The integration provides links to open NNMi console pages from the NA console.

On the Device Details page, the NNMi Associations table includes the following links for each NNMi management server that manages the device:

  • NNMi server—Opens the NNMi console to the initial view for this NNMi management server.
  • NNMi node UUID—Opens the NNMi console to the Node form for this device.

On the Administrative Settings - NA/NNMi Integration page, each value in the NNMi Server column of the Integration Server List is a link to the NNMi console.

Send SNMP Traps from NA to NNMi

The integration configures NA to send SNMP traps to NNMi when specified NA events occur for synchronized NA devices. The NNMi operator can see these traps in the incident views and investigate the changes if necessary.

In NNMi, the NASnmpTrapv1 and NASnmpTrapv2 incident types control the format of the NA trap messages in the NNMi incident views. Enabling the integration adds these incident types to the SNMP trap configurations available in NNMi.

In NA, the NA/NNMi Integration using SNMP Traps (NNMi Server) event rule determines the NA events that cause NA to send SNMP traps to NNMi. Additionally, this event rule determines the community string in the traps, SNMP version of the traps, and to which NNMi port NA sends the traps.

The integration adds one of these event rules for each NNMi management server. The default configuration of the NA/NNMi Integration using NNMi's SNMP Traps event rule is as follows:

  • NA sends SNMP traps for device configuration changes only.
  • The traps contain the community string that NA uses to access the device.
  • The traps use SNMPv1 format.
  • The traps are sent to port 162 on the NNMi management server.

You can customize the event rule to be different for each NNMi management server integrated with NA.

To change the configuration of the NA/NNMi Integration using SNMP Traps event rule for the integration with one NNMi management server, follow these steps:

  1. In the NA console, open the Event Notification & Response Rule page (Admin > Event Notification & Response Rule).
  2. In the row for the NA/NNMi Integration using SNMP Traps event rule for the NNMi management server, select Edit.

  3. On the Edit Event Notification & Response Rule page, make any of the following changes:

    1. In the When the Following Events Occur field, select the NA events that should cause NA to send SNMP traps to NNMi.

      NA sends SNMP traps only for NA events that are associated with a device. This field includes events that are not specific to a device, for example: User Added. NA ignores these non-device events.

    2. Set the SNMP Trap Receiver Port field to the value for the NNMi management server.

    3. Set the SNMP Community String field to the value to include in traps to this NNMi management server.

    4. Set the SNMP Version field to either SNMPv1 or SNMPv2.

    Do not change any other settings in the event rule configuration.

  4. Click Save.

To prevent NA from sending SNMP traps to an NNMi management server, set the rule status to inactive for the NA/NNMi Integration using SNMP Traps event rule for that NNMi management server.

Trigger NNMi Node Config Polls from NA

For certain device configuration tasks, after the task completes, NA triggers node rediscovery on the NNMi management servers that manage the device. This node rediscovery ensures that NNMi maintains accurate information about the device.

In the NA console, the Tasks that Request NNMi Config Poll field on the Administrative Settings - NA/NNMi Integration page specifies the device configuration tasks that trigger NNMi to rediscover a device. The default selections are:

  • Update Device Software
  • Deploy Passwords
  • Reboot Device
  • Discover Driver

You can select any or all of the following additional tasks:

  • Deploy Change Plan
  • Run Diagnostics
  • Delete ACLs
  • Configure Syslog
  • Run ICMP Test
  • Take Snapshot
  • Synchronize Startup and Running
  • OS Analysis

To prevent NA from triggering node config polls in NNMi, set the rule status to inactive for the NA/NNMi Integration Rediscover Host event rule.

To disable an NA event rule, follow these steps:

  1. In the NA console, open the Event Notification & Response Rule page (Admin > Event Notification & Response Rule).
  2. In the row for the NA event rule, select Edit.
  3. On the Edit Event Notification & Response Rule page, set the Rule Status to Inactive.
  4. Click Save.

Disable the Integration

To disable the integration, follow these steps:

  1. In the NNMi console, open the NNMi–NA Integration Configuration form (Integration Module Configuration >  NA).
  2. Clear the Enable Integration check box.
  3. Click Submit.

Send Help Center feedback