Configuring SNMP Devices

Here are described options available and concerns should be taken into account while configuring a particular devices for SNMP management.

Ensure SNMP is enabled on the device you are going to manage. SNMP is enabled by default for manually added devices. For discovered devices, SNMP is enabled or disabled automatically according to the service scan results.

If SNMP is disabled for the discovered device, or the enabled SNMP service is "offline", try the following:

Being confident that all the parameters are correct, enable SNMP service if it is disabled, or invoke synchronization. Mind, that full synchronization with an SNMP device can take a significant amount of time. Alternatively, you can try to rediscover SNMP service on this device.

SNMP device settings are presented by SNMP Properties variable in Network Host device contexts (refer to SNMP connection properties for details).

The SNMP properties are used to establish communication with SNMP agent. Thus, both sides should be configured identically.

The SNMP properties must conform the agent configuration in order to successfully communicate with it.

SNMP can work over two transport protocols: UDP (User Datagram Protocol) or TCP (Transmission Control Protocol). UDP is connectionless, i.e. try to establish end-to-end between agent and manager, and unreliable, i.e. delivery of messages is not guaranteed, and the order of messages may change. On the contrary TCP guarantees messages delivery and provides robust error-recovery; the messages are delivered in the sequence they were sent.

Iotellect Network Manager supports both UDP and TCP as transport protocols for SNMP. Which one to choose for your network?

SNMP over UDP has a reduced impact on network's performance, not trying to retransmit lost or broken information. UDP should be considered as default transport for SNMP; especially this is true for problematic networks. (Note, SNMP was originally designed for UDP transport.)

The unreliable nature of UDP protocol can be balanced by regular requests, and/or Iotellect Network Manager ability to resend requests several times when no response was received within the specified timeout (see below). But this is not true for traps as they are basically unconfirmed operations. So, if a trap was not delivered from agent to manager for any reason, the manager will never know it was ever sent; and the agent will have no chance to be informed about that and therefore can't resend the trap. This issue should be considered when configuring SNMP management.

Use Inform requests instead of traps for guaranteed delivery.

SNMP over TCP is primarily defined to support more efficient bulk transfer mechanisms. It is possible to exchange multiple SNMP request/response pairs over a single (persistent) TCP connection, even sending multiple SNMP messages to an agent before receiving responses. SNMP over TCP is intended to be used when the size of the transferred data is large. This is where TCP can be more effective then UDP. But in a whole, to be effective, using TCP as transport for SNMP polling needs a fine IP configuration considering the environment circumstances it is used in.

Another concern is reliability. SNMP over TCP gives a reliable exchange of SNMP messages between SNMP engines. In particular, TCP guarantees (in the absence of security attacks) that the delivered data is not damaged, lost, duplicated, or delivered out of order. At the same time these features of TCP does not guarantee that the data sent was eventually received and processed in any way by manager. To ensure that, confirmed operations should be used.

The choice between UDP or TCP does not impact security significantly, as both variants are basically vulnerable: for example, UDP is subjected to IP spoofing attacks, while TCP may introduce vulnerabilities to denial of service attacks. In either case other security options should be considered.

By default SNMP uses port 161 for sending and receiving requests. If a device has a non-standard SNMP configuration, you can specify another port number.

Iotellect Network Manager supports SNMPv1, SNMPv2c and SNMPv3. Select the one appropriate for the particular device.

Don't forget to setup the Read Community and Write Community properties correctly to get a read and write access to the device management information via SNMPv1/SNMPv2c.

Use string like public@12 to get information about certain VLAN from CISCO devices.

If Iotellect Network Manager's request is not responded with the specified timeout period, it repeats the request again. These settings are important especially when UDP is used as transport protocol, because it is unreliable and SNMP messages can be lost.

The concrete values depend on the parameters of your network. They can be chosen empirically starting with the default values provided out of box.

This is the maximum size of SNMP message the agent can receive. It is used by Iotellect Network Manager to limit the size of SNMP requests.

The recommended size is 1472 octets (see, for example, Transport Mappings for the Simple Network Management Protocol). But some agents are unable to handle messages more than 484 octets in size, which is a "guaranteed" value.

Many SNMP agents expose multitudes of SNMP variables. Not all of those variables are used in practice. Reading, processing and storing the variables that are not actually utilized is a waste of network, processor and memory resources. Obviously, it is a good idea not to read all the variables available, but access only those of them that are actually useful for monitoring a particular item. But what is useful may vary depending on the user tasks and aims. To meet different user requirements, Iotellect Network Manager provides two options:

• Iotellect Network Manager can read, process and store all the values the SNMP agent exposes. This option, for example, may be used for exploration of an unknown device.
• Another options is processing only the values described by loaded MIB files, ignoring unrecognized ones. This can be a good choice if you want to have detailed information about the monitored device.

These options are available only for SNMPv3. A user can specify security level, username, passwords and protocols for authentication and encryption. Refer to SNMP security options description for details.

Iotellect Network Manager polls monitored items periodically. The interval between adjacent requests is a very important monitoring parameter. It defines balance between monitoring data accuracy/precision and processor/memory/network load. Furthermore, the polling interval should not be shorter than refresh period at the agent side (see Data Processing section).

The polling in Iotellect Network Manager is implemented as synchronization; polling interval is represented by the Synchronization Period (refer to Generic Device Properties) and can be customized using Device Settings Synchronization Options. You can specify custom synchronization period for individual SNMP variables.

The default synchronization period for SNMP devices is 24 hours. Some variables are customized with specific synchronization periods, e.g. network interface and processor statistics data are read every 15 minutes and every 30 seconds, respectively. You can specify your own periods for these and other variables.

Was this page helpful?

Tell us more

Send

Thank you!