KR20030057629A - Error management of SNMP manager - Google Patents

Abstract

PURPOSE: A method for processing failure of an SNMP(Simple Network Management Protocol) manager is provided to perform a trap process together with request/response according to polling, thereby processing a failure process of the SNMP manager with reliability. CONSTITUTION: A management manager(110) requests periodically according to polling and receives a response to the corresponding request from a management object node(200). During the operation of the polling process, the management manager(110) also receives a trap event of the management object node(200). The polling is performed by procedures: the management manager(110) transmits periodically a request(GetRequest) to the management object node(200) and the management object node(200) transmits a response(GetResponse) showing a fault situation.

Description

How to handle failure of Simple Network Management Protocol Manager {Error management of SNMP manager}

The present invention relates to failure handling of a simple network management protocol (SNMP) manager, and more particularly, to a failure handling method of a simple network management protocol manager suitable for reliable failure handling of an SNMP manager. .

In general, SNMP is a network management protocol of Transmission Control Protocol / Internet Protocol (TCP / IP). It is adopted as a standard communication protocol used to send network management information of a network agent such as a router or a hub to the network management system, and TCP / IP's Simple Gateway Management Protocol, It is developed based on SGMP and corresponds to Open System Interconnection (OSI) Network Common Management Information Protocol (CMIP).

SNMP collects and manages network management information using two functions, request and response. It is standardized by RFC 1157, with revisions such as SNMPv2. And the Internet uses Request For Comments (RFCs), which are requirements and recommendations for the standard. The behavior of SNMP is defined by three separate and related RFCs, and is extended by many others. Accordingly, there are RFC1155, RFC1156, RFC1157, RFC1212, RFC1213, RFC1215, and RFC1239 with respect to SNMP.

SNMP is closely related to the Management Information Base (MIB). One of the main goals of SNMP is to allow the transmission of network management information from inside one device to another via a device that is not subject to the abstract syntax.

In this way, network information can be managed by a remote user. SNMP models can easily change or examine all management information functions. Limited request messages from network elements guide the timing and focus of polling. Limited request messages are simple and keep the network traffic to a minimum.

And the management information base is the collection-integrated information of all objects controlled by a specific agent or manager. The management database is a very simple table that is easy to operate and is configured to connect quickly and effectively to most systems.

1 is a network management block diagram according to a general SNMP protocol.

SNMP is configured with several elements by means of network management. These are management elements, managers, and their means of communication. Network management is performed by the structure of the management manager 110 and the managed node 120, the management manager 110 monitors the management application (Application) and controls the management elements. The management element may be a network element NE such as a host, a bridge, a router, a hub, or a device such as a terminal server on the managed node 120.

SNMP functions as a simple request / response protocol for exchanging management information between network elements of network management manager 110 and managed node 120. This protocol does not define any manageable objects.

SNMP applications use the instruments of managed node 120 via network elements. The management target node 120 accesses data of the management information base (MIB), and operates as a server to perform a network function required by the network administrator.

The managed node 120 operates on a direct connection of the remote process. It operates when certain defined errors occur. These fault events call traps, and the use of traps is limited.

A typical implementation of managed node 120 is a transport protocol for sending and receiving datagrams between network devices, and a manager and peer-to-between management manager 110 and managed node 120. -peer) SNMP engine, which exchanges messages and encrypts and decrypts the request and response of an independent platform, allowing the managed node 120 to access the management protocol so that the data structure of the device responds to the request of the management protocol. It includes mediation means to enable access, and a management profile, which is a set of rules that define access to various interests.

According to the prior art, failure event processing of the managed node 120 is performed in two ways.

2 shows a fault handling procedure using a polling scheme, and FIG. 3 shows a fault handling procedure using a trap scheme.

In the polling method, the management manager 110 processes a failure event by periodically repeating a request / response (GetRequest / GetResponse) for the managed node 120.

A trap is a special form of condition propagation point operated by hardware, an operating system, or a combination of both. In the trap method, a trap event is generated when a trap condition set in the managed node 120 is established. 110) to the side.

However, in the prior art according to the polling method, since the management manager 110 processes the request / response for the agent periodically, network traffic is inefficient, and the problem of the failure event that occurs until the next polling is not known. have.

Moreover, trap event reporting cannot predict the situation before a failure occurs, and can only post-process in the event of a failure.

SUMMARY OF THE INVENTION The present invention was created to solve the above-mentioned conventional problems, and an object of the present invention is to provide a simple network management protocol for reliable failure processing of an SNMP manager by performing trap processing together with a request / response according to polling. It provides a way to handle the manager's failure.

In order to achieve the above object, a method for processing a failure of a simple network management protocol manager of the present invention includes: setting a polling period and a trap condition at a management manager and a managed node, respectively; Updating, by the management manager, status information of the corresponding management target node by issuing a request to the management target node at each set polling period; And transmitting, by the management node, a failure event occurrence seat wrap according to the set trap condition to the management manager regardless of whether the polling period has arrived.

1 is a network management block diagram in accordance with a general SNMP protocol.

2 is a diagram illustrating a failure processing according to a conventional polling scheme.

Figure 3 is an illustration of failure processing according to the conventional trap method.

Figure 4 is a general simplified network management protocol message structure diagram.

5 is a diagram illustrating a failure processing according to a trap-polling scheme according to an embodiment of the present invention.

6 is a flow chart of a failure handling method of the simplified network management protocol manager according to an embodiment of the present invention.

Hereinafter, exemplary embodiments of the present invention will be described with reference to the accompanying drawings.

4 is a schematic diagram of a simple network management protocol message, FIG. 5 is a diagram illustrating a failure processing according to a trap-polling scheme according to an embodiment of the present invention, and FIG. 6 is a diagram of a simple network management protocol manager according to an embodiment of the present invention. A flowchart of the fault handling method.

This embodiment implements a trap-polling technique by combining trap processing and polling processing, unlike the prior art using only polling for fault events or prior art generating only trap events.

When the trap-polling scheme is applied, it is preferable that the management manager 110 perform polling and receive a trap event generated in the management target node 120. Accordingly, the present embodiment also follows.

First, referring to FIG. 4, an SNMP message structure is shown. A typical SNMP message has three parts.

The Version Number field ensures that the source and destination of the message use the same version of SNMP. The Community String field is for passing a service that implements the required authentication plan. An appropriate profile is selected using the SNMP community and a packet data unit (PDU) is appropriately performed.

In addition, the PDU field contains one of five SNMP PDUs. There are five kinds of requests (GetRequest), Next Request (GetNextRequest), Response (GetResponse), Request Request (SetRequest), and Traps.

The SNMP message is transmitted between the management manager 110 and the managed node 120.

According to FIG. 5, the management manager 110 periodically makes a request for polling and receives a response to the request from the management target node 120. The management manager 110 may receive a trap event of the managed node 120 even during the polling process.

Polling is performed by a procedure in which the management manager 110 periodically issues a request GetReqest for the managed nodes 120 and sends a response indicating a failure condition in the managed node 120. . In general, traps are used in multidrop or multipoint communication where multiple devices share the same line, and the controller sends a message to each device one at a time to ask if there is any data to send. In this manner, the management manager 110 periodically grasps the state of the management target node 120, and in particular, detects the occurrence of a failure situation.

A trap is a special condition for testing in a running program. For example, "trap an interrupt" means waiting for a particular interrupt to occur before executing the corresponding routine. Therefore, the trap for the failure event processing sets the trap conditions according to possible failure situations in each managed node 120, and traps the managed node 120 to notify its own failure situation when the corresponding trap condition occurs. It operates in a manner of delivering the event to the management manager (110) side.

Referring to Figure 6 describes a specific failure processing procedure as follows.

First, since the polling period is required to be applied when polling is applied, the polling period for each management target node 120 is set in the management manager 110. In addition, a trap event is generated in each management target node 120 and is set to a condition that is transmitted to the management manager 110, that is, a trap condition (S61).

The management manager 110 checks the set polling cycle and writes a request (GetRequest) to the PDU type field when the polling cycle arrives to create an SNMP message.

The created SNMP message is transferred from the management manager 110 to the managed node 120 (S62).

The management node 120 confirms that a request (GetRequest) has been issued through the PDU type field of the received SNMP message, and creates an SNMP message by putting a response (GetResponse) in the PDU type field to indicate its failure situation. do.

The management target node 120 transmits the SNMP message to the management manager 110 (S63).

The management manager 110 grasps a failure situation of the managed node 120 by issuing a request for each polling period and receiving a response thereto. What is necessary is just to take appropriate measures, such as notifying an administrator about the identified failure situation (S64).

In general, since the management manager 110 monitors the information on the status of each managed node 120, the management manager 110 according to the failure of the managed node 120 identified by the periodic polling status information Update (S65).

On the other hand, regardless of the arrival of the polling period, the management target node 120 transmits a trap to the management manager 110 by placing a trap in the PDU type field of the SNMP message when a set trap condition, that is, a failure event. For convenience, the case following the step S65 will be described by way of example (S66 to S67).

When the management manager 110 receives a trap for a failure event, the management manager 110 polls the failed management target node 120. At this time, the polling is preferably performed regardless of the set polling period. That is, polling is performed on the managed nodes 120 immediately after receiving the trap. As a result, detailed information on the failure may be obtained (S68).

In addition, if the trap occurs frequently, the polling interval is reduced, and if the frequency of traps decreases, the polling interval may be increased. This allows the polling interval to be properly adjusted, enabling efficient operation of network bandwidth due to reduced network traffic, and increasing the efficiency of fault handling.

The embodiments described above are within the scope of various changes, modifications, and equivalents of the present invention. Therefore, the present invention is not limited to the description of the examples.

According to the fault handling method of the simplified network management protocol manager of the present invention, the fault handling is performed in a trap-polling manner by combining polling and trap events performed every set polling period, thereby enabling reliable fault handling.

In addition, by applying the present invention by adjusting the polling period according to the frequency of the failure occurrence it is possible to increase the operation efficiency of traffic resources and improve the efficiency of failure processing.

Claims (4)

Setting polling cycles and trap conditions in the management manager and the managed node, respectively; Updating, by the management manager, status information of the corresponding management target node by issuing a request to the management target node at each set polling period; And transmitting, by the management target node, a failure event occurrence sheet wrap according to the set trap condition to the management manager regardless of the arrival of the polling period. The method of claim 1, wherein the updating of the state information of the managed node, When the managed node receiving a request of the management manager delivers a response, the management manager updates the state information of the managed node owned by the management manager according to the failure state indicated by the response. How to handle failure of Network Management Protocol Manager. The method of claim 1, If the management node receives a trap for a failure event, the management manager further comprises the step of polling the failed management target node to obtain detailed information about the failure. How the management protocol manager handles failures. The method of claim 1, And the management manager is configured to adjust the polling period according to a change in the frequency of trap generation.