JP2002140240A - Hierarchical network management system - Google Patents

Abstract

(57) [Summary] [Problem] A sub-manager with a simple configuration and IAB
Hierarchical management of a large communication network based on the management standard SNMP. SOLUTION: SNMP is used as a communication protocol between an agent and a sub-manager and between a sub-manager and an integrated manager, and a management object of the same management range is periodically set in the sub-manager via an agent belonging to its own management range. Collected MIB information is created in the form of MIB from the collected results, the collected MIB information is stored in a collected MIB database, and the collected information is stored in a MIB in response to a reference request from the integration manager.
Notify the integration manager in B format.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

[0001] 1. Field of the Invention [0002] The present invention relates to a hierarchical network management system, and more particularly to a network management system in which agents, sub-managers, and integrated managers manage network resources hierarchically, and use SNM as a communication protocol between them.
P (Simple Network management)
nt protocol) using a hierarchical network management system.

[0002]

2. Description of the Related Art Generally, a communication network management system includes two types of subsystems, a manager and an agent. The manager manages and controls network resources for each agent. The agent manages and controls management objects such as configuration information and status information for each resource of the communication network. International standards for the management of communication networks include IAB (Internet Activit).
isBoard) management standard and OSI (Open Systems Interc)
There are two management standards, and a network using these management standards manages network resources in the following manner.

(1) Network management system using IAB management standard When a communication network becomes large-scale, the communication network is divided and a manager is assigned to each of the divided communication networks (hereinafter, referred to as sub-networks). , Deploy agents and manage network resources.

In this case, when resource management according to the IAB management standard is performed, SNMP (Simple Net) is used.
work management protocol)
Is used. The standard relating to the SNMP is RC 1157, a simple network management protocol (RFC 1157, "A Simple
Network Management Protocol ").

(2) Hierarchical network management system using both OSI management standard and IAB management standard “Integrated management of distributed LAN domain by OSI” (Miyauchi et al., IPSJ Transactions, 1993, June, pp. 1)
426 to 1440, hereinafter, each LAN (local area network) is managed by a sub-manager based on the IAB management standard, and the sub-manager and a higher-level integrated manager are described. During this time, network resources are managed based on OSI management standards.

That is, in the sub manager, the IAB
Manage network resources according to management standards
The data is converted into the SI management standard and transmitted to the integrated manager, and the integrated manager manages the resources of the entire network.

[0007]

When a large-scale network is managed, it is more effective to manage it in a hierarchical structure in order to reduce management packets and simplify the manager.

However, the SNMP of the IAB management standard
In the above-mentioned network management system using, hierarchy management is not considered, so even if a sub-manager is arranged between a manager and an agent, the structure of the management information transmitted between the manager and the sub-manager and its structure Unless the collection method is solved, there is a problem that hierarchical management cannot be realized. That is, there is a problem that a hierarchical network management system for managing and controlling a group of agents cannot be realized.

In this case, according to the SNMPv2 (SNMP version 2) standard, it is possible for a manager to notify an event to a manager. Even if you put a sub-manager in between,
Unless the structure of the management information transmitted between the manager and the sub-manager and the method of collecting the management information are solved, there is a problem that hierarchical management cannot be realized.

On the other hand, O described in Reference [1]
In the SI management system, the sub manager is OSI
An OSI standard communication service that implements the management standard;
Since both of the IAB standard communication services that realize the AB management standard must be implemented, there is a problem that the sub-manager becomes large.

[0011] In the LAN, a communication service of the IAB standard is used. In the operation of a communication network, it is a normal operation to use an IAB standard communication service between LANs. Therefore, in the management system described in the reference [1], the OSI management standard must be used in spite of using the IAB management standard on a WAN (Wide Area Network). This also has the problem that the configuration of the sub-manager becomes large.

Furthermore, when a communication network managed by a plurality of management standards is unified and hierarchically managed by an integrated manager, the management information is converted for that purpose and the management function for reducing the load on the integrated manager is delegated and distributed. However, the management system of the reference [1] does not consider the delegation and decentralization of the management function, so that the integration manager and the sub-manager become larger as the network becomes larger. However, there is a problem that the number of management packets used when exchanging management information increases.

A first object of the present invention is to provide a hierarchical network management system which is a sub-manager having a simple structure and capable of hierarchically managing a large-scale communication network based on SNMP of the IAB management standard. It is.

The second object is to transmit management information between the integrated manager and the sub-manager with a small number of management packets,
An object of the present invention is to provide a hierarchical network management system capable of managing a large-scale communication network with low traffic and low cost.

[0015]

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, And, in the sub-manager, management objects of the same management range are periodically collected via agents belonging to the management range of the sub-manager, collected MIB information in MIB format is created from the collected result, and the collected MIB information is collected. It is characterized by comprising a periodic collection unit that stores the collected information in the MIB database and notifies the integrated manager of the collected information in MIB format in response to a reference request from the integrated manager.

Further, in order to achieve the second object, in response to a reference request from the integration manager, a plurality of pieces of information from each agent managed by a plurality of identifiers are aggregated and notified to the integration manager. And

According to the above means, the periodic collection means periodically collects the managed objects of the same management range via the agents belonging to the own management range, and collects the collected information in response to a reference request from the integration manager. Notify.

In this case, the collected information is an MIB (Management) representing a set of a plurality of management objects in a tree structure.
The information is stored in a format of “ment Information Base”, is accessed in response to a reference request from the integration manager, and is notified to the integration manager.

Thus, the SNMP of the IAB management standard
A large-scale communication network can be hierarchically managed on the basis of a single protocol, and the configuration of the sub-manager can be simplified because it is a single protocol.

Also, a plurality of management objects from each agent managed by a plurality of identifiers are aggregated and notified to the integrated manager. Therefore, the management information between the integrated manager and the sub-manager can be transmitted with a small number of management packets, and the load on the integrated manager can be reduced.

[0021]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Hereinafter, the present invention will be described in detail with reference to an embodiment shown in the drawings.

FIG. 1 is a system configuration diagram showing an embodiment of a communication network to which the present invention is applied.
N1, 2 and 3 are WAN (Wide Area Network) 4
Are joined by

The LAN 1 has a plurality of agents 20a-1 and 20a for managing and controlling management objects such as configuration information and status information in units of network resources.
a-2 and IP without Agent (Intern
(Protocol) node 30a, and a sub-manager 10a for managing and controlling managed objects in the LAN 1 via these agents 20a-1 and 20a-2.

The LAN 2 has a plurality of agents 20b-1 and 20b- which manage and control management objects such as configuration information and status information for each network resource.
2 are connected, and these agents 20b-1,
A sub-manager 10b that manages and controls a managed object under the management of 20b-2 is connected. Further, the agent 20c and the IP node 3 on which the agent is not mounted
0c is connected, and a sub-manager 10c that manages and controls the managed objects managed by the agent 20c is connected.

That is, in the LAN 2, the management objects are managed by the two sub-managers 10b and 10c.

On the other hand, a plurality of agents 20-1 and 20-2 are connected to the LAN 3, and further manage and control the management objects under the management of the agents 20-1 and 20-2, as well as the WAN 4 and the sub-manager. An integrated manager 50 for managing and controlling these managed objects is connected through 10a, 10b and 10c. That is, the LAN 3 is connected to the integrated manager 50 that hierarchically manages resources of the entire network.

FIG. 2 is a diagram showing a logical relationship between an agent, a sub-manager, and an integrated manager.
Between the sub-manager 10a connected to N1 and the agents 20a-1 and 20a-2, the SN of the IAB management standard
MP and ICMP (Internet Control)
1 Message Protocol) to manage managed objects. Further, between the sub-manager 10a and the IP node 30a in which the agent is not mounted, the management object is managed using ICMP. The sub-manager 10a has a tree structure representing a set of a plurality of management objects collected through agents in the management range.
B (Management Information)
A collection MIB database 170a held in the form of “Base” is connected.

Similarly, between the sub-manager 10c and the agent 20c connected to the LAN 2, management objects are managed using SNMP and ICMP of the IAB management standard. Further, between the sub-manager 10c and the IP node 30c in which the agent is not mounted, the management object is managed using ICMP. Then, the sub-manager 10c
MIB (Mana) representing a set of a plurality of management objects collected through agents in a management range in a tree structure
collection M held in a format called “gement Information Base” (hereinafter referred to as MIB format)
The IB database 170c is connected.

The sub-manager 10b and the agents 20-1 and 20-2 are also connected to the integration manager 50 with the same logical relationship.

FIG. 3 is a functional block diagram showing an embodiment of the internal configuration of the sub-manager 10, which comprises the following functional modules.

(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) Centralization function 150 (7) ) Trap management function 160 Details of each function are as follows.

(1) Communication Control Function 100 In the IAB management standard, a protocol for network management is named SNMP (hereinafter simply referred to as SNMP). This standard is based on RFC 1157, the Simple Network Management Protocol (RFC 1157, "A Simple
Network Management Protocol ").

The communication control means 100 receives an SNMP request from the integrated manager 50 and the sub-manager 10 and receives an SNMP trap.

The SNMP requests are a request for acquiring a management object from the integrated manager 50 to the sub-manager 10 and a request for acquiring a management object from the sub-manager 10 to the agent 20.

The received SNMP request is notified to its own agent function 130 or sub-manager agent function 140 according to the management object identifier existing in the protocol, and the result is sent to the integrated manager 50 or the sub-manager 10 which is the SNMP request source. Respond to yourself. Further, the received SNMP trap is notified to the trap management function 160.

(2) Management range monitoring function 110 The IP address range specified as the management range of the sub-manager 10 is acquired by referring to the environment setting file 180 specified by the network manager of the sub-manager 10. An SNMP request and an ICMP echo request for acquiring a specific management object defined by MIB-II are periodically issued to a specified IP address group (regardless of whether or not an agent is installed), and as a result, And the SNMP response and the ICMP echo response.

In this case, the polling interval of the periodically issued SNMP request and ICMP echo request, and S
The community name described on the NMP protocol is obtained by referring to the environment setting file 180.

Information in the MIB format is created from the results obtained periodically, and the latest information in the MIB format is stored in the memory, passed to the collection database management function 120, and stored in the collection MIB database 170.

Further, the centralizing function 150 can refer to the IP address and status of the management range, and information on whether or not an agent is installed.

Further, the trap management function 160 can refer to each information of the IP address and the index number in the management range.

Further, when a change occurs in the information constituting the value of the collection MIB such as addition or deletion of an IP node in the management range, a sub-manager extension for notifying the integration manager 50 of the change. Issues a trap.

The MIB-II standard conforms to RFC 1213, Management Information Base for Network Management.
Of TIP
Based Internets: M.I.B.2 (RFC 1213, "Management Information Base for Netw
ork Management of TCP / IP Based internets: MIB-I
I ″).

(3) Collection Database Management Function 120 The collection database management function 120 stores the information in the collection MIB database 170 when each piece of information constituting the value of the collection MIB is input from the management range monitoring function 110.
MIB collected from sub manager agent function 140
When a value acquisition request is input, each piece of information constituting the value of the collection MIB is assembled into a management object format and responded.

(4) Own Agent Function 130 The own agent function 130 manages the host where the sub-manager 10 exists, and receives SNMP requests for the MIB-II and the agent extended MIB from the integrated manager 50 and the sub-manager 10 themselves. The input is made through the communication control function 100, and the result is input to the communication control function 1
Output to 00.

The environment setting file 180 refers to the community name (password for responding to the SNMP request).

(5) Sub-manager agent function 1
40 An SNMP request from the integrated manager 50 to the sub-manager extension MIB is input from the communication control function 100,
The acquisition destination is sorted by the management object identifier described in the protocol of the SNMP request.

That is, in the present invention, in order to provide the integrated manager 50 with the management information collected and aggregated by the sub-manager 10, a sub-manager extension MIB composed of a regular collection MIB and a real-time collection MIB is defined.

The periodic collection MIB is obtained by converting the management information periodically collected by the sub-manager 10 to the IP node group within the management range into MIB.

In the real-time collection MIB, the sub-manager 10 collects information on the management objects in the management range in real time according to a reference request from the integration manager 50,
Aggregate (delete and process unnecessary information) and integrate manager 5
In order to respond to "0", they are collected in MIB format.

Sub-manager agent function 140
Makes a MIB value acquisition request to the collection database management function 120 in the case of a reference request to the periodic collection MIB,
The result is acquired from the collection MIB database 170.

In the case of a reference request to the real-time collection MIB, an MIB value acquisition request is made to the centralizing function 150, and the result is obtained from the centralizing function 150.

Thereafter, the obtained result is transmitted to the communication control function 10.
Output to 0.

The environment setting file 180 refers to the community name (password for responding to the SNMP request).

(6) Aggregation Function 150 When a real-time collection MIB value acquisition request is input from the sub-manager agent function 140, the SNM is sent to the IP node group in which agents within the management range are mounted.
Issue a P request. Further, after obtaining the response, an aggregation process is performed, and the aggregated MIB value is returned to the sub-manager agent function 140.

From the environment setting file 180, the SNMP
Refers to the community name described in the protocol when issuing the request.

(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. In addition, a plurality of SNMPs notified within a certain time
The traps are combined into one sub-manager extended trap and relayed to the integration manager 50.

The environment setting file 180 refers to the time interval at which the sub-manager extended trap is issued, the community name described in the protocol, and the like.

The logical structure of the sub-manager extension MIB which is a main part of the present invention, the method of determining and monitoring the management range of the sub-manager,
An NMP request distribution method, a collection MIB management method, a collection MIB aggregation method, and an SNMP trap management method will be specifically described.

(1) Logical Structure of Sub-Manager Extension MIB In the IAB management standard, the logical structure of a managed object is generally defined in a virtual database called a management information base. This management information base is called MIB.

The syntax for describing the MIB and the method for identifying the instance of the management object are described in RFC 1155, Structure
And Identification of Management Information for TPC IP Based Internets (RFC
1155, "Structure and Identification of Manage
ment Information for TCP / IP-based internets "), and RFC 1212, Concise M.
IBM Definitions (RFC 1212, "Cons
ice MIB Definitions ").

Here, the standard agent 20 is M
Implements management objects specified in IB-II.

The sub-manager 10 has an SN for acquiring a specific MIB-II value from the IP node group within the management range.
An MP request and an ICMP echo request are issued, and the value of the sub-manager extension MIB is obtained from the collected result.

The sub-manager extension MIB includes a regular collection MIB and a real-time collection MIB.

The periodic collection MIB is obtained by converting the management information periodically collected by the sub-manager 10 to the IP node group within the management range into MIB. This data structure is composed of a table type management object identifier composed of a plurality of entries and a non-table type management object identifier.

The table type management object identifier is
An entry is provided 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 an agent, IP router identification flag, etc.), IP status, and ping (ICMP echo). Status information such as the response time of the request packet is held.

When a reference request is received from the integration manager 50, entries composed of a plurality of pieces of information are grouped into an information unit composed of an index part and a context part.
A method is taken to reduce the number of management object identifiers to be returned.

The non-table type management object identifier expresses information obtained by totalizing the contents of the configuration information and the status information of the table type management object identifier by the number of IP nodes.

The sub-manager 10 has the integrated management 5
Means for performing tallying is provided to provide tallying information to 0.

On the other hand, the sub-manager 10 collects and aggregates (deletes and processes unnecessary information) the status information of the management range in real time in accordance with a reference request from the integration manager 50 so that the The management information to be returned is a MIB.

The sub-manager 10 sends the SNMP request
The message is received from the integrated manager 50 and also from the sub-manager itself. This is because the management range of the sub-manager 10 can include the sub-manager itself. In particular, when a request for referencing the real-time collection MIB is received from the integration manager 50, an SNMP request is issued to the sub-manager itself, and the results are aggregated and returned to the integration manager 50. Therefore, the sub-manager 10 is configured to be able to process a plurality of SNMP requests in parallel.

FIGS. 4 to 6 show examples of definitions of the periodic collection MIB which is a sub-manager extension MIB.
FIGS. 7 to 9 show definition examples of B, and FIG. 10 shows definition examples of the sub-manager extended trap.

In the definition examples of the periodic collection MIB shown in FIGS. 4 to 6, (1) the number of IP nodes to be managed, (2) the number of nodes whose status with the sub-manager is critical, and (3) communication with the sub-manager But not working TC
(4) Number of nodes where all TCP / IP interfaces are operating, (5) Number of routers within the sub-manager's management range, (6) Sub-manager's management range SNMP within
(7) List of information on IP nodes in the management range of the sub-manager, (8) I of the management range
An example of a definition of an entry containing information for each P is shown.

In the example of the definition of the real-time collection MIB shown in FIGS. 7 to 9, (1) a list of TCP connections within the management range of the sub-manager, (2) an IP address for opening the TCP connection, and (3) smgSumTcpServerI
The port number used by the node defined by pAddress, (4) the IP address that opens the TCP connection (the address of the partner defined by smgSumTcpServerIpAddress), (5) smgSumTcpClientIpAddre
port number used by the IP node defined by ss, (6) TC opened by the IP node within the management range
A definition example of an entry of P connection information is shown.

In the definition example of the sub-manager extended trap shown in FIG. 10, (1) trap for notifying that a system has been added, (2) trap for notifying that a system has been added, and (3) trap for relay trap A definition example is shown.

FIG. 11 is a correspondence table 19 when the sub-manager 10 converts the MIB-II management object (hereinafter referred to as MIB-II object) name collected periodically and in real time into the management object name of the extended MIB.
If the MIB-II object is collected periodically and in real time from the agent 20 which has implemented the MIB-II management object as a standard, the MIB-II management object is converted into an extended MIB management object name according to the correspondence table 190.

FIG. 12 shows the contents 200 of smgIpNodeContext, which is a converted management object of the periodic collection MIB. As shown, the smgIpNodeContext has an IP address 210, a host name 220, a status 230, and a pin
g, a response time 240, SNMP support information 250, and router information 260.

When the management object configured as described above is periodically collected and displayed by the integration manager 50, a plurality of pieces of information on one agent or IP node can be displayed in one line. Alternatively, the state of the IP node can be easily confirmed.

FIG. 13 shows the contents 300 of smgSumTcpContext which is a management object of the real-time collection MIB. As shown, the smgSumTcpContext includes an IP address (part 1) 310, a port number (part 1) 320, a status (part 1) 330, and an IP address (part 2) 34
0, port number (part 2) 350, status (part 2) 360, and service name 370.

When the management object configured as described above is collected and displayed in real time by the integration manager 50, a plurality of pieces of information on one TCP connection can be displayed in one line.
It is possible to easily confirm the state of the connection.

Further, as shown in a correspondence table 400 of FIG. 14, a management object name (identifier) used for totalizing the values of the regular collection MIB is prepared in the regular collection MIB. The periodic collection MIB is totaled.

FIG. 29 shows an example in which the aggregated management objects are collected by the integration manager 50 at intervals of, for example, 10 minutes and displayed as a graph.

(2) Method for Determining and Monitoring Sub-Manager Management Range smgCreateSystemTrap in FIG. 10 defines a sub-manager extended trap issued when an IP node is added to the sub-manager management range. The extended trap number is "1" and the variable list (Variable-binding
In s), the corresponding index number 520a of the management range table 500 shown in FIG. 16 is specified.

The smgDeleteSystemTrap in FIG. 10 defines a sub-manager extended trap issued when an IP node is deleted from the sub-manager management range. The extended trap number is "2" and the variable list (Va
For riable-bindings, the corresponding index number 520a of the management range table 500 is specified.

FIG. 15 shows an environment setting file 18 used for determining the management range and the monitoring range of the sub-manager.
FIG. 9 is a diagram showing a format of 0, and a community name for acquisition 40
0, setting community name 410, trap destination 42
0, the number of management ranges 430, the management address range 440, and the trap relay interval 450 are stored in the respective areas.

Among them, 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.

The setting community name 410 is SNMP
Is a name for performing authentication when a setting request is received.

The trap destination 420 is the sub manager 1
0 is the IP of the other party that issues the sub-manager extended trap
This is an address, and a plurality of addresses such as trap destinations 420a and 420b can be designated.

The number of management ranges 430 is
Is the information for specifying the maximum number of IP nodes included in the management range.

The management address range 440 includes the IP address of the IP node, the community name,
This is information for specifying a polling interval and a timeout time, and a plurality of sets can be specified as shown in 440a and 440b. Then, a range of IP addresses can be specified in each group. For example, in the management address range 440a, 2
I from 0.10.20.1 to 200.10.20.70
This indicates that the P address is specified.

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.

The initial value (default value) of the polling interval at the time of periodically collecting the management objects of the agent is set to, for example, 5 minutes. The initial value of the timeout time is set to, for example, one second. Further, the initial value of the trap relay interval 450 is set to, for example, 10 minutes.

FIG. 16 is a diagram showing the format of a management range table 500 provided inside the management range monitoring function 110, which is composed of a control unit and a plurality of entries. This is the same number as the value specified by Expression 430.

The control unit comprises an area for storing an acquisition community name 510a and the like. The contents taken into the control unit from the environment setting file 180 will be described as follows.

The acquisition community name 400a is set as the acquisition community name 510a, and the acquisition community name 510a is set as the acquisition community name 510a.
In b, the setting community name 410 and the management range number 51
In 0c, the management range number 430 and the trap destination number 510d
The number of destinations specified by the trap destination 420 and the IP address of the destination are set in the trap destination table address 510e. For other contents, see FIG.
24 to FIG.

FIG. 17 shows an outline of the main processing of the management range monitoring function 110. First, the management range is initialized (step 600), and the process loops until an end request is received (step 610). During this time, monitoring of the management range (step 620), totaling process (step 63)
0) and update of the management range (step 640).

FIG. 18 shows an outline of the 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).

IP of entry in management range table 500
The following processing is performed to set only the existing IP address among the IP addresses specified in the management address range 440 as the address 520b. First, in order to obtain an IP address recognized by the sub-manager 10, atNetAddress, which is an address conversion group of MIB-II, is obtained from the own agent function 130 (step 6).
52) (Step 652).

The obtained value of atNetAddress indicates the correspondence between the IP address and the physical address. An empty entry 520 exists in the management range table 500 and atNe
The process loops while the tAddress IP address exists (step 653).

It is determined whether the IP address of atNetAddress is included in the management address range 440 of FIG. 15 (step 6).
54), ping is issued only for the included IP address (step 655).

Then, it is determined whether or not there is a ping response (step 656), and the IP address having the response is set to the IP address 520b of the empty entry 520 of the management range table 500. In addition, a sub-manager extended trap for notifying the integrated manager 50 that the IP node has been added to the management range is issued (step 658).

Next, a community name, a polling interval, and a timeout time related to the IP address are obtained from the management address range 440 of the environment setting file 180, and a community name 520c, a polling interval 520d, and a timeout time 520e are set. (Step 659).

Next, referring to the / etc / hosts file (included in the information for each IP node in FIG. 6), the host name 520f of the IP address 520b is set (step 66).
0). Thereafter, "Normal" is set in the status 520g (step 661).

FIG. 19 shows the monitoring of the management range (step 62).
0) is shown.

Referring to the management range table 500 (step 670), the process loops by the number of entries 520 in which the IP address 520b is set.

During this time, a ping process is performed (step 6).
72). The IP address 520b is set in the entry 520, and the status 520g is "Critica
l "is determined (step 673), and the MIB-II (sysObjectID, ifNu
mber, ifType, ifOperStatus, ipForwarding) (Figure 1
1) is issued (step 674).

Next, it is determined whether there is a response to the SNMP request (step 675). If there is a response, "snmp" is added to the SNMP support information 520j of the entry 520.
Is set (step 676), and a router determination is made (step 677).

If there is no response, the entry 52
"Nonsnmp" is set in the SNMP support information 520j of 0 (step 678), and the router support information 520k is set.
Is set to "host" (step 679).

FIG. 20 shows a router judgment (step 677).
This is an outline of the above. "Host" is set in the router support information 520k as an initial setting (step 69)
0). The value of the MIB-II ipForwarding (see FIG. 11) is determined (step 691). If it is "1" (gateway), the flow proceeds to step 692; if it is other than "1" (host), the flow proceeds to step 698.

MIB-II if indicating the number of interfaces
The value of Number is determined (step 692). If it is "2" or more, the process proceeds to step 693, and if it is "1", "Normal" is set in the status 520g (step 69).
7).

MIB-II indicating interface type
It is determined whether there are a plurality of interfaces whose ifType value is other than "24" (softwareLoopback), and all the MIB-II ifOperStatus values indicating the status are "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.
Is set (step 695).

If the condition is not satisfied, the status 52
"Marginal" is set to 0 g (step 696).

If the value of ipForwarding of MIB-II is other than "1" (host) (step 691), the value of ifNumber of MIB-II indicating the number of interfaces is determined (step 698) and "2" or more. If it is, the process proceeds to step 699. If it is "1", "Normal" is set in the status 520g (step 702).

In step 699, the same determination as in step 693 is performed.
Is set to "Normal" (step 700). If the condition is not satisfied, "Marginal" is set to the status 520g (step 701).

FIG. 21 shows a ping process (step 67).
This is an outline of 2).

First, the ping response time 520h of the entry 520 is cleared (step 710), and the ping is issued to the specified IP address (step 71).
1), the presence or absence of the response is confirmed (step 712).
If there is a ping response (step 712), the ping response time 520h of the entry 520 is set (step 713), the oldest time 520i in which there is no ping response is cleared (step 714), and SNMP is sent.
The support information 520j is determined (step 715).

When the SNMP support information 520j is "nons
If "nmp", "Normal" is set in the status 520g (step 716). If "snmp", status 5 is set.
"Marginal" is set to 20 g (step 717).

If there is no ping response (step 712), the status 520g of the entry 520 is set.
Is set to "Critical" (step 718), and ping is set.
The oldest time 520i at which no response has been received is confirmed (step 719).

The oldest time 520i exists (step 7).
19) If a certain period of time (for example, one week) has elapsed (step 720), the contents 5
20a to 520k are deleted (step 721), and a sub-manager extended trap for notifying the integrated manager 50 that the IP node has been deleted from the management range is issued (step 722).

If the oldest time 520i does not exist (step 719), the current time is set (step 72).
3) Yes.

FIG. 22 shows an outline of the tallying process (step 630).

First, a part 510f-51 of the control unit of the management range table 500 for counting the number of IP addresses.
0k is cleared, and looping is performed for the number of entries 520 (step 732). Then, the entry 520 contains I
Only when the P address is set, the counter is incremented (+1) under the following conditions.

That is, smgTotalManagedNodeNumber is unconditionally set (step 734), and smgTotalCriticalNodeNu
mber is only when the status 520g is "Critical" (step 736), and smgTotalMarginalNodeNumber is when the status 520g is "Marginal" (step 73).
7) Only, smgTotalNormalNodeNumber has status 52
Only when 0g is "Normal" (step 738), smgT
otalRouterNodeNumber is router support information 520k
SmgTotal only when is "router" (step 740)
SnmpSupportNodeNumber is SNMP support information 520
Only when j is "snmp" (step 742), each is incremented.

If there is a difference between the results before and after the aggregation (step 743), the collection database management function 12
The difference information is stored in 0 (step 744).

FIG. 23 shows the updating of the management range (step 64).
0) is shown.

First, the operation is performed after confirming that a predetermined time, for example, 3 hours, has elapsed from the previous update time (step 7).
50).

Empty entry 5 in management range table 500
20 exists, the status 520g is other than "Critical", and the loop is performed only for the IP address whose SNMP support information 520j is "snmp" (step 75).
1).

Next, the IP address 520 of the entry
b), an SNMP request is issued to obtain the atNetAddress of the MIB-II (step 752).

If there is a response to the SNMP request (step 752), the process loops while the empty entry 520 exists and the number of acquired IP addresses (step 752).
4) Perform an update process (step 755).

If there is no response to the SNMP request (step 752), the status 520g is updated.
"Critical" is set (step 756).

FIG. 24 shows an outline of the updating process (step 755).

First, it is determined whether or not 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). Perform processing.

That is, the IP address is stored in the empty entry 520.
The address is set (step 761), and a sub-manager extended trap for notifying the integrated manager 50 that the IP node has been added to the management range is issued (step 762).

By performing the above processing, the sub-manager 10 can not only limit the number of IP nodes included in the management range but also monitor only existing IP nodes.

(3) SNMP received by sub manager
Request Distributing Method The communication control function 100 receives an SNMP request from the centralizing function 150 of the integrated manager 50 and the sub-manager 10, and receives an SNMP trap from the agent 20.

Sub manager agent function 140
Distributes the SNMP request input from the communication control function 100 by the management object identifier, and relays the SNMP request to the collection MIB database management function 120 or the aggregation function 150.

The main reason for providing two agent functions, the own agent function 130 and the sub-manager agent function 140, is that the S
This is because it is necessary to process the NMP request and the SNMP request from the aggregation function 150 in parallel. That is, SNM
By processing P requests in parallel, the integration manager 5
When an SNMP request is received from 0 to the real-time collection MIB of the sub-manager 10, the aggregation function 150 issues an SNMP request to the own agent function 130 via the communication control function 100 as an extension of the SNMP request. , A real-time collection MIB value can be created based on the above, and an SNMP response can be returned to the integration manager 50.

FIG. 25 shows an outline of a method of distributing the communication control function 100 by the management object. The communication control function 100 loops until a termination request is received (step 770). The received data includes an SNMP request from the centralizing function 150 of the integrated manager 50 and the sub-manager 10, and an SN request from the own agent 130 and the sub-manager agent function 140.
Since there are an MP response and an SNMP trap from the agent, it is determined which of them is present (step 7).
71).

First, when an SNMP request is received, S
It is determined whether or not the sub-manager extension MIB is used to perform distribution by the management object identifier in the protocol of the NMP request (step 772). Sub-manager agent function 1 for sub-manager extension MIB
40 is notified (step 773). However, when the sub-manager extension MIB is not used, the own agent function 13
0 is notified (step 774).

On the other hand, when an SNMP response is received, a response is returned to the integration manager 50 (step 775).

If an SNMP trap is received, the trap management function 160 is notified (step 77).
6).

FIG. 26 shows an outline of a method of distributing the sub-manager agent function 140 according to the management object.

First, sub-manager agent function 1
40 loops until an end request is received (step 780).

The received data includes the communication control function 100
Request from SNMP, collection database management function 120
Since there is a result response of the MIB value from the aggregation function 150, it is determined which one of them is received (step 781).

When the SNMP request is received, it is determined whether the request is an MIB acquisition request and the community names match (step 782). The confirmation of the community name is performed by comparing the community name in the protocol of the SNMP request with the community name for acquisition 400 shown in FIG.

If the judgment condition of step 782 is satisfied, the operation is judged (step 78).
3).

If the operation is get-next, the specified next managed object identifier is obtained and set as the requested managed object identifier (step 78).
4). Next, regular collection MIB or real-time collection MIB
Is determined (step 785). In the case of the regular collection MIB, the collection database management function 120 is notified (step 786). In the case of the real time collection MIB, the collection function is notified (step 787).

If the condition of step 782 is not satisfied, an error response is returned to the communication control function 100 (step 788).

On the other hand, if the result response is received,
Assembling the P response (step 789), the communication control function 10
Responds to 0 (step 790).

(4) Management Method of Collection MIB in Collection Database Management Function 120 Here, in particular, management objects are divided and managed, and
A method of assembling the management object when responding to the B value will be described.

The collection database management function 120 inputs the individual information constituting the periodic collection MIB from the management range monitoring function 110, stores the information in the memory, and collects the collected MIB.
It is stored in the database 170.

As shown in FIG. 27, the individual information includes smgIpNodeIndex 810, IP address 210, host name 220, status 230, ping response time 240, SNMP
There are support information 250 and router information 260.

That is, the collection database management function 12
0 performs individual management not on a managed object basis which is a periodic collection MIB but on an individual information unit constituting the managed object. The collection database management function 120 inputs the smgIpNodeIndex 810 which is key information for specifying an IP node from the management range monitoring function 110 and, for example, only the status 230 in which the change has occurred. It is configured to reduce the amount of data exchanged between them.

When an arbitrary IP node is deleted from the management range of the sub-manager 10, the management range monitoring function 11
A deletion request of smgIpNodeIndex 810 is input from 0, and the collection database management function 120 sets the flag 800 to “Yes”.
By changing from “none” to “none”, the management of the IP nodes within the management range is performed.

When a request for referring to 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 because the smgIpNod shown in FIG.
This is performed to make the correspondence between the eIndex 810 and the IP address 210 the same as the correspondence before the restart.

The collection database management function 120 stores individual information constituting the periodic collection MIB in the collection MIB database 170 in order to maintain the correspondence.

The collection database management function 120 allows the sub-manager 10 to periodically collect MI
When receiving the request to acquire B, the communication control function 100,
Via the sub-manager agent function 140, a request to acquire a periodically collected MIB value is received.

The collection database management function 120 assembles the periodic collection MIB value from the 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. .

Here, assembling of the periodically collected MIB value is as follows.
As shown in FIG. 27, one agent or IP address 210 indicating the IP node characteristics and IP status, host name 220, status 230, ping response time 240, SNMP support information 250, router information 26
SmgIpNod which is one management object
That is to put it in eContext200.

FIG. 28 shows the collection database management function 12.
0 shows an outline of the operation.

The collection database management function 120 loops until an end request is received (step 820).

The data to be received (step 821) includes
Since there is a request for acquisition of the periodically collected MIB from the sub-manager agent function 140 and a storage request and a reference request from the management range monitoring function 110, it is determined which one is (step 821).

When an acquisition request is received, get-nex
The t operation is determined (step 822), and g is determined.
If it is an et-next operation, the next index specified (smgIpNodeIndex 810) is obtained (step 823).

In the next step 824, the presence or absence of an index is determined using the flag 800 in FIG. This is mainly for confirming the index specified by the get operation.

If an index exists, step 8
At 25, a periodic collection MIB value that responds is created. That is, when the smgIpNodeContext 200 is requested, the assembling is performed, and when the management object expressing the aggregation result as the periodic collection MIB shown in FIG. 14 is requested, it is excluded from the assembling target.

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).

When the storage request is received, smgIpNodeIndex 810 which is the key information constituting the periodic collection MIB from the management range monitoring function 110 and smgIpNodeContext to be updated
After searching for the corresponding IP node based on the key information, smgIpN stored in the memory is entered.
Update the content 200 of the odeContext (step 82)
8).

When an arbitrary IP node is added or deleted from the management range of the sub-manager 10, the flag 800 in FIG. 27 is updated (changed) to “Yes” or “No”.

Then, the collection MIB database 170 is updated (step 829).

Since the division management cannot be performed on the management object representing the total result as the collection MIB shown in FIG. 14, the MIB value is simply updated.

When the reference request is received, the management range monitoring function 110 is provided with the requested individual information of the smgIpNodeIndex 810 and the contents 200 of the smgIpNodeContext which are the key information constituting the periodic collection MIB (step 830). ). For the management object expressing the aggregation result, which is the regular collection MIB shown in FIG. 14, the MIB value is simply provided because the division management is not performed.

(5) Collection / Aggregation Method in Aggregation Function 150 The aggregation function 150 is, for example, a TCP as shown in FIG.
If there is a connection, the TCP connection 1000 between the IP nodes within the management range and the IP connection within the management range
The TCP connection 1010 between the node and the IP node outside the management range is set as an aggregation target. 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 within the management range, and the TCP connection in which the IP node has the agent 20 is set as an aggregation target.

FIG. 31 shows the format of MIB-II tcpConnState index and MIB value collected by the centralizing function 150 from agents within the management range.

FIG. 32 shows a real-time collection MIB of the sub-manager 10.
Index and MI of smgSumTcpContext whose value is required
It shows the format of the B value.

FIG. 33 shows the conversion between FIG. 31 and FIG. Sm requested from integrated manager 50
gSumTcpContext index IP address (part 1) 310, port number (part 1) 320, IP address (part 1) 330, port number (part 2) 340,
Each is obtained from the IP address (part 1) 310 and tc
It is used as the local IP address 1120, local TCP port 1130, remote IP address 1140, and remote TCP port 1150 of the index of pConnState 1100.

Also, the value 1160 of tcpConnState is smgS
umTcpContext status (part 1) is set to 330.

Similarly, the remote IP address 1120, remote TCP port 1130, and local IP address 11 of the index of tcpConnState 1110
40, used as local TCP port 1150. The value 1170 of tcpConnState is smgSumTcpCon
The status of the text (part 2) is set to 360.

The service name 370 of the smgSumTcpContext is
By referring to the / etc / services file, a service name corresponding to the port number (part 1) 320 or the port number (part 2) 350 is acquired and set.

FIG. 34 explains the order of the indexes shown in FIG. 32, and has a relationship with the order of the entries 520 of the management range table 500.

In the IP address (part 1) 310, the IP addresses 520b are arranged in order from the head of the entry. Port numbers (part 1) 320 and port numbers (part 2) 350 are arranged in ascending order of port number. Further, the IP address (part 2) 340 includes the IP address
The entries are arranged in order from the IP address 520b of the entry next to the address (part 1) 310, and the last is an IP address outside the management range.

FIG. 35 shows an outline of the main processing of the centralizing function 150, and loops until an end request is received (step 1200).

The operation starts when an acquisition request for an aggregate MIB is received from the sub-manager agent function 140 (step 1201). First, the operation is determined (step 1202). If the operation is a get operation, a get process (step 1203) is performed. , Otherwise g
An et-next process is performed (step 1204).

Next, an error determination is made (step 120).
5) If there is no error, obtain the service name (step 1206) and respond with smgSumTcpContext
Are assembled (step 1207). Further, a result response is returned to the sub-manager agent function 140 (step 1208).

When there is an error, an error response is returned to the sub-manager agent function 140 (step 12).
09).

FIG. 36 shows a get process (step 120).
This shows an outline of 3). First, the index shown in FIG. 33 is decomposed (step 1250), and it is determined whether the IP address is included in the management range (step 1)
252), the management range table 500 is referred to (step 1251).

When only the IP address (Part 1) is included in the management range, only the IP address (Part 1) has g
ET is issued (steps 1253, 1254).

Similarly, if only the IP address (No. 2) is included in the management range, a get is issued only to the IP address (No. 2) (steps 1255 and 12).
56).

However, when both IP addresses are included in the management range, first, get is issued to the IP address (No. 1) (steps 1257 and 1258), and
A get is issued to the IP address (No. 2) only when there is no error (steps 1259, 126)
0,1261).

If both IP addresses are not included in the management range, an error is returned (step 1262).

FIG. 37 shows an outline of the get issue executed in FIG.

In order to efficiently obtain the value of MIB-II, the management range table 500 is referred to and the status 520g of the IP address is set to "Marginal" or "Normal".
And the SNMP support information 520j is "snmp"
Is determined (step 1270).

When the condition is satisfied, the management object identifier shown in FIG. 33 is converted (step 127).
1), issue a get request (step 1272).

Next, it is determined whether or not there is a response to the get request and an error is determined (steps 1273 and 1274). If the condition is satisfied, an acquisition result is returned (step 12).
75).

If the conditions of steps 1270, 1273 and 1274 are not satisfied, an error is returned (steps 1278, 1277, 1276).

FIG. 38 shows an outline of the get-next processing (step 1204).

First, it is determined whether or not an index has been designated (step 1280).
Decompose the index in the same way as 0 (step 128
1).

When no index is specified,
The next index is calculated to obtain the first index (step 1282).

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).

In this determination, if only the IP address (1) is included in the management range, get-next is issued only to the IP address (1) (step 1).
285, 1286).

Similarly, if only the IP address (No. 2) is included in the management range, get-next is issued only to the IP address (No. 2) (step 12).
87, 1288).

When both IP addresses are included in the management range, first, get-
Next issuance is executed (steps 1289 and 129).
0), and issue get-next to the destination address of the connection only when there is no error (steps 1291, 1292, 1293).

If both IP addresses are not included in the management range, an error is returned (step 1294).

FIG. 39 shows an outline of calculation of the next index.

First, the presence / absence of the designated index is determined (step 1300). If the index does not exist, the management range table 500 is used to determine the leading index.
Are searched in order from the first entry, and the status is 520g.
Is “Marginal” or “Normal”, and the SNMP address 520b whose SNMP support information is “snmp”
A new IP address (part 1) 310 is set (step 1301).

The port number (No. 1) 330 contains "
0 "for the IP address (No. 2) 340.
0.0 ”for the port number (No. 2) 350
Are set respectively.

However, if there is an index in step 1300, the management range table 500 is searched in order to efficiently find the next index.
According to the order of the index shown in FIG. 34, the IP address (part 1) is the IP address 520b after 310, and the status 520g is "Marginal" or "Norm".
The IP address 520b which is "al" and whose SNMP support information is "snmp" is set as a new IP address (part 1) 310 (step 1305).

FIG. 40 shows get-ne executed in FIG.
This is an outline of xt issuance.

First, in order to efficiently obtain the value of MIB-II, the management range table 500 is referred to and the status 520g of the IP address is set to "Marginal" or "Norm".
al "and the SNMP support information 520j is" sn
mp "is determined (step 1310).

When the condition is satisfied, the management object identifier shown in FIG. 33 is converted (step 131).
1), issue a get-next request (step 13)
12).

Next, the management object identifier of the obtained result is determined (step 1313), and if it is tcpConnState, it is determined whether the connection is a TCP connection between IP nodes (step 1314).

If the connection is a TCP connection between IP nodes, an acquisition result is returned (step 1315). If the connection is not a TCP connection between IP nodes, get-nex is obtained.
The t issuance is executed again (step 1316).

If it is not tcpConnState in step 1313, execution of the next index calculation and determination of presence / absence of the next index are performed (steps 1317 and 131).
8) If it exists, issue the get-next issue (step 1319), otherwise return an error (step 1320).

If the condition of step 1310 is not satisfied, the same processing as in steps 1317 to 1320 is performed.

(6) S in the trap management function 160
NMP Trap Reduction Method 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”. is there.

The community name for acquisition 400 in the environment setting file 180 described with reference to FIG. 15 is also used when the sub-manager 10 issues a sub-manager extended trap. Trap destination 420 is sub-manager 1
0 is the IP of the other party that issues the sub-manager extended trap
This is an address, and can be specified multiple times Trap relay interval 4
Reference numeral 50 denotes a time for storing the SNMP traps received from the agent 20 which is the management range of the sub-manager. If the SNMP traps are received during this time, they are collected into one sub-manager extended trap and relayed to the integrated manager 50.

FIG. 41 shows an outline of the conversion of the SNMP trap received by the sub-manager 10 from the agent 20 in the management range into the sub-manager extended trap.

SmgInt, a sub-manager extended trap
The format 1400 of ermediaryTrap is the trap header 14
10 and Variable-bindings 1420.

The trap header 1410 is for enterprise 14
11, agent-addr1412, generic-trap1413, sp
It consists of an ecific-trap 1414 and a time-stamp 1415, and describes the sysObjectID of the sub-manager 10, the IP addresses “6” and “3” of the sub-manager 10, and the sysUpTime of the sub-manager 10, respectively.

In the Variable-bindings 1420, the contents of the received SNMP trap are described in order.

FIG. 42 shows details of the conversion from the SNMP trap to the sub-manager extended trap.

Var of smgIntermediaryTrap format 1400
iable-bindings1420 mainly consists of smgIpNodeIndex14
30, smgEnterprise1431, smgAgentAddr143
2. smgGenericTrap1433, smgSpecificTrap143
4. VarBindList 1435.

In the smgIpNodeIndex 1430, agent-addr 146, which is the IP address that issued the SNMP trap, is set.
The index number 520a of the management range table 500 corresponding to No. 2 is described.

SmgEnterprise1431, smgAgentAddr1
432, smgGenericTrap1433, smgSpecificTrap1
Reference numerals 434 and 434 denote SNMP trap enterprises 1461 and ag received from the agents 20 in the management range, respectively.
ent-addr 1462, generic-trap 1463, specific-t
rap1464 is described.

The VarBindList 1435 contains the received SN
Describe the Variable-bindings 1470 of the MP trap.

FIG. 43 shows an outline of an SNMP trap reduction method.

First, the environment setting file 180 is referred to (step 1500), and a loop is performed (step 1501) until an end request is received.

Next, a buffer is secured (step 1).
502), a loop is performed only during the trap relay interval 450 (see FIG. 15) (step 1503), and an SNMP trap is received (step 1504).

In order to confirm whether the received SNMP trap is from the agent 20 in the sub-manager management range, the IP address 52 from the management range table 500 is checked.
0b and index 520a (step 15).
05).

If the received SNMP trap is issued by the agent 20 in the sub-manager management range, the index 520a and the received SNMP
Store the P trap (steps 1506, 150
7).

A sub-manager extended trap is assembled from the contents of this buffer (step 1508), and a sub-manager extended trap is issued to the integrated manager 50 (step 1509). Thereafter, the buffer is released (step 1510).

The details of the sub-manager 10 which is a main part of the present invention have been described above. According to this embodiment, the extended MIB of the sub-manager 10
The following effects can be obtained by referring to the periodic collection MIB and the real-time collection MIB that are:

(1) When referencing the periodic collection MIB The sub-manager 10 periodically issues a ping (ICMP echo request packet) and an SNMP request packet to the IP nodes in the sub-manager management range, and By retaining the periodic collection MIB, which is one of the manager extension MIBs, the integrated manager 5
It is possible to immediately respond to the SNMP acquisition request from 0.

[0230] The periodic collection MIB includes the characteristics (index, IP address,
A managed object in which a host name, an IP status, a ping response time, an SNMP implementation flag, and an IP router implementation flag) are represented by 1 [managed object identifier / IP node] and their individual characteristics are totaled by the number of IP nodes. Since the network manager is composed of the identifier, the network manager of the integrated manager 50 can confirm the configuration information and the status information of the sub-manager management range by referring to the periodic collection MIB of the sub-manager 10 according to the application.

Further, the number of management packets between the integrated manager 50 and the sub-manager 10 can be reduced by the number of the periodically collected MIBs.

(2) When referencing the real-time collection MIB In accordance with a request from the integration manager 50 to the sub-manager 10 for reference to the real-time collection MIB, the management objects of each agent are collected / aggregated in real time and returned to the integration manager 50. Resources (CP
The latest state of the sub-manager management range can be grasped with U power, memory capacity) and a small number of management packets. Further, a time error between agents can be reduced.

Also, by managing the TCP connection information in the sub-manager management range as a real-time collection MIB, the integrated manager 50 can be operated with a small number of operations.
High traffic I in the management range of the sub-manager 10
P nodes and services can be specified. Further, 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.

Further, 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 efficiently transmitted to the integrated manager 50.

Note that, in the logical relationship diagram of FIG. 2, the hierarchy from the agent to the integration manager is three layers, but the present invention is not limited to this.

[0238]

As described above, according to the present invention, SN is used as a communication protocol between an agent and a sub-manager and between a sub-manager and an integrated manager.
Using the MP, and within the sub-manager, the management objects of the same management range are periodically collected via agents belonging to the own management range, and the MIs are collected from the collected results.
Since the collected MIB information in the B format is created, the collected MIB information is stored in the collected MIB database, and the collected information is notified to the integrated manager in the MIB format in response to a reference request from the integrated manager. It is a sub-manager having a simple configuration and can hierarchically manage a large-scale communication network based on the SNMP of the IAB management standard.

Also, in response to a reference request from the integration manager, a plurality of information from each agent managed by a plurality of identifiers are aggregated and notified to the integration manager. Management information can be transmitted between sub-managers, and large-scale communication networks can be managed with low traffic and low cost. Further, the load on the integrated manager can be reduced.

Also, the network manager on the integrated manager side periodically collects the sub-manager
By referring to B, the configuration information and status information of the sub-manager management range can be confirmed.

Further, when management objects are collected in real time and notified to the integration manager,
The latest state of the sub-manager management range can be grasped with a small amount of resources (CPU power, memory capacity) and a small number of management packets.

Also, by managing the TCP connection information in the sub-manager management range as a real-time collection MIB, it is possible to specify the high-traffic IP nodes and services in the management range of the sub-manager 10 with a small number of operations by the integrated manager. The effect is obtained.

[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, a sub-manager, and an agent are arranged.

FIG. 2 is a logical relationship diagram showing a logical relationship among an integration manager, a sub-manager, and an agent in FIG. 1;

FIG. 3 is a functional configuration diagram showing a detailed configuration of a sub-manager which is a main part of the present invention.

FIG. 4 is a periodic collection MI that is a sub-manager extension MIB.
FIG. 9 is an explanatory diagram showing a definition example (No. 1) of B.

FIG. 5 is a periodic collection MI which is a sub-manager extension MIB.
FIG. 9 is an explanatory diagram showing a definition example (No. 2) of B.

FIG. 6 is a periodic collection MI which is a sub-manager extension MIB.
FIG. 9 is an explanatory diagram showing a definition example (No. 3) of B.

FIG. 7 is an explanatory diagram showing a definition example (1) of a real-time collection MIB which is a sub-manager extension MIB.

FIG. 8 is an explanatory diagram showing a definition example (part 2) of a real-time collection MIB that is a sub-manager extension MIB.

FIG. 9 is an explanatory diagram showing a definition example (part 3) of a real-time collection MIB that is a sub-manager extension MIB.

FIG. 10 is an explanatory diagram showing a definition example of a sub-manager extended trap.

FIG. 11 is a diagram showing a correspondence table of management objects to be converted from MIB-II to sub-manager extension MIB.

FIG. 12: smgIpNodeC which is a sub-manager extension MIB
FIG. 9 is an explanatory diagram showing contents of ontext.

FIG. 13: smgSumTcpC which is a sub-manager extension MIB
FIG. 9 is an explanatory diagram showing contents of ontext.

FIG. 14 is a diagram showing a correspondence table of a periodically collected MIB to be totaled.

FIG. 15 is an explanatory diagram illustrating an example of an environment setting file.

FIG. 16 is an explanatory diagram showing an example of the contents of a management range table.

FIG. 17 is a schematic PAD of a monitoring method (main) of a management range.
FIG.

FIG. 18 is a schematic PAD diagram of initial setting of a management range.

FIG. 19 is a schematic PAD diagram of monitoring of a management range.

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 a tabulation process.

FIG. 23 is a schematic PAD diagram of updating a management range.

FIG. 24 is a schematic PAD diagram of an update process.

FIG. 25 is a schematic diagram P of a distribution method in the communication control function;
It is an AD diagram.

FIG. 26 is a schematic PAD diagram of a distribution method in a sub-manager agent function.

FIG. 27 is an explanatory diagram showing an example of the contents of a periodic collection 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 of a total value, which is a periodic collection MIB, in the integrated manager.

FIG. 30 is an explanatory diagram showing an example of a TCP connection targeted by the aggregation function.

FIG. 31 is an explanatory diagram showing a format of an index and a value of tcpConnState of MIB-II.

FIG. 32: smgSumTcpContext of the real-time collection MIB
FIG. 4 is an explanatory diagram showing the format of an index and a value of the “.

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 the real-time collection MIB.

FIG. 35 is a schematic diagram PA of a method of consolidating management ranges (main);
FIG.

FIG. 36 is a schematic PAD diagram of a method of integrating management ranges (get processing).

FIG. 37 is a schematic PAD diagram of a method of consolidating management ranges (get issuance).

FIG. 38 is a schematic PAD diagram of a management range consolidation method (get-next processing).

FIG. 39 is a schematic PAD diagram of a method of consolidating management ranges (calculation of next index).

FIG. 40 is a schematic PAD diagram of a method of consolidating management ranges (get-next issuance).

FIG. 41 is a conversion diagram from an SNMP trap to a sub-manager extended 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 an SNMP trap reduction method.

[Explanation of symbols]

10, 10a, 10b, 10c ... sub-manager, 2
0, 20a-1, 20a-2, 20b-1, 20b-
2, 20c: agent, 30a, 30c: IP node without agent, 50: integrated manager, 10
0: communication control function, 110: management range monitoring function, 120
… Collection database management function, 130… own agent function, 140… sub manager agent function, 15
0: Centralizing function, 160: Trap management function, 170:
Collection MIB database, 180 ... environment setting file,
500: management range table.

 ──────────────────────────────────────────────────続 き Continued on the front page (72) Inventor Takashi Kagei 1099 Ozenji Temple, Hitachi, Ltd.System Development Laboratory, Aso-ku, Kawasaki City, Kanagawa Prefecture (72) Inventor Yasuhiro Tanaka 1099 Address Ozenji Temple, Aso-ku, Kawasaki City, Kanagawa Prefecture (72) Inventor Shinichi Nakazaki 5030 Totsuka-cho, Totsuka-ku, Yokohama-shi, Kanagawa Prefecture, Ltd.Software Development Division, Hitachi, Ltd. (72) Yoshinori Oba 5030 Totsukacho, Totsuka-ku, Yokohama-shi, Kanagawa Address F-term (reference) in Software Development Division, Hitachi, Ltd. 5B089 GA04 GB01 HB06 5K030 GA04 GA11 HA08 HB08 JA10 MA01

Claims (8)

[Claims] 1. A plurality of agents for managing and controlling management objects such as configuration information and state information in resource units of a communication network, and management of a communication network through agents of the group in predetermined agent group units A sub-manager that manages and controls a part of the object, and an integrated manager that manages and controls the managed objects of the entire communication network via the sub-manager, wherein the agent and the sub-manager, and the sub-manager and the integration What is claimed is: 1. A hierarchical network management system using SNMP as a communication protocol between managers, wherein said sub-manager periodically collects management objects of the same management range via agents belonging to its own management range, and collects the management objects. From the result of the MIB format The collected MIB information is created, the collected MIB information is stored in the collected MIB database, and the collected information is stored in the MIB in response to a reference request from the integration manager.
A hierarchical network management system comprising periodic collection means for notifying an integrated manager in a B format. 2. The hierarchical network management system according to claim 1, wherein the periodic collection unit periodically collects management objects that are not installed or not started by the agent. 3. The system according to claim 2, wherein the periodic collection unit collects a plurality of pieces of information about each agent managed by a plurality of identifiers and notifies the integration manager of the reference request from the integration manager. 2. The hierarchical network management system according to 1. 4. The sub-manager includes 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 extended trap to the integrated manager. The hierarchical network management system according to claim 1, wherein 5. A real-time collection means for collecting, in real time, the status of an agent belonging to its own management range in response to a reference request from the integration manager in the sub-manager, and notifying the integration manager of the collected information. The hierarchical network management system according to claim 1, further comprising: 6. The hierarchical network management system according to claim 5, wherein said real-time collection means selects a real-time collection target with reference to the management objects collected by said periodic collection means. 7. The real-time collection means, in response to a reference request from the integration manager, collects a plurality of pieces of information about each agent managed by a plurality of identifiers and notifies the integration manager. 5. The hierarchical network management system according to item 5. 8. The periodic collection means stores the collected MIB information in a collected MIB database in individual information units, and collects the collected MIB information in response to a reference request from the integration manager.
2. The hierarchical network management system according to claim 1, wherein the IB value is combined into an assembly management object and notified to an integrated manager.