JP3877557B2 - Hierarchical network management system - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a hierarchical network management system, and in particular, a hierarchical network in which network resources are hierarchically managed by agents, sub-managers, and integrated managers, and SNMP (Simple Network management protocol) is used as a communication protocol between them. Regarding management system.
[0002]
[Prior art]
Generally, a communication network management system includes two types of subsystems, a manager and an agent, and the manager manages and controls network resources in units of agents. The agent also manages and controls management objects such as configuration information and status information for each resource of the communication network.
There are two international standards for communication network management: IAB (Internet Activities Board) management standard and OSI (Open Systems Interconnection) management standard. In the network using the management standard, network resources are managed as follows.
[0003]
(1) Network management system using IAB management standard
When a communication network becomes large, the communication network is divided, and a manager and an agent are arranged in each of the divided communication networks (hereinafter referred to as sub-networks) to manage network resources.
[0004]
In this case, when performing resource management according to the IAB management standard, SNMP (Simple Network management protocol) is used. The SNMP standard is defined by RFC 1157, Simple Network Management Protocol (RFC 1157, “A Simple Network Management Protocol”).
[0005]
(2) Hierarchical network management system using both OSI management standard and IAB management standard
As described in "Integrated management by OSI of distributed LAN domain" (Miyauchi et al., IPSJ Journal, 1993, June issue, pp 1426-1440, reference [1]) A local area network) is managed by a sub-manager based on the IAB management standard, and network resources are managed between the sub-manager and its upper integrated manager based on the OSI management standard.
[0006]
That is, the sub-manager manages network resources in accordance with the IAB management standard, converts it to the OSI management standard and transmits it to the integrated manager, and the integrated manager manages the resources of the entire network.
[0007]
[Problems to be solved by the invention]
By the way, when managing a large-scale network, it is more effective to manage in a hierarchical structure in order to reduce management packets and simplify managers.
[0008]
However, in the above network management system using SNMP of the IAB management standard, since hierarchical management is not considered, even if a sub-manager is arranged between the manager and the agent, it is transmitted between the manager and the sub-manager. There is a problem that hierarchical management cannot be realized unless the structure of the management information to be collected and the collection method thereof are solved. That is, there is a problem that a hierarchical network management system that manages and controls a group of agents cannot be realized.
[0009]
In this case, in the SNMPv2 (SNMP version 2) standard, an event can be notified from the manager to the manager. However, as with SNMP, since hierarchical management is not considered, a sub- Even if the manager is arranged, there is a problem that the hierarchical management cannot be realized unless the structure of the management information transmitted between the manager and the sub-manager and the collection method thereof are solved.
[0010]
On the other hand, in the OSI management system described in the reference [1], the sub-manager is an OSI standard communication service that realizes the OSI management standard and an IAB standard communication service that realizes the IAB management standard. Since both must be implemented, there is a problem that the sub-manager becomes large.
[0011]
In the LAN, an IAB standard communication service is used. In operation of the communication network, it is normal operation to use an IAB standard communication service even between LANs. Therefore, in the management system described in the reference [1], the standard of the OSI management standard must be used even though the standard of the IAB management standard is used on the WAN (Wide Area Network). In this respect, there is a problem that the configuration of the sub-manager becomes large.
[0012]
In addition, when a communication network managed by multiple management standards is unified and managed by an integrated manager, management information conversion and delegation of management functions for reducing the load on the integrated manager, decentralization, etc. are performed in advance. Although it is necessary to take into consideration, the management system in Reference [1] does not consider management function substitution, decentralization, etc., so management information between the integrated manager and sub-managers as the network becomes larger There is a problem that the number of management packets used when exchanging the packets increases.
[0013]
A first object of the present invention is to provide a hierarchical network management system that is a sub-manager with a simple configuration and can hierarchically manage a large-scale communication network based on SNMP of the IAB management standard.
[0014]
A second object is to provide a hierarchical network management system capable of transmitting management information between an integrated manager and sub-managers with a small amount of management packets and managing a large-scale communication network with low traffic and low cost. It is.
[0015]
[Means for Solving the Problems]
In order to achieve the first object, the present invention basically uses SNMP as a communication protocol between an agent and a sub-manager, and between a sub-manager and an integrated manager. Management objects in the same management range are periodically collected through agents belonging to the range, MIB collection MIB information is created from the collected results, and the collected MIB information is stored in the collection MIB database. In accordance with a reference request from the integrated manager, there is provided periodic collection means for notifying the integrated manager in the MIB format.
[0016]
In order to achieve the second object, in response to a reference request from the integrated manager, a plurality of pieces of information from each agent managed by a plurality of identifiers are aggregated and notified to the integrated manager.
[0017]
According to the above means, the periodic collection means periodically collects management objects in the management range via an agent belonging to the management range of the management group, and notifies the integration manager of the collection information in response to a reference request from the integration manager. .
[0018]
In this case, the collected information is held in a format called MIB (Management Information Base) in which a set of a plurality of management objects is expressed in a tree structure, accessed in response to a reference request from the integrated manager, and notified to the integrated manager.
[0019]
Accordingly, a large-scale communication network can be hierarchically managed based on a single protocol called SNMP of IAB management standard, and the configuration of the sub-manager can be simplified because it is a single protocol.
[0020]
Also, a plurality of managed objects from each agent managed by a plurality of identifiers are aggregated and notified to the integrated manager. Therefore, management information can be transmitted between the integrated manager and the sub-manager with a small amount of management packets, and the load on the integrated manager can be reduced.
[0021]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, the present invention will be described in detail based on an embodiment shown in the drawings.
[0022]
FIG. 1 is a system configuration diagram showing an embodiment of a communication network to which the present invention is applied. A plurality of LANs 1, 2, 3 are connected by a WAN (wide area network) 4.
[0023]
Among these, a plurality of agents 20a-1 and 20a-2 that manage and control management objects such as configuration information and status information and an IP (Internet Protocol) node 30a in which no agent is installed are connected to the LAN 1 in units of network resources. Furthermore, a sub-manager 10a that manages and controls managed objects in the LAN 1 is connected via these agents 20a-1 and 20a-2.
[0024]
In addition, a plurality of agents 20b-1 and 20b-2 that manage and control management objects such as configuration information and status information are connected to the LAN 2 in units of network resources. Further, the agents 20b-1 and 20b-2 A sub-manager 10b that manages and controls managed objects under management is connected. Further, an agent 20c and an IP node 30c not mounted with an agent are connected, and a sub-manager 10c that manages and controls managed objects under the management of the agent 20c is connected.
[0025]
That is, in the LAN 2, managed objects are managed by the two sub-managers 10b and 10c.
[0026]
On the other hand, a plurality of agents 20-1 and 20-2 are connected to the LAN 3, and management objects managed by these agents 20-1 and 20-2 are managed and controlled, and the WAN 4 and sub-managers 10 a and 10 b are managed. , 10c, an integrated manager 50 that manages and controls these managed objects is connected. That is, an integrated manager 50 that hierarchically manages resources of the entire network is connected to the LAN 3.
[0027]
FIG. 2 is a diagram showing a logical relationship among the agent, the sub-manager, and the integrated manager. SNMP and ICMP (IAB management standards) are connected between the sub-manager 10a connected to the LAN 1 and the agents 20a-1 and 20a-2. Management objects are managed using the Internet Control Message Protocol. Further, managed objects are managed between the sub-manager 10a and the IP node 30a in which no agent is installed using ICMP. The sub-manager 10a is connected to a collection MIB database 170a that holds a collection of a plurality of management objects collected through agents in the management range in a format called MIB (Management Information Base) expressed in a tree structure.
[0028]
Similarly, managed objects are managed between the sub-manager 10c and the agent 20c connected to the LAN 2 using IAB management standard SNMP and ICMP. In addition, managed objects are managed using ICMP between the sub-manager 10c and the IP node 30c in which no agent is installed. Then, the sub-manager 10c has a collection MIB database 170c that holds a collection of a plurality of management objects collected through agents in the management range in a MIB (Management Information Base) format (hereinafter referred to as MIB format) expressed in a tree structure. Is connected.
[0029]
The sub-manager 10b and the agents 20-1 and 20-2 are also connected to the integrated manager 50 with the same logical relationship.
[0030]
FIG. 3 is a functional block diagram showing an embodiment of the internal configuration of the sub-manager 10 and is composed of the following functional modules.
[0031]
(1) Communication control function 100
(2) Management range monitoring function 110
(3) Collection database management function 120
(4) Own agent function 130
(5) Sub-manager agent function 140
(6) Consolidation function 150
(7) Trap management function 160
Details of each function are as follows.
[0032]
(1) Communication control function 100
In the IAB management standard, a network management protocol is named SNMP (hereinafter referred to simply as SNMP). This standard is defined by RFC 1157, Simple Network Management Protocol (RFC 1157, “A Simple Network Management Protocol”).
[0033]
The communication control means 100 receives an SNMP request from the integrated manager 50 and the sub-manager 10 itself, and receives an SNMP trap.
[0034]
The SNMP request is a management object acquisition request from the integrated manager 50 to the sub-manager 10 and a management object acquisition request from the sub-manager 10 to the agent 20.
[0035]
The received SNMP request is notified to the own agent function 130 or the sub-manager agent function 140 according to the management object identifier existing in the protocol, and the result is returned to the integrated manager 50 or the sub-manager 10 itself that is the SNMP request source. To do. The received SNMP trap is notified to the trap management function 160.
[0036]
(2) Management range monitoring function 110
The environment setting file 180 designated by the network manager of the sub-manager 10 is referred to, and the IP address range designated as the management range of the sub-manager 10 is acquired. An SNMP request and an ICMP echo request for acquiring a specific management object defined in MIB-II are periodically issued to a specified IP address group (regardless of whether an agent is installed or not), and the result SNMP responses and ICMP echo responses are obtained.
[0037]
In this case, the polling interval of the SNMP request and ICMP echo request that are periodically issued, and the community name described on the SNMP protocol are acquired by referring to the environment setting file 180.
[0038]
MIB format information is created from the periodically acquired results, and the latest MIB format information is stored in the memory and is also transferred to the collection database management function 120 and stored in the collection MIB database 170.
[0039]
Further, the aggregation function 150 can refer to each information on the IP address and status of the management range and whether or not the agent is installed.
[0040]
Further, the trap management function 160 can refer to each information of the management range IP address and index number.
[0041]
In addition, when a change occurs in the information constituting the value of the collected MIB, such as addition or deletion of an IP node in the management range, a sub-manager extension trap is issued to notify the integrated manager 50 to that effect. To do.
[0042]
The MIB-II standards are RFC-1213, Management Information Base for Network Management of TPCIPIP, IP-based Internets: It is specified in MB2 (RFC 1213, “Management Information Base for Network Management of TCP / IP Based internets: MIB-II”).
[0043]
(3) Collection database management function 120
When the collection database management function 120 receives each piece of information constituting the collection MIB value from the management range monitoring function 110, the collection database management function 120 stores it in the collection MIB database 170, and sends a collection MIB value acquisition request from the sub-manager agent function 140. When input, the information constituting the value of the collected MIB is assembled in a managed object format and responded.
[0044]
(4) Own agent function 130
The own agent function 130 manages the host on which the sub-manager 10 exists, and inputs an SNMP request for the MIB-II and the agent extended MIB from the integrated manager 50 and the sub-manager 10 itself through the communication control function 100, and as a result. Is output to the communication control function 100.
[0045]
From the environment setting file 180, the community name (password for responding to the SNMP request) is referred to.
[0046]
(5) Sub-manager agent function 140
An SNMP request for the sub-manager extension MIB from the integrated manager 50 is input from the communication control function 100, and the acquisition source is distributed according to the managed object identifier described in the protocol of the SNMP request.
[0047]
That is, in the present invention, in order to provide management information collected and aggregated by the sub-manager 10 to the integrated manager 50, a sub-manager extension MIB composed of a periodic collection MIB and a real-time collection MIB is defined.
[0048]
The regularly collected MIB is a MIB obtained by converting the management information periodically collected by the sub-manager 10 to the IP node group in the management range.
[0049]
In the real-time collection MIB, the sub-manager 10 collects and aggregates (deletes and processes unnecessary information) management object information in real time in response to a reference request from the integration manager 50, and responds to the integration manager 50. Are summarized in the MIB format.
[0050]
In the case of a reference request for the periodic collection MIB, the sub-manager agent function 140 makes a MIB value acquisition request to the collection database management function 120 and acquires the result from the collection MIB database 170.
[0051]
In the case of a reference request for the real-time collection MIB, an MIB value acquisition request is made to the aggregation function 150 and the result is acquired from the aggregation function 150.
[0052]
Thereafter, the acquired result is output to the communication control function 100.
[0053]
From the environment setting file 180, the community name (password for responding to the SNMP request) is referred to.
[0054]
(6) Consolidation function 150
When an acquisition request for a real-time collected MIB value is input from the sub-manager agent function 140, an SNMP request is issued to an IP node group in which agents in the management range are installed. Further, after obtaining the response, the aggregation processing is performed, and the aggregated MIB value is returned to the sub-manager agent function 140.
[0055]
From the environment setting file 180, a community name described in the protocol is referred to when an SNMP request is issued.
[0056]
(7) Trap management function 160
The SNMP trap notified from the communication control function 100 is notified to all functions and applications that have established an internal interface with the trap management function 160. Also, a plurality of SNMP traps notified within a certain time are collected as one sub-manager extension trap and relayed to the integrated manager 50.
[0057]
The environment setting file 180 refers to the time interval for issuing the sub-manager extended trap, the community name described in the protocol, and the like.
[0058]
Hereinafter, the logical structure of the sub-manager extension MIB, which is the main part of the present invention, the determination method and monitoring method of the sub-manager management range, the distribution method of the SNMP requests received by the sub-manager, the management method of the collection MIB, and the aggregation of the collection MIB The method and the SNMP trap management method will be specifically described.
[0059]
(1) Logical structure of sub-manager extension MIB
In the IAB management standard, generally, the logical structure of a management object is defined in a virtual database called a management information base. This management information base is called MIB.
[0060]
It should be noted that the syntax for describing the MIB and a method for identifying an instance of a managed object are described in RFC 1155, Structure and Identification of Management Information for TSE • RFC 1155 “Structure and Identification of Management Information for TCP / IP-based internets” and RFC 1212, Concise MDB Definitions ( RFC 1212 “Consice MIB Definitions”).
[0061]
Here, the standard agent 20 implements a management object defined in MIB-II.
[0062]
The sub-manager 10 issues an SNMP request and an ICMP echo request for acquiring a specific MIB-II value from the IP node group in the management range, and obtains a value of the sub-manager extension MIB from the collection result.
[0063]
This sub-manager extension MIB is composed of a periodic collection MIB and a real-time collection MIB.
[0064]
The regularly collected MIB is a MIB obtained by converting the management information periodically collected by the sub-manager 10 to the IP node group in the management range. This data structure is composed of a table type managed object identifier composed of a plurality of entries and a non-table type managed object identifier.
[0065]
The table type management object identifier has an entry for each IP node in the management range, and each entry includes configuration information of the management range (IP address, host name, presence / absence of agent installation, IP router identification flag, etc.), In addition, state information such as an IP state and a response time of ping (ICMP echo request packet) is held.
[0066]
When a reference request is received from the integrated manager 50, a method is adopted in which entries made up of a plurality of information are grouped into information units made up of an index part and a context part, and the number of managed object identifiers to be returned is reduced.
[0067]
The non-table type management object identifier represents information obtained by tabulating the contents of the configuration information and state information of the table type management object identifier by the number of IP nodes.
[0068]
The sub-manager 10 is provided with a means for performing aggregation in order to provide the integrated management 50 with the aggregation information.
[0069]
On the other hand, the real-time collection MIB is a management that the sub-manager 10 returns to the integrated manager 50 by collecting and consolidating (deleting and processing unnecessary information) the status information in the management range in real time according to a reference request from the integrated manager 50. Information is converted to MIB.
[0070]
The sub-manager 10 receives the SNMP request from the integrated manager 50 and also from the sub-manager itself. This is because the sub-manager itself can be included in the management range of the sub-manager 10. In particular, when a real-time collection MIB reference request is received from the integrated manager 50, an SNMP request is issued to the sub-manager itself, and the results are aggregated and then returned to the integrated manager 50. Therefore, the sub-manager 10 is configured to be able to process a plurality of SNMP requests in parallel.
[0071]
Examples of definition of the periodic collection MIB, which is the sub-manager extension MIB, are shown in FIGS. 4 to 6, examples of definition of the real-time collection MIB are shown in FIGS.
[0072]
In the definition example of the periodic collection MIB of FIGS.
(1) Number of IP nodes to be managed
(2) Number of nodes whose status with the sub-manager is critical,
(3) TCP / IP interface that can communicate with the sub-manager but is not operating
The number of nodes on which the interface exists,
(4) Number of nodes on which all TCP / IP interfaces are operating,
(5) Number of routers within the management range of the sub-manager,
(6) The number of nodes that implement SNMP within the management range of the sub-manager,
(7) List of information on IP nodes in the management range of the sub-manager,
(8) An entry including information for each IP of the management range,
An example definition is shown.
[0073]
In the definition example of the real-time collection MIB of FIGS.
(1) A list of TCP connections within the management range of the sub-manager,
(2) IP address establishing the TCP connection,
(3) Port used by the node defined in smgSumTcpServerIpAddress
Number,
(4) IP address establishing the TCP connection (the address of the other party defined in smgSumTcpServerIp Address),
(5) Used by the IP node defined in smgSumTcpClientIpAddress
port number,
(6) TCP connection information entry established in the IP node in the management range,
An example definition is shown.
[0074]
In the definition example of the sub-manager extended trap in FIG.
(1) A trap notifying that a system has been added,
(2) A trap notifying that a system has been added,
(3) Relay trap
An example definition is shown.
[0075]
FIG. 11 is a correspondence table 190 when the MIB-II management object names (hereinafter referred to as MIB-II objects) collected by the sub-manager 10 regularly and in real time are converted into the extended MIB management object names. If the MIB-II objects are collected periodically and in real time from the agent 20 that has the MIB-II managed objects as standard, they are converted into the extended MIB managed object names according to the correspondence table 190.
[0076]
FIG. 12 shows the contents 200 of the smgIpNodeContext that is the management object of the converted regular collection MIB. As shown in the figure, the smgIpNodeContext includes an IP address 210, a host name 220, a status 230, a ping response time 240, SNMP support information 250, and router information 260.
[0077]
When the management object configured as described above is periodically collected and displayed by the integrated manager 50, a plurality of information regarding one agent or IP node can be displayed in one line, so that one agent or IP node is displayed. It is possible to easily check the state of
[0078]
FIG. 13 shows the contents 300 of smgSumTcpContext, which is a management object of the real-time collection MIB. As shown, smgSumTcpContext consists of IP address (part 1) 310, port number (part 1) 320, status (part 1) 330, IP address (part 2) 340, port number (part 2) 350, status (part 2) It is composed of 360 and service name 370.
[0079]
When the management object configured in this way is collected and displayed in real time by the integrated manager 50, a plurality of information related to one TCP connection can be displayed in one line, so that the state of one TCP connection can be easily achieved. It becomes possible to confirm.
[0080]
Further, as shown in the correspondence table 400 of FIG. 14, the periodic collection MIB is provided with management object names (identifiers) used for aggregating the values of the regular collection MIB, and the regular collection MIB according to the correspondence table 400. Are counted.
[0081]
FIG. 29 shows an example in which the aggregated management objects are collected by the integrated manager 50 at intervals of, for example, 10 minutes and displayed as a graph.
[0082]
(2) Sub-manager management range determination method and monitoring method
SmgCreateSystemTrap in FIG. 10 defines a sub-manager extended trap that is issued when an IP node is added to the sub-manager management range. The extended trap number is “1”, and the corresponding index number 520a of the management range table 500 shown in FIG. 16 is specified in the variable list (Variable-bindings).
[0083]
SmgDeleteSystemTrap in FIG. 10 defines a sub-manager extended trap that is issued when an IP node is deleted from the sub-manager management range. The extended trap number is “2”, and the corresponding index number 520a of the management range table 500 is specified in the variable list (Variable-bindings).
[0084]
FIG. 15 is a diagram showing the format of the environment setting file 180 used when determining the management range and monitoring range of the sub-manager. The acquisition community name 400, the setting community name 410, the trap destination 420, and the number of management ranges 430 are shown. , A management address range 440 and a trap relay interval 450 are respectively stored.
[0085]
Among these, the acquisition community name 400 is a name for performing authentication when an SNMP acquisition request is received, and is also used when the sub-manager 10 issues a sub-manager extended trap.
[0086]
The setting community name 410 is a name for performing authentication when an SNMP setting request is received.
[0087]
The trap destination 420 is an IP address of a partner to which the sub-manager 10 issues a sub-manager extended trap, and a plurality of trap destinations 420a and 420b can be designated.
[0088]
The management range number 430 is information for designating the maximum number of IP nodes included in the management range of the sub-manager 10.
[0089]
The management address range 440 is information for specifying the IP address, community name, polling interval, and timeout time of the IP node that is the target of the management range, and a plurality of sets can be specified as shown in the diagrams 440a and 440b. A range of IP addresses can be specified for each group. For example, the management address range 440a indicates that IP addresses from 200.10.20.1 to 200.10.20.70 are designated.
[0090]
The community name in the management address range 440 is used when the sub-manager 10 issues an SNMP request to an agent in the management range.
[0091]
In addition, the initial value (default value) of the polling interval when regularly collecting the management objects of the agent is set to 5 minutes, for example. The initial value of the timeout time is set to 1 second, for example. Furthermore, the initial value of the trap relay interval 450 is set to 10 minutes, for example.
[0092]
FIG. 16 is a diagram showing the format of the management range table 500 provided in the management range monitoring function 110, which is composed of a control unit and a plurality of entries. The maximum number of entries is the number of management ranges 430 in FIG. It is the same number as the specified value.
[0093]
The control unit is configured with an area for storing the community name for acquisition 510a and the like. The contents imported from the environment setting file 180 to the control unit will be described as follows.
[0094]
The acquisition community name 510a is the acquisition community name 400, the setting community name 510b is the setting community name 410, the management range number 510c is the management range number 430, the trap destination number 510d and the trap destination table address 510e. Is set with the number of destinations specified by the trap destination 420 and the IP address of the destination. Other contents will be described with reference to FIGS.
[0095]
FIG. 17 shows an outline of main processing of the management range monitoring function 110. First, the management range is initialized (step 600), and a loop is executed until an end request is received (step 610). During this time, monitoring of the management range (step 620), aggregation processing (step 630), and updating of the management range (step 640) are performed in order.
[0096]
FIG. 18 shows an outline of initial setting of the management range (step 600). The environment setting file 180 is referred to and the management range table 500 is set (steps 650 and 651).
[0097]
In order to set only existing IP addresses among the IP addresses specified in the management address range 440 to the IP address 520b of the entry in the management range table 500, the following processing is performed. First, in order to acquire the IP address recognized by the sub-manager 10, atNetAddress, which is a MIB-II address translation group, is acquired from the own agent function 130 (step 652) (step 652).
[0098]
The acquired atNetAddress value indicates the correspondence between the IP address and the physical address. The management range table 500 loops while an empty entry 520 exists and an IP address of atNetAddress exists (step 653).
[0099]
It is determined whether the IP address of atNetAddress is included in the management address range 440 of FIG. 15 (step 654), and ping is issued only for the included IP address (step 655).
[0100]
Then, the presence / absence of a ping response is determined (step 656), and the IP address with the response is set to the IP address 520b of the empty entry 520 in the management range table 500. Further, a sub-manager extended trap is issued to notify the integrated manager 50 that an IP node has been added to the management range (step 658).
[0101]
Next, the community name, polling interval, and time-out time for the IP address are acquired from the management address range 440 of the environment setting file 180, and the community name 520c, polling interval 520d, and time-out time 520e are set (step). 659).
[0102]
Next, the host name 520f of the IP address 520b is set with reference to the / etc / hosts file (included in the information for each IP node in FIG. 6) (step 660). Thereafter, “Normal” is set in the status 520g (step 661).
[0103]
FIG. 19 shows an outline of management range monitoring (step 620).
[0104]
The management range table 500 is referred to (step 670), and a loop is performed for the number of entries 520 in which the IP address 520b is set.
[0105]
During this time, ping processing is performed (step 672). It is determined whether the IP address 520b is set in the entry 520 and the status 520g is other than “Critical” (step 673). , IpForwarding) (see FIG. 11), an SNMP request is issued (step 674).
[0106]
Next, it is determined whether or not there is an SNMP request response (step 675). If there is a response, “snmp” is set in the SNMP support information 520j of the entry 520 (step 676), and router determination is performed (step 677).
[0107]
If there is no response, “nonsnmp” is set in the SNMP support information 520j of the entry 520 (step 678), and “host” is set in the router support information 520k (step 679).
[0108]
FIG. 20 shows an outline of the router determination (step 677). As an initial setting, “host” is set in the router support information 520k (step 690). The MIB-II ipForwarding value (see FIG. 11) is determined (step 691). If it is “1” (gateway), the process proceeds to step 692, and if it is not “1” (host), the process proceeds to step 698.
[0109]
The MIB-II ifNumber value indicating the number of interfaces is determined (step 692). If it is "2" or more, the process proceeds to step 693. If "1", the status 520g is set to "Normal" (step 697). ).
[0110]
There are multiple interfaces other than the MIB-II ifType value indicating the interface type other than “24” (softwareLoopback), and the MIBO-II ifOperStatus values indicating the status are all “1” (up). (Step 693). If the condition is satisfied, “router” is set in the router support information 520k (step 694), and “Normal” is set in the status 520g (step 695).
[0111]
If the condition is not satisfied, “Marginal” is set in the status 520g (step 696).
[0112]
If the MIB-II ipForwarding value is other than “1” (host) (step 691), the MIB-II ifNumber value indicating the number of interfaces is determined (step 698). Proceeding to step 699, if "1", the status 520g is set to "Normal" (step 702).
[0113]
In step 699, the same determination as in step 693 is performed. If the condition is satisfied, "Normal" is set in the status 520g (step 700), and if the condition is not satisfied, "Marginal" is set in the status 520g (step 701).
[0114]
FIG. 21 shows an outline of the ping process (step 672).
[0115]
First, the ping response time 520h of the entry 520 is cleared (step 710), a ping is issued to the designated IP address (step 711), and the presence or absence of the response is confirmed (step 712). When there is a ping response (step 712), setting of the ping response time 520h of the entry 520 (step 713), clearing of the oldest time 520i when the ping response is lost (step 714), SNMP support information 520j (Step 715).
[0116]
When the SNMP support information 520j is “nonsnmp”, “Normal” is set in the status 520g (step 716), and when it is “snmp”, “Marginal” is set in the status 520g (step 717).
[0117]
If there is no ping response (step 712), "Critical" is set in the status 520g of the entry 520 (step 718), and the earliest time 520i at which the ping response is lost is confirmed (step 719).
[0118]
When the oldest time 520i exists (step 719) and a certain time (for example, one week) has passed (step 720), the contents 520a to 520k are deleted from the entry 520 (step 721), and the integrated manager A sub-manager extended trap is issued to notify 50 that the IP node has been deleted from the management range (step 722).
[0119]
When the oldest time 520i does not exist (step 719), the current time is set (step 723).
[0120]
FIG. 22 shows an outline of the tabulation process (step 630).
[0121]
First, the portions 510f to 510k for counting the number of IP addresses in the control unit of the management range table 500 are cleared, and a loop is performed for the number of entries 520 (step 732). Only when an IP address is set in the entry 520, the entry is incremented (+1) under the following conditions.
[0122]
That is, smgTotalManagedNodeNumber is unconditionally (step 734), smgTotalCriticalNodeNumber is only when status 520g is "Critical" (step 736), smgTotalMarginalNodeNumber is only when status 520g is "Marginal" (step 737), and smgTotalNormalNodeNumber is status 520g " Only when “Normal” (step 738), smgTotalRouterNodeNumber is incremented only when the router support information 520k is “router” (step 740), and smgTotalSnmpSupportNodeNumber is incremented only when the SNMP support information 520j is “snmp” (step 742). .
[0123]
When a difference occurs between the results before and after the aggregation (step 743), the difference information is stored in the collection database management function 120 (step 744).
[0124]
FIG. 23 shows an outline of the management range update (step 640).
[0125]
First, it operates after confirming that a fixed time, for example, 3 hours, has passed since the last update time (step 750).
[0126]
The management range table 500 has an empty entry 520, loops only for IP addresses whose status 520g is other than “Critical” and whose SNMP support information 520j is “snmp” (step 751).
[0127]
Next, an SNMP request is issued to obtain the MIB-II atNetAddress for the IP address 520b of the entry (step 752).
[0128]
When there is a response to the SNMP request (step 752), while there is an empty entry 520, a loop is performed for the number of acquired IP addresses (step 754), and update processing is performed (step 755).
[0129]
If there is no SNMP request response (step 752), "Critical" is set to update the status 520g (step 756).
[0130]
FIG. 24 shows an outline of the update process (step 755).
[0131]
First, it is determined whether the IP address does not exist in the IP address 520b of the management range table 500 and is included in the management address range 440 of the environment setting file 180 (step 760), and the following processing is performed only when the condition is satisfied. .
[0132]
That is, the IP address is set in the empty entry 520 (step 761), and a sub-manager extension trap is issued to notify the integrated manager 50 that an IP node has been added to the management range (step 762).
[0133]
By performing the processing as described above, the sub-manager 10 can not only limit the number of IP nodes included in the management range, but also can monitor only existing IP nodes.
[0134]
(3) SNMP request distribution method received by the sub-manager
The communication control function 100 receives an SNMP request from the integration function 50 of the integrated manager 50 and the sub-manager 10 and an SNMP trap from the agent 20.
[0135]
The sub-manager agent function 140 distributes the SNMP request input from the communication control function 100 according to the management object identifier, and relays it to the collection MIB database management function 120 or the aggregation function 150.
[0136]
The main reason for providing the two agent functions of the own agent function 130 and the sub-manager agent function 140 is that it is necessary to process the SNMP request from the integration manager 50 and the SNMP request from the aggregation function 150 in parallel. . That is, when the SNMP request is received from the integrated manager 50 to the real-time collection MIB of the sub-manager 10 by processing the SNMP request in parallel, the aggregation function 150 is automatically transmitted via the communication control function 100 by the extension. An SNMP request is issued to the agent function 130, and a real-time collection MIB value is created based on the result, and an SNMP response can be returned to the integration manager 50.
[0137]
FIG. 25 shows an outline of the distribution method by the management object of the communication control function 100. The communication control function 100 loops until an end request is received (step 770). The received data includes an SNMP request from the integration function 150 of the integrated manager 50 and the sub-manager 10, an SNMP response from the own agent 130 and the sub-manager agent function 140, and an SNMP trap from the agent. It is determined whether or not there is (step 771).
[0138]
First, when an SNMP request is received, it is determined whether or not it is a sub-manager extension MIB in order to perform distribution based on the management object identifier in the protocol of the SNMP request (step 772). If it is a sub-manager extension MIB, the sub-manager agent function 140 is notified (step 773). However, if it is not the sub-manager extension MIB, the self-agent function 130 is notified (step 774).
[0139]
On the other hand, when the SNMP response is received, the response is returned to the integration manager 50 (step 775).
[0140]
If an SNMP trap is received, the trap management function 160 is notified (step 776).
[0141]
FIG. 26 shows an outline of the distribution method by the management object of the sub-manager agent function 140.
[0142]
First, the sub-manager agent function 140 loops until an end request is received (step 780).
[0143]
Since the received data includes an SNMP request from the communication control function 100 and a MIB value result response from the collection database management function 120 and the aggregation function 150, it is determined which of these is received (step 781).
[0144]
If an SNMP request is received, it is determined whether it is a MIB acquisition request and the community names match (step 782). The community name is confirmed by comparing the community name in the SNMP request protocol with the community name 400 for acquisition shown in FIG.
[0145]
When the determination condition of step 782 is satisfied, the operation is determined (step 783).
[0146]
If the operation is get-next, the next specified managed object identifier is obtained and used as the requested managed object identifier (step 784). Next, it is determined whether it is a regular collection MIB or a real-time collection MIB (step 785). If it is a regular collection MIB, it notifies the collection database management function 120 (step 786). (Step 787).
[0147]
If the determination condition of step 782 is not satisfied, an error response is returned to the communication control function 100 (step 788).
[0148]
On the other hand, when the result response is received, the SNMP response is assembled (step 789), and the communication control function 100 is responded (step 790).
[0149]
(4) Collection MIB Management Method in Collection Database Management Function 120
Here, a method of dividing and managing managed objects and assembling the managed objects when responding to MIB values will be described.
[0150]
The collection database management function 120 inputs each piece of information constituting the periodic collection MIB from the management range monitoring function 110, holds it in the memory, and stores it in the collection MIB database 170.
[0151]
As shown in FIG. 27, each piece of information includes smgIpNodeIndex 810, IP address 210 that is the content 200 of smgIpNodeContext, host name 220, status 230, ping response time 240, SNMP support information 250, and router information 260. .
[0152]
That is, the collection database management function 120 performs individual management for each information unit constituting a management object, not for each management object that is a periodic collection MIB. The collection database management function 120 receives only the smgIpNodeIndex 810 that is the key information for identifying the IP node from the management range monitoring function 110 and the changed status 230, for example, the status 230, and the collection database management function 120 and the management range monitoring function 110 It is configured to reduce the amount of data exchanged between them.
[0153]
When an arbitrary IP node is deleted from the management range of the sub-manager 10, a deletion request for smgIpNodeIndex 810 is input from the management range monitoring function 110, and the collection database management function 120 changes the flag 800 from “present” to “none” By doing so, the management of IP nodes in the management range is performed.
[0154]
Further, when a reference request for individual information constituting the periodic collection MIB is received from the management range monitoring function 110, the key information smgIpNodeIndex 810 and the requested individual information are provided. This is mainly performed in order to make the correspondence between the smgIpNodeIndex 810 and the IP address 210 shown in FIG. 27 the same as the correspondence before the restart even when the sub-manager 10 is restarted.
[0155]
The collection database management function 120 stores the individual information constituting the periodic collection MIB in the collection MIB database 170 in order to maintain the correspondence relationship.
[0156]
When the sub-manager 10 receives an acquisition request for the periodic collection MIB from the integrated manager 50, the collection database management function 120 issues an acquisition request for the periodic collection MIB value via the communication control function 100 and the sub-manager agent function 140. Receive.
[0157]
The collection database management function 120 assembles a periodic collection MIB value from individual information constituting the periodic collection MIB, and returns the result to the integrated manager 50 via the sub-manager agent function 140 and the communication control function 100.
[0158]
Here, assembling the periodically collected MIB value means that, as shown in FIG. 27, IP address 210, host name 220, status 230, ping response time 240, SNMP indicating one agent or IP node characteristics and IP status, SNMP Each information of the support information 250 and the router information 260 is collected into one management object, smgIpNodeContext200.
[0159]
FIG. 28 shows an outline of the operation of the collection database management function 120.
[0160]
The collection database management function 120 loops until an end request is received (step 820).
[0161]
Since the data to be received (step 821) includes a request for acquisition of a periodic collection MIB from the sub-manager agent function 140, a storage request from the management range monitoring function 110, and a reference request, it is determined which one (step 821). ).
[0162]
When an acquisition request is received, a get-next operation is determined (step 822), and if it is a get-next operation, the next specified index (smgIpNodeIndex 810) is obtained (step 823).
[0163]
In the next step 824, the presence / absence of an index is determined using the flag 800 of FIG. This is mainly for confirming the index specified by the get operation.
[0164]
If the index exists, step 825 creates a responding periodic collection MIB value. In other words, when the smgIpNodeContext 200 is requested, it is assembled, and when the management object representing the total result, which is the periodic collection MIB shown in FIG. 14, is requested, it is excluded from the objects to be assembled.
[0165]
Thereafter, the MIB value is returned to the sub-manager agent function 140 (step 826). If the index does not exist, an error response is returned to the sub-manager agent function 140 (step 827).
[0166]
When the storage request is received, after inputting the smgIpNodeIndex 810 which is the key information constituting the periodic collection MIB and the content 200 of the smgIpNodeContext to be updated from the management range monitoring function 110 and searching for the corresponding IP node by the key information, The content 200 of smgIpNodeContext held in the memory is updated (step 828).
[0167]
When adding or deleting an arbitrary IP node from the management range of the sub-manager 10, the flag 800 in FIG. 27 is updated (changed) to “present” or “none”, respectively.
[0168]
Thereafter, the collected MIB database 170 is updated (step 829).
[0169]
Since the management object shown in FIG. 14 that represents the collection result that is the collected MIB cannot be divided and managed, the MIB value is simply updated.
[0170]
When the reference request is received, the management range monitoring function 110 is provided with the requested individual information out of the contents 200 of the smgIpNodeIndex 810 and the smgIpNodeContext that are the key information constituting the periodic collection MIB (step 830). Since the management object representing the aggregated result that is the periodically collected MIB shown in FIG. 14 is not dividedly managed, the MIB value is simply provided.
[0171]
(5) Collection and aggregation method in the aggregation function 150
For example, if there is a TCP connection as shown in FIG. 30, the aggregation function 150 aggregates the TCP connection 1000 between IP nodes in the management range and the TCP connection 1010 between the IP node in the management range and the IP node outside the management range. The target of. The TCP connection 1020 between IP nodes outside the management range is not targeted. That is, at least one end of the TCP connection is an IP node in the management range, and the IP node is a target of aggregation for the TCP connection in which the agent 20 is mounted.
[0172]
FIG. 31 shows the MIB-II tcpConnState index and MIB value format that the aggregation function 150 collects from agents in the management range.
[0173]
FIG. 32 is a real-time collection MIB of the sub-manager 10 and shows the smgSumTcpContext index and MIB value format for which the MIB value is requested from the integrated manager 50.
[0174]
FIG. 33 shows the conversion between FIG. 31 and FIG. The IP address (part 1) 310, the port number (part 1) 320, the IP address (part 1) 330, and the port number (part 2) 340 of the smgSumTcpContext index requested from the integration manager 50 are respectively set to the IP address (part 1). ) 310, and used as the local IP address 1120, local TCP port 1130, remote IP address 1140, and remote TCP port 1150 in the index of tcpConnState 1100.
[0175]
The value 1160 of tcpConnState is set in the status (part 1) 330 of smgSumTcpContext.
[0176]
Similarly, the remote IP address 1120, remote TCP port 1130, local IP address 1140, and local TCP port 1150 of the index of tcpConnState 1110 are used. Also, the value 1170 of tcpConnState is set to the status (part 2) 360 of smgSumTcpContext.
[0177]
The service name 370 of smgSumTcpContext refers to the / etc / services file and acquires and sets the service name corresponding to the port number (part 1) 320 or the port number (part 2) 350.
[0178]
FIG. 34 explains the order of the indexes shown in FIG. 32, and is related to the order of the entries 520 in the management range table 500.
[0179]
In the IP address (part 1) 310, the IP address 520b is arranged in order from the top of the entry. The port number (part 1) 320 and the port number (part 2) 350 are arranged in order from the smallest port number. Further, the IP address (part 2) 340 is arranged in order from the IP address 520b of the next entry of the IP address (part 1) 310, and finally the IP address is out of the management range.
[0180]
FIG. 35 shows an outline of the main process of the aggregation function 150, and loops until an end request is received (step 1200).
[0181]
The operation is started when an aggregate MIB acquisition request is received from the sub-manager agent function 140 (step 1201). First, the operation is determined (step 1202). If it is a get operation, the get process (step 1203) is performed. In the case of, get-next processing is performed (step 1204).
[0182]
Next, error determination is performed (step 1205). When there is no error, the service name is acquired (step 1206) and the contents of the smgSumTcpContext to be responded are assembled (step 1207). Further, a result response is returned to the sub-manager agent function 140 (step 1208).
[0183]
If there is an error, an error response is returned to the sub-manager agent function 140 (step 1209).
[0184]
FIG. 36 shows an outline of the get process (step 1203). First, the index shown in FIG. 33 is decomposed (step 1250) to determine whether the IP address is included in the management range (step 1252). For this purpose, the management range table 500 is referred to (step 1251).
[0185]
When only the IP address (part 1) is included in the management range, get issuance is executed only for the IP address (part 1) (steps 1253 and 1254).
[0186]
Similarly, when only the IP address (part 2) is included in the management range, get issuance is executed only for the IP address (part 2) (steps 1255 and 1256).
[0187]
However, when both IP addresses are included in the management range, get issue is first executed for the IP address (part 1) (steps 1257 and 1258), and only when there is no error, the IP address (part 2) is set. A get issue is executed (steps 1259, 1260, 1261).
[0188]
If both IP addresses are not included in the management range, an error is returned (step 1262).
[0189]
FIG. 37 shows an outline of get issuance executed in FIG.
[0190]
In order to obtain the MIB-II value efficiently, the management range table 500 is referred to, whether the status 520g of the IP address is “Marginal” or “Normal”, and the SNMP support information 520j is “snmp”. Determination is made (step 1270).
[0191]
When the condition is satisfied, the management object identifier shown in FIG. 33 is converted (step 1271), and a get request is issued (step 1272).
[0192]
Next, the presence / absence of a response to the get request and the error (steps 1273 and 1274) are determined, and if the condition is satisfied, the acquisition result is returned (step 1275).
[0193]
If the conditions of step 1270, step 1273, and step 1274 are not satisfied, an error is returned (steps 1278, 1277, 1276).
[0194]
FIG. 38 shows an outline of the get-next process (step 1204).
[0195]
First, the presence / absence of an index designation is determined (step 1280). If it exists, the index is decomposed in the same manner as in step 1250 (step 1281).
[0196]
When the index is not specified, the next index calculation is executed to obtain the head index (step 1282).
[0197]
Next, in order to determine whether the IP address is within the management range, the same determination as in step 1252 of FIG. 36 is performed (step 1284).
[0198]
In this determination, when only the IP address (part 1) is included in the management range, get-next issuance (steps 1285, 1286) is executed only for the IP address (part 1).
[0199]
Similarly, when only the IP address (part 2) is included in the management range, get-next issuance is executed only for the IP address (part 2) (steps 1287 and 1288).
[0200]
When both IP addresses are included in the management range, first, get-next is issued to the IP address (part 1) (steps 1289 and 1290), and only when there is no error, get for the connection partner address. -Next issue is executed (steps 1291, 1292, 1293).
[0201]
If both IP addresses are not included in the management range, an error is returned (step 1294).
[0202]
FIG. 39 shows an overview of the next index calculation.
[0203]
First, the presence / absence of the designated index is determined (step 1300). If the index does not exist, retrieval is performed in order from the first entry in the management range table 500 to obtain the first index, and the status 520g is “Marginal” or “Normal”. The IP address 520b that is "SNMP" and the SNMP support information is "snmp" is set as a new IP address (part 1) 310 (step 1301).
[0204]
The port number (part 1) 330 is "0", the IP address (part 2) 340 is "0.0.0.0", the port number (part 2) 350 is "0", Set each.
[0205]
However, when there is an index in step 1300, the management range table 500 is searched in order to obtain the next index efficiently, and the IP address (part 1) 310 and subsequent ones are searched according to the index order shown in FIG. The IP address 520b that is the IP address 520b, the status 520g is “Marginal” or “Normal”, and the SNMP support information is “snmp” is set as a new IP address (part 1) 310 (step 1305).
[0206]
FIG. 40 shows an outline of the get-next issue executed in FIG.
[0207]
First, in order to obtain the MIB-II value efficiently, the management range table 500 is referred to, the status 520g of the IP address is “Marginal” or “Normal”, and the SNMP support information 520j is “snmp”. It is determined whether it exists (step 1310).
[0208]
If the condition is satisfied, the management object identifier shown in FIG. 33 is converted (step 1311), and a get-next request is issued (step 1312).
[0209]
Next, the management object identifier of the acquisition result is determined (step 1313), and if it is tcpConnState, it is determined whether it is a TCP connection between IP nodes (step 1314).
[0210]
If it is a TCP connection between IP nodes, an acquisition result is returned (step 1315), and if it is not a TCP connection between IP nodes, get-next issuance is executed again (step 1316).
[0211]
If it is not tcpConnState in step 1313, the next index calculation is executed and the presence / absence of the next index is determined (steps 1317 and 1318). If it exists, get-next is issued (step 1319). Is returned (step 1320).
[0212]
If the condition in step 1310 is not satisfied, the same processing as in steps 1317 to 1320 is performed.
[0213]
(6) SNMP trap reduction method in trap management function 160
The smgIntermediaryTrap in FIG. 10 defines a sub-manager extended trap relayed by the sub-manager 10 in order to reduce the number of management packets used by the SNMP trap, and the extended trap number is “3”.
[0214]
The community name for acquisition 400 in the environment setting file 180 described in FIG. 15 is also used when the sub-manager 10 issues a sub-manager extended trap. The trap destination 420 is an IP address of a partner to which the sub-manager 10 issues a sub-manager extended trap, and a plurality of trap destinations 420 can be designated. The trap relay interval 450 is a time for storing SNMP traps received from the agent 20 that is the management range of the sub-manager. When SNMP traps are received during this time, the trap relay intervals 450 are combined into one sub-manager extended trap and relayed to the integrated manager 50. To do.
[0215]
FIG. 41 shows an outline of conversion from the SNMP trap received by the sub-manager 10 from the management range agent 20 to the sub-manager extended trap.
[0216]
A format 1400 of smgIntermediaryTrap which is a sub-manager extension trap is composed of a trap header 1410 and Variable-bindings 1420.
[0217]
The trap header 1410 includes an enterprise 1411, an agent-addr 1412, a generic-trap 1413, a specific-trap 1414, and a time-stamp 1415. The sub-manager 10 sysObjectID, the sub-manager 10 IP addresses “6” and “3”, and the sub-manager 10 respectively. Write sysUpTime.
[0218]
Variable-bindings 1420 describes the contents of the received SNMP traps in order.
[0219]
FIG. 42 shows details of conversion from the SNMP trap to the sub-manager extended trap.
[0220]
The variable-bindings 1420 in the smgIntermediaryTrap format 1400 mainly includes smgIpNodeIndex 1430, smgEnterprise1431, smgAgentAddr1432, smgGenericTrap1433, smgSpecificTrap1434, and VarBindList1435.
[0221]
In smgIpNodeIndex 1430, the index number 520a of the management range table 500 corresponding to agent-addr 1462, which is the IP address that issued the SNMP trap, is described.
[0222]
In smgEnterprise1431, smgAgentAddr1432, smgGenericTrap1433, and smgSpecificTrap1434, SNMP trap enterprise 1461, agent-addr1462, generic-trap 1463, and specific-trap 1464 received from the agent 20 in the management range are described, respectively.
[0223]
VarBindList 1435 describes Variable-bindings 1470 of the received SNMP trap.
[0224]
FIG. 43 shows an outline of the SNMP trap reduction method.
[0225]
First, the environment setting file 180 is referred to (step 1500), and a loop is executed (step 1501) until an end request is received.
[0226]
Next, a buffer is secured (step 1502), loops only during the trap relay interval 450 (see FIG. 15) (step 1503), and an SNMP trap is received (step 1504).
[0227]
In order to check whether the received SNMP trap is from the agent 20 in the sub-manager management range, the IP address 520b and the index 520a are referred from the management range table 500 (step 1505).
[0228]
If the received SNMP trap is issued by the agent 20 in the sub-manager management range, the index 520a and the received SNMP trap are stored in the buffer (steps 1506 and 1507).
[0229]
A sub-manager extension trap is assembled from the contents of this buffer (step 1508), and a sub-manager extension trap is issued to the integrated manager 50 (step 1509). Thereafter, the buffer is released (step 1510).
[0230]
Although the details of the sub-manager 10 that is the main part of the present invention have been described above, according to the present embodiment, by referring to the periodic collection MIB and the real-time collection MIB that are the extended MIBs of the sub-manager 10 from the integrated manager 50. There are the following effects.
[0231]
(1) When referring to the regularly collected MIB
The sub-manager 10 periodically issues a ping (ICMP echo request packet) and an SNMP request packet to the IP nodes within the sub-manager management range, and holds the response result as a periodic collection MIB that is one of the sub-manager extension MIBs. By doing so, it is possible to immediately respond to the SNMP acquisition request from the integration manager 50.
[0232]
The periodic collection MIB has 1 property [index, IP address, host name, IP status, ping response time, SNMP implementation flag, IP router implementation flag] of the IP node in the sub-manager management range (managed object identifier / IP node). The network manager on the integrated manager 50 side refers to the periodic collection MIB of the sub-manager 10 in accordance with the usage. By doing so, the configuration information and status information of the sub-manager management range can be confirmed.
[0233]
Furthermore, the number of management packets between the integrated manager 50 and the sub-manager 10 can be reduced by the number of aggregations of the regularly collected MIBs.
[0234]
(2) When referring to the real-time collection MIB
In accordance with a reference request to the real-time collection MIB from the integrated manager 50 to the sub-manager 10, the management objects of each agent are collected and aggregated in real time and returned to the integrated manager 50. Therefore, fewer resources (CPU power, memory capacity) and The latest status of the sub-manager management range can be grasped with a small number of management packets. In addition, the time error between agents can be reduced.
[0235]
In addition, by managing the TCP connection information in the sub-manager management range as a real-time collection MIB, it is possible to specify an IP node and a service having a high traffic in the management range of the sub-manager 10 with few operations in the integrated manager 50. Furthermore, the number of management packets between the integrated manager 50 and the sub-manager 10 can be reduced as compared with the case where the sub-manager 10 does not exist.
[0236]
Furthermore, by issuing the sub-manager extended trap, the change of the sub-manager management range and the SNMP trap received from the agent can be transmitted to the integrated manager 50 efficiently.
[0237]
In the logical relationship diagram of FIG. 2, there are three layers from the agent to the integrated manager, but the present invention is not limited to this.
[0238]
【The invention's effect】
As described above, in the present invention, SNMP is used as a communication protocol between the agent and the sub-manager and between the sub-manager and the integrated manager, and the sub-manager is connected via the agent belonging to its own management range. Management objects in the management range are periodically collected, MIB collection information is created from the collected results, the collected MIB information is stored in the collection MIB database, and the collected information is used as a reference request from the integrated manager. Accordingly, since the integrated manager is notified in the MIB format, it is possible to hierarchically manage a large-scale communication network based on the SNMP of the IAB management standard with a sub-manager with a simple configuration.
[0239]
In addition, in response to a reference request from the integrated manager, multiple information from each agent managed by multiple identifiers is aggregated and notified to the integrated manager, so there is a small amount of management packets between the integrated manager and the sub-manager. Management information can be transmitted, and a large-scale communication network can be managed with low traffic and low cost. Furthermore, the load on the integrated manager can be reduced.
[0240]
Further, the network manager on the integrated manager side can confirm the configuration information and status information of the sub-manager management range by referring to the sub-manager periodic collection MIB according to the usage.
[0241]
Further, when management objects are collected and notified to the integrated manager in real time, the latest state of the sub-manager management range can be grasped with a small number of resources (CPU power and memory capacity) and a small number of management packets.
[0242]
In addition, by managing TCP connection information in the sub-manager management range as a real-time collection MIB, it is possible to specify an IP node and a service with high traffic in the management range of the sub-manager 10 with few operations in the integrated manager. It is done.
[Brief description of the drawings]
FIG. 1 is a system configuration diagram showing an embodiment of a communication network management system in which an integrated manager, sub-managers, and agents are arranged.
FIG. 2 is a logical relationship diagram showing a logical relationship among the integrated manager, sub-manager, and agent in FIG.
FIG. 3 is a functional configuration diagram showing a detailed configuration of a sub-manager that is a main part of the present invention.
FIG. 4 is an explanatory diagram of a definition example (part 1) of a regularly collected MIB that is a sub-manager extended MIB;
FIG. 5 is an explanatory diagram of a definition example (part 2) of a periodic collection MIB that is a sub-manager extension MIB;
FIG. 6 is an explanatory diagram of a definition example (part 3) of a regularly collected MIB that is a sub-manager extended MIB;
FIG. 7 is an explanatory diagram showing a definition example (No. 1) of a real-time collection MIB that is a sub-manager extension MIB;
FIG. 8 is an explanatory diagram of a definition example (No. 2) of a real-time collection MIB that is a sub-manager extension MIB;
FIG. 9 is an explanatory diagram of a definition example (No. 3) of a real-time collection MIB that is a sub-manager extension MIB;
FIG. 10 is an explanatory diagram of a definition example of a sub-manager extended trap.
FIG. 11 is a diagram showing a correspondence table of managed objects to be converted from MIB-II to sub-manager extension MIB.
FIG. 12 is an explanatory diagram showing contents of smgIpNodeContext that is a sub-manager extension MIB;
FIG. 13 is an explanatory diagram showing the contents of smgSumTcpContext, which is a sub-manager extension MIB.
FIG. 14 is a diagram showing a correspondence table of regularly collected MIBs to be aggregated.
FIG. 15 is an explanatory diagram illustrating an example of an environment setting file.
FIG. 16 is an explanatory diagram illustrating an example of the contents of a management range table.
FIG. 17 is a schematic PAD diagram of a management range monitoring method (main).
FIG. 18 is a schematic PAD diagram of initial setting of a management range.
FIG. 19 is a schematic PAD diagram of management range monitoring;
FIG. 20 is a schematic PAD diagram of router determination.
FIG. 21 is a schematic PAD diagram of a ping process.
FIG. 22 is a schematic PAD diagram of tabulation processing.
FIG. 23 is a schematic PAD diagram for updating a management range;
FIG. 24 is a schematic PAD diagram of update processing.
FIG. 25 is a schematic PAD diagram of a distribution method in a communication control function.
FIG. 26 is a schematic PAD diagram of a distribution method in the sub-manager agent function.
FIG. 27 is an explanatory diagram showing an example of the contents of a regularly collected MIB value management table.
FIG. 28 is a schematic PAD diagram of a collection database management function.
FIG. 29 is an explanatory diagram showing a graph display example in the integrated manager of the total value which is a regularly collected MIB.
FIG. 30 is an explanatory diagram illustrating an example of a TCP connection targeted by an aggregation function;
FIG. 31 is an explanatory diagram showing MIB-II tcpConnState index and value formats;
FIG. 32 is an explanatory diagram showing an index and a value format of a smgSumTcpContext of a real-time collection MIB;
FIG. 33 is an explanatory diagram of conversion between tcpConnState of MIB-II and smgSumTcpContext of real-time collection MIB.
FIG. 34 is an explanatory diagram showing the order of indexes of a real-time collection MIB.
FIG. 35 is a schematic PAD diagram of a management range aggregation method (main).
FIG. 36 is a schematic PAD diagram of a management range aggregation method (get process);
FIG. 37 is a schematic PAD diagram of a management range aggregation method (get issue).
FIG. 38 is a schematic PAD diagram of a management range aggregation method (get-next process);
FIG. 39 is a schematic PAD diagram of a management range aggregation method (next index calculation);
FIG. 40 is a schematic PAD diagram of a management range aggregation method (get-next issuance).
FIG. 41 is a conversion diagram from an SNMP trap to a sub-manager extension trap.
FIG. 42 is a conversion diagram from an SNMP trap to a sub-manager extension trap.
FIG. 43 is a schematic PAD diagram of a method for reducing SNMP traps.
[Explanation of symbols]
10, 10a, 10b, 10c... Sub-manager, 20, 20a-1, 20a-2, 20b-1, 20b-2, 20c... Agent, 30a, 30c. ... Communication control function, 110 ... Management range monitoring function, 120 ... Collection database management function, 130 ... Self-agent function, 140 ... Sub-manager agent function, 150 ... Aggregation function, 160 ... Trap management function, 170 ... Collection MIB database, 180 ... environment setting file, 500 ... management range table.

Claims (10)

A plurality of agents that manage and control management objects such as configuration information and status information for each resource unit of the communication network, and a part of the management objects of the communication network via the agent of the group for a predetermined agent group unit A sub-manager that manages and controls; and an integrated manager that manages and controls managed objects of the entire communication network via the sub-manager, and a communication protocol between the agent and the sub-manager, and between the sub-manager and the integrated manager As a hierarchical network management system using SNMP as a management method, the management object of the same management range is periodically collected in the sub-manager via an agent belonging to the management range of itself, and the MIB format is obtained from the collected result. Collection of MIB information And a periodic collection unit that stores the collected MIB information in a collected MIB database and notifies the integrated manager of the collected information in the MIB format in response to a reference request from the integrated manager. Network management system. 2. The hierarchical network management system according to claim 1, wherein the periodic collection unit periodically collects management objects that are not installed or activated by an agent using the ICMP protocol . 2. The hierarchical type according to claim 1, wherein the periodic collection unit aggregates a plurality of pieces of information about each agent managed by a plurality of identifiers in response to a reference request from the integrated manager and notifies the integrated manager. Network management system. The sub-manager comprises means for analyzing an SNMP trap received from an agent existing in its own management range and relaying a plurality of SNMP traps as a single sub-manager extension trap to the integrated manager. The hierarchical network management system according to claim 1. The sub-manager further comprises real-time collection means for collecting in real time the status of agents belonging to its own management range in response to a reference request from the integrated manager and notifying the integrated manager of the collected information. The hierarchical network management system according to claim 1. 6. The hierarchical network management system according to claim 5, wherein the real-time collection unit selects a real-time collection target with reference to the management object collected by the periodic collection unit. 6. The hierarchical type according to claim 5, wherein the real-time collection unit aggregates a plurality of pieces of information about each agent managed by a plurality of identifiers in response to a reference request from the integrated manager and notifies the integrated manager. Network management system. The periodic collection means stores the collected MIB information in a collected MIB database in units of individual information, collects collected MIB values into assembly management objects according to a reference request from the integrated manager, and notifies the integrated manager. The hierarchical network management system according to claim 1, wherein: The agent belonging to the self management range includes an agent in the sub-manager, and the real-time collection unit collects the state of the agent included in the sub-manager and notifies the integrated manager of the collected information. The hierarchical network management system according to claim 5. The sub-manager notifies the integration manager of addition or deletion of an IP node when a change occurs in the information constituting the collection MIB value of the addition or deletion of IP nodes in the management range. The hierarchical network management system according to claim 1.

Images