SNMP Connector

Many network components contain programs that enable SNMP communication to take place. These programs, known as agents and running directly on the monitored device, can transmit the state of the device and receive and apply data for configuring the network components.

Communication

An SNMP server is employed to monitor components in simple and complex IT networks. The agents running on the network components communicate with the server over SNMP. Communication over SNMP is based on the connectionless User Datagram Protocol (UDP) which simply adds the addressing data to the SNMP data packets and thus requires very little bandwidth. By default, the agents communicate through port 161 while the SNMP Manager communicates through port 162.

The structure of the SNMP data packets is transparent when using the SNMP connector. To configure the connector, all you need to know is the connection data, the type of the data packet and the OID.

Data packets

Only four of the six different data packets that are defined in the standard are needed for the SNMP connector. The data packets are named after the methods that are executed with them. The SNMP connector supports the GET, GETNEXT, SET and TRAP operations.

OID

Each agent is aware of the value of the parameters of its network components. This can be used to either issue a status message (Trap) or to change the configuration. These parameters are known as managed objects. All managed objects are held in a tabular list (not in a database). This list is called the Management Information Base, abbreviated to MIB. An object identifier, abbreviated to OID, is assigned to each managed object in the MIB.

The object identifier is a string composed of numbers and dots. The structure of this string follows a structure that is composed of the so-called MIB tree.

For an illustration of the MIB tree, refer to https://de.wikipedia.org/wiki/SNMP.

This numeric code also contains a portion that indicates the company. Virtimo AG has been assigned the code 15899 for its INUBIT software. Thus, the start of the OID looks like this:

The OID has only been standardized as far as the Private Enterprise Code. The composition of the remainder of the OID is not standardized. It is up to the system administrators to create an internal company system that covers all network components and assigns these numbers. A number must also be allocated to each of the managed objects associated with the devices. The values of the managed objects, that is, of the events that can be monitored and configured by SNMP, are device-dependent and can only be found in the manufacturer’s manual in each case

OIDs as constants and variables

The rules for constructing the OID string out of digits and dots are frequently not followed since the OIDs are only used within the company and thus there is no need for uniqueness compared to the IT environment of other companies.

If a trap or a configuration instruction is to be sent, it normally consists of an OID and a value. Variable: Each OID can get only the values that are specified in the manufacturer’s data for the network component. Constants: In some cases just an OID is transmitted, without a value. This is the case if a managed object can only communicate a state via an OID.

Community

SNMP offers the facility to transmit a so-called community string when communicating. Only components that belong to the same community react to traps or configuration commands. The community string is transmitted unencrypted.

An ISDN connection is to be established in the workflow through an SNMP connector via a router. Subsequently, at the end of the workflow, a message is to be sent over this connection to an FTP connector.

With the SNMP medium connector, tables of tuples consisting of the OID and a value cannot be specified. Instead, the relevant value pairs are expected in the XML input message.

An OID can either contain:

In an XML input message, these three different cases have the following format. The OIDs and values are examples.

The router is configured dynamically during the execution of the workflow. The required values are read from the input message, turned into an XML message by an XSLT converter and are then passed to the SNMP connector.

The following figure shows the mapping in the XSLT converter. The abbreviations are explained as follows:

The following lines show the XML message that is passed to the SNMP medium connector as a result of the mapping:

This example relates to the medium connector example.

If the router’s ISDN connection always uses the same data, this connection can be configured right at the start of the workflow with a static OID table. To do this an SNMP input connector is configured as follows:

In this dialog you have the following options:

Basic configuration

Configuration of the variable binding

Operation: Four different operations are available

For the purpose of variable binding, a table of pairs is built, each pair consisting of an OID and a value. This table is only available for the SNMP input connectors.

Table

Offers a context menu for adding and deleting OIDs.

Trap configuration
(For operation TRAP only)

Connection test