Concepts for Communications

NNMi uses SNMP and ICMP primarily in a request-response manner. Responses to ICMP ping requests verify address responsiveness. Responses to other management protocols, such as SNMP requests for specific MIB objects, provide more comprehensive information about a node.

Levels of Communication Configuration

NNMi communication configuration provides the following levels:

• Specific nodes
• Regions
• Global defaults

At each level you can configure access credentials, timeout and retry values, management protocol enablement (for example, for ICMP and SNMP), and management protocol access settings (for example, SNMP). If you leave settings blank at one level, NNMi applies the next level of defaults.

When communicating with a given node, NNMi applies the configuration settings as follows:

1. If the node matches a specific node configuration, NNMi uses any communication values in that configuration.
2. If any settings are not yet defined, NNMi determines whether the node belongs to any regions. Because regions might overlap, NNMi uses the matching region with the lowest ordering number. NNMi uses the values specified for that region to fill in the blanks left from the applicable specific node setting (if any). The settings for additional regions are not considered.
3. If any settings are still not yet defined, NNMi uses the global default settings to fill in the remaining blanks.

The values used for management protocol communication with a particular device might be built up cumulatively until all required settings are determined.

Network Latency and Timeouts

Normal network latency influences the amount of time the NNMi management server must wait to get answers to ICMP queries. Different areas of a network customarily have different turnaround times. For example, the local network where the NNMi management server resides could provide nearly instantaneous response, while responses from a device in a remote geographical region accessed through a dial-up wide area link would typically take much longer. In addition, heavily-loaded devices might be too busy to respond to ICMP queries immediately. When deciding which timeout and retry settings to configure, consider these latency concerns.

You can configure specific timeout and retry settings for both network regions and specific devices. The settings you choose determine how long NNMi waits for an answer and how many times NNMi requests data before abandoning the request when no answer is received.

For each request retry, NNMi adds the configured timeout value to the previous timeout value. Thus, the pause gets longer between each retry. For example, when NNMi is configured to use timeout of 5 seconds and three retries, NNMi waits 5 seconds for a response to the first request, 10 seconds for a response to the second request, and 15 seconds for a response to the third request before giving up until the next polling cycle.

SNMP Access Control

Communication with SNMP agents on managed devices requires access control credentials:

• SNMPv1 and SNMPv2c

  A community string in each NNMi request must match a community string configured in the responding SNMP agent. All communication passes through the network in clear text (no encryption).

• SNMPv3

  Communication with the SNMP agent complies with the user-based security model (USM). Each SNMP agent has a list of configured user names and their associated authentication requirements (the authentication profile). Formatting of all communication is controlled through configuration settings. NNMi SNMP requests must specify a valid user and follow the authentication and privacy controls configured for that user.

  • Authentication protocol uses hash-based message authentication code (HMAC) using your choice of either the message-digest algorithm 5 (MD5) or the secure hash algorithm (SHA).
  • Privacy protocol uses no encryption or the data encryption standard - cipher block chaining (DES-CBC) symmetric encryption protocol.

NNMi supports the specification of multiple SNMP access control credentials for a region of your network (defined through IP address filters or hostname filters). NNMi attempts communication with a device in that region by trying all configured values at a given SNMP security level in parallel. You can specify the minimum SNMP security level that NNMi uses in that region. NNMi uses the first value returned by each node (response from the device’s SNMP agent) for discovery and monitoring purposes.

Also see SNMP Access Control in High Availability (HA) Environments

SNMP Access Control in High Availability (HA) Environments

When NNMi is configured in a High Availability (HA) environment, the SNMP source address is set to a physical cluster node address. To set the SNMP source address to the NNM_INTERFACE (which is set to the virtual IP address), you must edit the ov.conf file and set the value for IGNORE_NNM_IF_FOR_SNMP to OFF. (By default, this setting is set to ON.)

To set the SNMP source address to the NNM_INTERFACE in HA environments:

1. Edit the following file on both nodes in the cluster:

   Windows: %NnmDataDir%\shared\nnm\conf\ov.conf

   Linux: $NnmDataDir/shared/nnm/conf/ov.conf

2. Set the value for IGNORE_NNM_IF_FOR_SNMP to OFF. (By default, this setting is set to ON.)

   IGNORE_NNM_IF_FOR_SNMP=OFF

3. Stop and restart the NNMi management server:

   Note Put the nodes in maintenance mode before running the ovstop and ovstart commands

   1. Run the ovstop command on the NNMi management server.
   2. Run the ovstart command on the NNMi management server.

SNMP Version Preferences

The SNMP protocol itself has evolved over the years from version 1 to version 2(c) and now version 3, with increasing security capabilities (among others). NNMi can handle any or a mix of all versions in your network environment.

The first SNMP response NNMi receives for a particular node determines the communication credentials and SNMP version used by NNMi for communication with that node.

You specify the minimum level of SNMP version and security settings that are acceptable in each area of your network. The options for the SNMP Minimum Security Level field are as follows:

• Community Only (SNMPv1 only)—NNMi attempts to communicate using SNMPv1 with the configured values for community strings, timeouts, and retries. NNMi does not try any SNMPv2c or any SNMPv3 settings.
• Community Only (SNMPv1 or v2c)—NNMi attempts to communicate using SNMPv2c with the configured values for community strings, timeouts, and retries. If there is no response to any community string using SNMPv2c, NNMi attempts to communicate using SNMPv1 with the configured values for community strings, timeouts, and retries. NNMi does not try any SNMPv3 settings.
• Community—NNMi attempts to communicate using SNMPv2c with the configured values for community strings, timeouts, and retries. If there is no response to any community string using SNMPv2c, NNMi attempts to communicate using SNMPv1 with the configured values for community strings, timeouts, and retries. If none work, NNMi tries SNMPv3.
• No Authentication, No Privacy—For users with no authentication and no privacy, NNMi attempts to communicate using SNMPv3 with the configured values for timeouts and retries. If none work, NNMi tries users with authentication and no privacy followed by users with authentication and privacy, if necessary.
• Authentication, No Privacy—For users with authentication and no privacy, NNMi attempts to communicate using SNMPv3 with the configured values for timeouts and retries. If none work, NNMi tries users with authentication and privacy.
• Authentication, Privacy—For users with authentication and privacy, NNMi attempts to communicate using SNMPv3 with the configured values for timeouts and retries.

Management Address Preferences

A node’s management address is the address NNMi uses to communicate with the node’s SNMP agent. You can specify the management address for a node (in the specific node settings), or you can let NNMi choose an address from the IP addresses associated with the node. You can fine-tune this behavior in the discovery configuration settings by excluding certain addresses from discovery. For information about how NNMi determines the management address, see Node Form in the NNMi help.

NNMi discovers and monitors devices on an ongoing basis. After the first NNMi discovery cycle, the Enable SNMP Address Rediscovery field controls NNMi behavior when previously discovered SNMP agents quit responding (for example, when you reconfigure the device’s SNMP agent).

• If the Enable SNMP Address Rediscovery check box is selected, NNMi retries any configured values in search of one that works.
• If the Enable SNMP Address Rediscovery check box is cleared, NNMi reports the device as “Down” and does not attempt to find another communication configuration setting for that device.

SNMPv3 Traps and Informs

When NNMi uses SNMPv3 to communicate with a device, it uses a discovery process to identify the Engine ID, boot count, and engine time of the device. NNMi then uses this information, along with the configured user and protocol details, to start sending messages to the device.

When the device sends a trap to NNMi, the device may not have the NNMi information, and because a trap is a single-packet transaction, it has no way to get the necessary information. Therefore, it uses its own Engine ID, boot count and engine time in the trap, along with the user name and protocol details. These device details must be the same as those configured for the device in NNMi. You cannot configure multiple SNMPv3 users per device in NNMi.

An inform is an acknowledged packet, so this is more like an SNMP request that NNMi would make to the device except, this time, it is the device initiating the first packet and NNMi responding with the acknowledgment. The device, therefore, performs the discovery to NNMi to learn NNMi’s Engine ID, boot count and engine time. The user name and protocol configuration that the device uses must match what is configured in the NNMi trap forwarding configuration—this is, in effect, NNMi’s SNMPv3 agent configuration.

Polling Protocols

You can prevent NNMi from using SNMP or ICMP in portions of your network (for example, when firewalls in your infrastructure prohibit ICMP or SNMP traffic).

Disabling ICMP traffic to the devices in an area of the network has the following results in NNMi:

• The optional auto-discovery rule ping sweep feature cannot locate additional nodes in that region of your network. All nodes must either be seeded or available through answers to MIB object requests, such as neighbor’s ARP cache, Cisco Discovery Protocol (CDP), or Extreme Discovery Protocol (EDP). Wide area network devices might be missed unless you seed every one of them.
• The State Poller cannot monitor devices that are not configured to respond to SNMP requests. (However, if the device responds to SNMP, State Poller does not use ICMP.)
• Operators cannot use Actions > Ping to check device reachability during troubleshooting.

Disabling SNMP traffic to the devices in an area of the network has the following results in NNMi:

• Discovery cannot gather any information about the devices except that they exist. All devices receive the No SNMP device profile.
• Discovery cannot find additional neighboring devices through queries. All devices must be directly seeded.
• Discovery cannot gather connectivity information from the devices, so they appear unconnected on NNMi maps.
• For devices with the No SNMP device profile, the State Poller respects the defaults of monitoring that device using only ICMP (ping).
• The State Poller cannot gather component health or performance data from the devices.
• The Causal Engine cannot contact the devices to perform neighbor analysis and locate the root cause of incidents.

Communication Configuration and the nnmsnmp*.ovpl Commands

The nnmsnmp*.ovpl commands look up the values for unspecified device communication settings in the NNMi database. This approach requires that the ovjboss process be running. If ovjboss is not running, the nnmsnmp*.ovpl commands behave as follows:

• For SNMPv1 and SNMPv2c agents, the commands use default values for any unspecified communication settings.
• For SNMPv3 agents, if you specify a user and password the commands use default values for any unspecified communication settings. If you do not specify a user and password, the commands fail.