Let us dwell in more detail on that part of the control system that relates to the interaction of the manager, agent and managed object (Fig. 25.3).
For each managed object in the network, some object model is created. It represents all the characteristics of an object that are needed to control it. For example, a router model usually includes such characteristics as the number of ports, their type, routing table, the number of frames and protocol packets of the link, network and transport layers that have passed through these ports. Network object models are used by the manager as a source of knowledge about what set of characteristics a particular object has.
The object model coincides with the logical schema of the database (DB) of the object that stores the values of its characteristics. This database is stored on the device and is constantly updated with the results of measurements of characteristics carried out by the agent.
In network management systems built on the basis of the SNMP protocol, such a database is called a management information database (Management Information Base, MIB ).
The manager does not have direct access to the MIB database; in order to obtain specific values of the object’s characteristics, he must contact its agent over the network. Thus, the agent is an intermediary between the managed object and the manager. The manager and the agent interact using a standard protocol . This protocol allows the manager to request the values of the parameters stored in the MIB, and the agent to transmit information on the basis of which the manager should manage the object.
A distinction is made between in-band control (In-band), when control commands go over the same channel through which user data is transmitted, and out-band control (Out-band), that is, carried out outside the user data transmission channel.
In-band management is more cost effective as it does not require a separate control data transmission infrastructure. However, out-of-band management is more reliable, since the corresponding equipment can perform its functions even when certain network elements fail and the main data transmission channels are unavailable.
The scheme “manager – agent – managed object” allows you to build quite complex structurally control systems.
The presence of several managers allows you to distribute the load on processing control data between them, ensuring system scalability. As a rule, two types of relationships between managers are used: peer-to-peer (Figure 25.4) and hierarchical (Figure 25.5). Each agent shown in the figures controls one or more network elements (Network Element, NE), the parameters of which it places in the corresponding MIB. Managers extract data from the MIBs of their agents, process
they are stored in their own databases. Operators working at workstations can connect to any of the managers and, using a graphical interface, view data about the managed network, as well as issue some directives to the manager to manage the network or its elements.
In the case of peer-to -peer communications, each manager manages his part of the network based on information received from downstream agents. There is no central manager. Coordination of managers’ work is achieved through the exchange of information between managers’ databases. Peer-to-peer construction of a control system today is considered inefficient and outdated.
Much more flexible is the hierarchical construction of relationships between managers. Each lower-level manager also acts as an agent for the upper-level manager. Such an agent already works with an enlarged MIB model of its part of the network. Such a MIB collects exactly the information that a top-level manager needs to manage the network as a whole.
Network management systems based on SNMP protocol
SNMP (Simple Management Network Protocol) is used as the standard manager-agent communication protocol.
The SNMP protocol belongs to the application layer of the TCP/IP stack. It uses the UDP datagram transport protocol to transport its messages, which is not known to provide reliable delivery. The TCP protocol, which organizes connection-based reliable messaging, loads managed devices quite heavily, which at the time of the development of the SNMP protocol were not very powerful, so it was decided to abandon the services of the TCP protocol.
SNMP is a request-response protocol, that is, for each request received from the manager, the agent must send a response. A feature of the protocol is its extreme simplicity – it includes only a few commands.
– The GetRequest command is used by the manager to query the agent for the value of a variable by its standard name.
– The GetNextRequest command is used by the manager to retrieve the value of the next object (without specifying its name) when sequentially scanning the object table.
– Using the Response command, the SNMP agent sends a response to the GetRequest or GetNextRrequest command to the manager.
– The SetRequest command allows the manager to change the values of any variable or list of variables. With the help of the SetRequest command, the device is actually managed. The agent must “understand” the meaning of the values of the variable that is used to control the device, and based on these values, perform the actual control action: disable the port, assign the port to a specific VLAN line, etc. The Set command is also suitable for setting the condition under which SNMP The agent must send the appropriate message to the manager. In this way, the response to events such as agent initialization, agent restart, link loss, link recovery, invalid authentication, and loss of the nearest router can be determined. If any of these events occur, then the agent initiates an interrupt.
– The Trap command is used by the agent to notify the manager that an exception has occurred.
– The GetBulk command allows the manager to get several variables in one request.
SNMP messages, unlike messages from many other communication protocols, do not have headers with fixed fields. Any SNMP message consists of three main parts: protocol version, common string, and data area.
The community string is used to group devices managed by a specific manager. The public string is a kind of password, because in order for devices to communicate using the SNMP protocol, they must have the same value for this identifier (the default string is often “public”). However, this mechanism serves more for “recognition” of partners than for security.
The data area contains the described protocol commands, as well as object names and their values. The data area consists of one or more blocks, each of which can be one of the listed types of SNMP commands. Each command type has its own format. For example, the block format related to the GetRequest command includes the following fields:
— request identifier;
– status of the error (yes or not);
— error index (error type, if any);
— list of SNMP MIB object names included in the request.
The MIB contains the values of many different types of variables that characterize a particular managed entity. In the very first version of the standard (MIB-I), it was proposed to use 114 types of variables to characterize a device. These variables are organized in a tree. 8 branches emerge from the root, corresponding to the following eight groups of variables:
System – general data about the device (for example, vendor ID, time of the last system initialization);
Interfaces – parameters of the device network interfaces (for example, their number, types, exchange rates, maximum packet size);
Address Translation Table – a description of the correspondence between network and physical addresses (for example, using the ARP protocol);
Internet Protocol – data related to the IP protocol (addresses of IP gateways, hosts, statistics on IP packets);
ICMP – data related to the ICMP protocol;
TCP – data related to the TCP protocol (the number of transmitted, received and errored TCP messages);
UDP – data related to the UDP protocol (the number of transmitted, received and erroneous UPD datagrams);
EGP – data related to the EGP protocol (the number of messages received with errors and without errors).
Each group of characteristics forms a separate subtree. The following are the variables of the Interfaces variable subtree used to describe the interface of the managed device:
ifType is the type of protocol that the interface supports (this variable accepts the values of all standard link layer protocols);
‰‰ifMtu is the maximum network layer packet size that can be sent over this interface;
‰‰ifSpeed — interface throughput in bits per second;
‰‰ifPhysAddress — port physical address (MAC address);
‰‰ifAdminStatus – desired port status (up – ready to send packets, down – not ready to send packets, testing – is in test mode);
‰‰ifOperStatus – actual current status of the port, has the same values as ifAdminStatus;
‰‰ifInOctets is the total number of bytes received on this port, including overhead, since the last SNMP agent initialization;
‰‰ifInUcastPkts is the number of packets with a unique interface address delivered to the upper layer protocol;
‰‰ifInNUcastPkts is the number of packets with a broadcast or multicast interface address delivered to the upper layer protocol;
ifInDiscards – the number of valid packets received by the interface, but not delivered to the upper layer protocol, most likely due to a packet buffer overflow or for some other reason;
‰‰ifInErrors is the number of incoming packets that were not passed to the upper layer protocol due to the detection of errors in them.
In addition to variables describing statistics on input packets, there is a similar set of variables related to output packets. Even more detailed statistics about network performance can be obtained using the SNMP extension – the RMON protocol (Remote Network MONitoring – remote network monitoring). Management systems based on RMON have the same architecture, the elements of which are managers, agents, and managed objects. The difference is that SNMP systems collect information only about events that occur on those objects on which agents are installed, while RMON systems also collect information about network traffic. Using the RMON agent built into the communication device, you can conduct a fairly detailed analysis of the operation of the network segment. Having collected information about the most common types of errors in frames, and then obtaining the dependence of the intensity of these errors on time, we can draw some preliminary conclusions about the source of erroneous frames and, on this basis, formulate more subtle conditions for capturing frames with specific features corresponding to the proposed version. All this helps to automate network troubleshooting.