Ðóññêàÿ âåðñèÿ
Óêðà¿íñüêà âåðñ³ÿ?

The module of subsystem “Data acquisition” <SNMP>

Introduction

SNMP protocol was designed to verify the operation of network routers and bridges in 1988. Subsequently, the scope of the protocol coverage and other network devices such as hubs, gateways, terminal servers, and even devices that are remotely related to the network: printer, uninterpretable power supplies, PLC, etc. In addition, the protocol allows the possibility of changes in the functioning of these devices. At this time, SNMP protocol is standardized as RFC-1157, -1215, -1187, -1089.

This module provides the ability to gather information and set modification for various devices on the SNMP protocol. Also, the module implements the functions of the horizontal reservation, namely, working in conjunction with the remote station of the same level.

1. SNMP

The main interacting "individuals" of the protocols are the agents and management systems. If we consider these two concepts in the language of «client — server», then the server role is played by agents, that is the same devices for the survey of the state of which the protocol has been developed. Accordingly, the role of the clients is played by the management systems — network applications which are necessary to gather the information about the functioning of agents. In addition to these two entities in the model of the protocol it can be identified as two more: control information and the protocol for data exchange.

All information about the objects of system-agent is contained in the so-called MIB (management information base) — the base of control information, in other words, MIB is the totality of objects (MIB-variables) accessible to the reading-writing operations.

For this time there are four typical of MIB:

1. Internet MIB — database of objects for providing the diagnosis of errors and configurations. It includes 171 objects (including objects of MIB I).
2. LAN manager MIB — database of 90 objects - passwords, sessions, users, shared resources.
3. WINS MIB — database of objects required for the operation of a WINS server.
4. DHCP MIB – base of objects required for the operation of the DHCP server that serves for dynamic allocation of IP addresses on the network.

In addition to the above types of databases, MIB can be additionally loaded by modules.

1.1. MIB

All names of MIB have a hierarchical structure. There are ten root aliases:

1. System — the group of MIB II contains the seven objects, each of which serves to store information about the system (OS version, time, etc.).
2. Interfaces — contains 23 objects necessary for the conduct of network interfaces of agents (the number of interfaces, the size of MTU, the rate of transmission, physical addresses, etc.).
3. AT (3 objects) — are responsible for the broadcast address. No longer used. Was included in the MIB I. In SNMP v2 this information was transferred to the MIB for the relevant protocols.
4. IP (42 objects) — data on the passing IP packets (number of requests, responses, offcast packages).
5. ICMP (26 objects) — information about control messages (incoming/outgoing messages, errors, etc.).
6. TCP (19) — all that relates to the same-name transport protocol (algorithms, constants, connections, open ports, etc.).
7. UDP (6) — the same one for UDP protocol (incoming/outgoing datagram, ports, errors).
8. EGP (20) — data about the traffic Exterior Gateway Protocol (used by routers, object stores information about the received/sent/ offcast frames).
9. Transmission — is reserved for specific MIB.
10. SNMP (29) — statistics on SNMP - incoming/outgoing packets, limiting package size, errors, data on the process request, and much more.

1.2. Addressing

Each of the root alias appears in the form of tree growing down. For example, to the address of the administrator you can contact by the means of the way: system.sysContact.0, to the time of the system: system.sysUpTime.0, to the description of the system (version, kernel and other information about the OS): system.sysDescr.0. On the other hand, the same data can be specified in the point notation. So, system.sysUpTime.0 value corresponds to 1.3.0, because the system has an index "1" in groups of MIB II, and sysUpTime - 3 in the hierarchy of the group system. Zero at the end of the path indicates the scalar type of data storage. During the work symbolic names of the objects are not used, that is, if the manager asks the agent the contents of the parameter system.sysDescr.0, then in the query string the link to the object will be converted to "1.1.0", and will not be handed over «as is».

In general, there are several ways to write the addresses of MIB-variable:

1. ".1.3.6.1.2.1.1" — Direct code addressing for object "System".
2. ".iso.org.dod.internet.mgmt.mib-2.system" — Full symbol to direct code addressing for object "System".
3. "system.sysDescr.0" — Simple, not full path, addressing from root alias (object "System").
4. "SNMPv2-MIB::sysDescr.0" — Addressing from MIB base by module name for "system.sysDescr.0".

1.3. Interaction

In the SNMP client interacts with a server on a request-response principle. On its own, the agent is able to initiate only one action, called a trap interrupt. In addition, all the actions of agents are to respond to requests sent by managers.

There are 3 main versions of the protocol SNMP (v1 & v2 & v3), which are not compatible. SNMP v3 supports encryption of traffic, which, depending on implementation, uses the algorithms DES, MD5. This leads to the fact that while transfer the most critical and important data is unavailable for listening. As a transport protocol the UDP protocol is usually used in the SNMP. Although, in fact, SNMP supports a variety of other lower-level transport protocols.

1.4. Authorization

One of the key concepts of SNMP is the notion of group. Procedure of the authorization of the manager is a simple test for membership of a particular group from the list, which belongs to the agent. If the agent does not find a group of the manager in its list, their further interaction is impossible. By default, the group used: public (for read) and private (for write). The protocol SNMP v3 for authentication uses the user with password of authentication and password of privacy, depending on the level of security.

2. Module

This module supports all versions of the protocol SNMP (1, 2 and 3) in the read-write MIB-parameters.

2.1. Controller of data

For addition of the SNMP data source the controller is created and configured in the system OpenSCADA. Example of the configuration tab of the controller is depicted in Figure 1.

Fig.1. Configuration tab of the controller.

From this tab you can set:

• The state of the controller, as follows: state, «Enable», «Run» and the name of the database containing the configuration.
• Id, name and description of the controller.
• The state, in which the controller must be translated at boot: «To enable» and «To start».
• Name of table to store the configuration of the parameters of the controller.
• The acquisition schedule policy and the priority of the task of data acquisition.
• Remote agent's host address.
• Retries number for send request.
• Responds timeout, in seconds.
• Used SNMP version.
• Community or user for a connection establish.
• Restriction on the number of attributes in the one parameter.
• Security level for v3 (No auth/No privacy; Auth/No privacy; Auth/Privacy).
• The protocol (MD5, SHA) and password of authentication for v3.
• The protocol (DES, AES) and password of privacy for v3.

2.2. Parameters

Module SNMP provides only one type of parameters — "Standard". An additional configuration field of the parameter of the module(Fig. 2) is a list of MIB-parameters, the branches or separated items (scalars) of which are to be read.

Fig.2. Configuration tab of the parameter.

In accordance with a specified list of MIB-parameters is carried out a survey of their branches (or scalars) and the creation of the attributes of the parameter. Further, updating of the values of parameters is carried out. Attributes are named in accordance with the code addressing of MIB-parameters, as the ID, and the addressing from the base of MIB objects in the name of the attribute(Figure 3).

Fig.3. Tab of the attributes of the parameter.

Links