Configuring SNMP community names in NNMi
To configure SNMP community names in NNMi, go to the Configuration workspace and select Communication Configuration...:
In the main window, you can set the following parameters:
- Enable SNMP Address discovery.
- SNMP timeout:
The time that determines how long NNM should wait for the SNMP
messages' reply (in milliseconds). Maximum timeout can be 59 seconds
and 999 milliseconds.
- SNMP retry count:
It describes how many times NNMi should try sending packets if timeout
comes. If zero is set, then no retries will be initiated.
- SNMP port: Default is port 161. You can change it if required.
- SNMP proxy address and port: If SNMP proxy is used to reach a device, then you need to set SNMP proxy address and port number for communication.
- SNMP minimum security level:
Here you can set which security level NNMi should consider while
communicating with a node. SNMP version preferences are given in the
- ICMP timeout:
Represents how long NNM should wait for ICMP messages reply (in
milliseconds). Maximum timeout can be 59 seconds and 999 milliseconds.
- ICMP retries count:
It describes how many times NNMi should try sending packets after SNMP
timeout. If zero is set, then no retries will be initiated.
Your network devices may support various versions of SNMP, starting
from v1, v2c, and SNMPv3. You can set the minimum security level that
is acceptable to NNMi. However, if you set your minimum security level,
NNMi makes queries and automatically selects appropriate security
levels using the following assumptions:
- If there is one or more SNMP community strings configured, use SNMPv2 for communication.
- If no response was received, use SNMPv1.
- If there are one or more SNMPv3 users configured, security level is selected by following rules:
- Use No Authentication, No Privacy if any users are configured.
- Use Authentication, No Privacy if any users are configured.
- Use Authentication, Privacy if any users are configured.
- If no
SNMP response was received, the device is not discovered. The NNMi
administrator can override this and the device would be discovered with
NO SNMP profile.
Be careful with timeouts and retry counts, as timeout is doubled for
every subsequent retry. You may have polling loops with slow networks
or accidental network bottlenecks. For example, if you set timeout for
2 seconds and retry count 3, the first packet sent will have a 2 second
timeout. If it doesn't respond, the second packet will have a 4 second
timeout, and the third will have 8 seconds. So, there is a total 14
The community name order in the Default Community Settings
doesn't matter. NNMi takes all names simultaneously and the community
name, which responds to the query, is selected as primary for that
A large number of default SNMP communities will affect the performance in a negative way.
The right part of the window has SNMP configuration tabs for node specific, zone, and default SNMP community configuration.
When the initial discovery is completed, it's good practice to check
whether all devices were discovered and if the correct information is
shown in NNMi. This may happen, because of several reasons:
- Device is not accessible: Firewall or access lists blocks traffic, device is down, routing issues
- Device cannot communicate with NNMi: Device is wrong or does not have SNMP configured, wrong SNMP settings on NNMi
- Neighbor device is not configured properly: That is, wrong or missing SNMP settings
First of all, you can check if all nodes have SNMP configured properly by selecting Inventory View | filter Device Profile column and check if you have any No SNMP records. If so, do one (or both if needed) of the following:
- Configure SNMP settings on NNMi
- Check if managed device has SNMP configured and have connectivity
Here is a list of symptoms, which may help to troubleshoot:
- Device not discovered:
- Check if the device is accessible by ICMP
- Check if the device is accessible by SNMP
- Check if the correct SNMP settings are configured
- Check if the neighbor device is discovered properly
- Device is shown as generic:
- Check whether the device is accessible by SNMP
- Check if the device has SNMP configured properly
The following diagram represents the SNMP communication troubleshooting workflow:
You can take control over the network load configuring polling cycles.
If your firewall is blocking the communication to some of your devices, you can do one of the following:
- Talk to the security personnel and agree to open the required ports, so that you could monitor devices blocked by the firewall
- Configure NNMi to exclude these nodes from the discovery and status polling scope
This is recommended to avoid poller polling unreachable devices and
improving poller performance in that way. There are two protocols you
can disable for specific node or some group of nodes:
- ICMP traffic: Disabling ICMP traffic will affect your network monitoring in the following way:
discovery will not discover such nodes, unless nodes are seeded,
queried through ARP cache, or queried through SNMP MIB entries (that
is, CDP and EDP).
- State polling cannot determine the state, although you can configure ICMP fault polling groups.
- Ping action (using Actions | Ping) cannot be used.
- SNMP traffic: Disabling SNMP will affect your network monitoring in the following way:
- Device will have No SNMP profile and will not show any other interface but itself. It means that you will see a generic device with one IP interface.
will not learn anything about the neighbor devices. So they must be
seeded in order to have them discovered and this will affect
connectivity information, so these devices will be shown as unconnected.
- State poller will use only ICMP pings to determine device status. No performance data will be collected.
- Causal engine cannot locate the root cause of incidents.
The following screenshot represents Autodiscovery Rules window:
If you have Cisco devices using loopback addresses, consider un-checking the Enable SNMP Address Discovery box. That way, the loopback address is the only address that will ever be used for SNMP communication.