JP3696023B2 - Network configuration automatic recognition method and system having intelligent network relay device - Google Patents

Description

[0001]
BACKGROUND OF THE INVENTION
The present invention relates to a physical configuration of each device when an intelligent network relay device that implements SNMP (Simple Network Management Protocol) is included in a network to which routers, switches, bridges, repeaters, hubs, terminals and the like are connected. The present invention relates to a method and system for automatically recognizing various network connection configurations.
[0002]
[Prior art]
The technology for recognizing the physical network connection configuration of each device in a network to which routers, switches, bridges, repeaters, hubs, terminals, etc. are connected is an indispensable technology for network monitoring / management systems and network drawing creation systems. .
In the conventional network connection configuration recognition technology, it is possible to recognize a network divided by IP (Intenet Protocol) network segments (divided in segments divided by routers). Within the scope of this technology, there is often a display method in which devices existing in a network segment divided by a router are listed in parallel, and there is a problem that it is not possible to correspond to the physical configuration of the actual network. It was.
In order to solve the above problems, “network connection device type detection method” (Japanese Patent Laid-Open No. 11-96094), “network monitoring and repeater connected terminal recognition method” (Japanese Patent Laid-Open No. 11-146003), “relay device And network management device "(Japanese Patent Laid-Open No. 10-336228)," Automatic Network Map Generation Method Using BGP Routing Information "(Japanese Patent Laid-Open No. 9-181722)," Network Topology Recognition Method and Network Topology Recognition Device " (Kaihei 9-186716) and “Network Configuration Recognition Method” (Japanese Patent Laid-Open No. 8-191326) have been proposed.
[0003]
[Problems to be solved by the invention]
However, the “network connection device type detection method” provides a technique for recognizing a loop connection existing between a bridge and a device to which the bridge is connected by transmitting an inspection packet to a link between devices. However, there is a problem specializing in loop connection.
In addition, the “network monitoring and repeater hub connection terminal recognition method” provides a technology for recognizing a terminal connected to each port of a repeater by using a repeater MIB (MIB: Management Information Base). However, there is a problem that cannot be detected when a plurality of terminals are connected to the connection destination of each port of the repeater.
In addition, the “relay device and network management device” provides a technique for detecting the connection relationship of the network relay device. However, this is an implementation means that depends on special hardware. What is an implementation means in an existing network configuration? There is a problem that cannot be.
In “Automatic Network Map Generation Method Using BGP Routing Information”, a method for detecting a connection relationship between AS (Autonomouse System) specialized for BGP (Border Gateway Protocol) compatible routers. However, there is a problem that the connection relationship in the network segment cannot be identified.
In addition, the “Network Topology Recognition Method and Network Topology Recognition Device” provides a technology for grasping the connection status of bridge devices using the spanning tree protocol, but the connection relationship between bridges corresponding to the source routing protocol is provided. There is a problem that cannot be detected.
In the “network configuration recognition method”, the MAC address information of the connection destination of each port of the hub (intelligent hub) is used as a repeater MIB under the condition that the connection destination of each port of the hub is only one terminal. By collecting data using, we provide a technology to grasp the physical address of the device at the port connection destination. However, when hubs are connected in cascade, the configuration of the connection destination of each port of the hub cannot be detected, and means for periodically sending from each terminal is required. Must be introduced to The implementation of the repeater MIB differs depending on the vendor, and cannot be said to be a general-purpose repeater solution.
[0004]
The present invention does not require the installation of special software other than SNMP in a network environment in which an intelligent network device that implements SNMP is operating, and does not depend on how SNMP is implemented. It is an object of the present invention to provide a network configuration automatic recognition method and system capable of automatically detecting a physical device configuration inside a network node from a single management terminal.
[0005]
[Means for Solving the Problems]
In order to achieve the above object, the present invention basically provides an SNMP manager in a network environment in which at least one intelligent network device that implements an SNMP agent and a management information base exists in a network node. A first step of transmitting an ICMP echo request from the installed administrator terminal to each network device in the network node and detecting an active network device based on the response, and an SNMP agent of each detected network device A second step of transmitting a transfer request for the management information base storage information in the network device and detecting the type of the network device existing in the network node from the returned management information base storage information. With features That.
Further, a third step of acquiring a set of physical addresses of the network devices connected to each port of the network device from the management information base of the network device having the bridge function as a device type, and management of the network device having the routing function 4th step of acquiring correspondence information between physical address and IP address from information base, and IP level of connection destination device of each port of network device having bridge function based on acquired correspondence information of physical address and IP address And a fifth step of recognizing in (5).
[0006]
Further, it is recognized that the network device to which a response is returned to the ICMP echo request is in operation and no network device to which no response is returned exists, and the correspondence between the physical address acquired in the fourth step and the IP address It is characterized by further comprising a sixth step of referring to the information and recognizing that the network device is not operating when there is correspondence information other than the network device recognized as operating.
[0007]
DETAILED DESCRIPTION OF THE INVENTION
Hereinafter, an embodiment of the present invention will be described in detail with reference to the drawings.
FIG. 1 is a diagram showing an embodiment of a network system for implementing the present invention. The illustrated network has a LAN built around the backbone network 1 and includes relay devices such as routers 2a and 2b, a switching hub 3, a bridge 4, an intelligent hub 5, and a non-intelligent hub 6. These relay apparatuses are assigned unique IP addresses such as “13X.XXX.2.1”.
[0008]
The router 2a (IP address “13X.XXX.2.1”) divides the backbone network 1 and the internal segment. That is, the network is divided into the network of IP address “13X.XXX.1. *” And the network of “13X.XXX.2. *”, And the IP address is “13X” from the network of “13X.XXX.1. *” Side. .XXX.1.7 ", but the IP address is recognized as" 13X.XXX.2.1 "from the" 13X.XXX.2. * "Network.
[0009]
Similarly, the router (IP address “13X.XXX.7.1”) 2b divides the backbone network and the internal segment. That is, the network is divided into the network of IP address “13X.XXX.1. *” And the network of “13X.XXX.7. *”, And the IP address is “13X” from the network of “13X.XXX.1. *” Side. .XXX.1.9 ", but the IP address is recognized as" 13X.XXX.7.1 "from the" 13X.XXX.7. * "Network.
[0010]
Internal segments include switching devices such as switching hub (IP address “13X.XXX.2.246”) 3, bridge (IP address “13X.XXX.2.245”) 4, intelligent hub (IP address “13X.XXX.2.243”) ) 5, and further divided using a network relay device such as a non-intelligent hub (not holding an IP address) 6.
[0011]
A LAN is constructed by connecting another network relay device or terminal devices 71 to 78 to these network relay devices.
[0012]
The network shown in the figure is connected to one administrator terminal 71, and a program for automatically detecting the network configuration is running in the administrator terminal 71. The terminal devices 72 to 78 can be classified into operating terminal devices 72 to 77 and non-operating terminal devices 78, and both are targeted for recognition in the network configuration automatic recognition method of the present embodiment.
[0013]
In FIG. 1, the router 2 a and the switching hub 3 are connected, the switching hub 3 is connected to the bridge 4, the intelligent hub 5, and the non-intelligent hub 6, and the administrator terminal 71 is connected to the switching hub 3. Is shown. Also, an example is shown in which one non-operating terminal device 78 is connected from the bridge 4 and three operating terminal devices 72 to 77 are connected from the intelligent hub 5 and the non-intelligent hub 6.
[0014]
In the present embodiment, a device is simply added to a network configuration automatic recognition service program and a drawing display program on the administrator terminal 71 without adding a program to terminal devices 72 to 78 other than one administrator terminal 71. The connection configuration between them is automatically detected.
The automatic recognition service program has a function as an SNMP manager. Some network devices to be recognized include an SNMP agent and others that do not.
[0015]
First, an overview of the network configuration automatic recognition method of this embodiment will be described.
The network configuration automatic recognition service program includes three modules: an operation status detection module, a MIB access module, and an auto discovery module.
The operating status detection module is a software module that detects the operating status of each device on the network using an ICMP (Internet Control Message Protocol) echo request, and a device with an IP address that does not respond to the ICMP echo request is not operating. Therefore, it has a function of detecting the operating status of each device on the network while avoiding unnecessary communication.
The MIB access module creates an SNMP message (Get-Request PDU, Get-Next PDU, Set-Request PDU), and transmits an SNMP message or receives an SNMP message (Get-Response PDU) to obtain an MIB object value. This is a software module having a function of acquiring This MIB access module is based on the premise that each network device implements an SNMP MIB object.
The auto-discovery module is a software module having a function of detecting a network configuration, and detects the network configuration by the following process.
(1) Device operating status detection process
(2) Device information (IP address, Mac address, host name, support MIB, device type) detection process
(3) MIB object information acquisition process
(4) Connection relationship (connection port) detection process between network relay devices
(5) Non-intelligent hub prediction process
In the process (1), the operating status of the device is detected using the operating status detection module.
In the process (2), the MIB supported by the device is detected by actually accessing the MIB using the MIB access module and checking whether a response is returned or an error is returned. Whether the device type corresponds to any of router, bridge, switching hub, intelligent hub, terminal device, or printer by combining IPMIB (value of ipForwarding object), bridge MIB support, and repeater MIB support Are classified and detected (see FIG. 18).
In the process (3), the value of the MIB object used for detecting the connection relationship between devices is acquired and stored in a table (see FIGS. 14 to 17). In this case, if the information of the device (IP address) that is determined not to be operating in the process (1) is cached in the MIB object, the connection information of the device that is not operating can also be acquired (FIG. 59). reference).
In the process (4), a bridge MIB, a repeater MIB, and an interface MIB are used to detect a connection relationship between network relay devices other than the terminal device among the above devices.
The bridge MIB holds an object that stores a Mac address of a connection destination device of each port of the network relay device, and can detect a connection relationship of each network relay device in units of ports. The repeater MIB holds an object for storing a source Mac address of a frame received last among frames transmitted by an arbitrary device to which a port is connected, and sets a source Mac address at a predetermined time interval. By learning, the connection relationship of each network relay device in units of ports can be detected. However, depending on the implementation of the repeater MIB, there is a network relay device that does not update the source Mac address of the last received frame, and the Mac address cannot be learned using the repeater MIB. There is. In this case, a method of determining that the device that has changed the port status of the interface MIB, temporarily blocked the port, and has not returned an ICMP echo request response is at the connection destination of the blocked port, or a plurality of network relay devices Use the method of acquiring statistics of transmission / reception frames of interface MIB in port and testing whether there is a significant difference in statistics and determining that there is a connection relationship between ports without significant difference Thus, it is possible to detect the connection relationship of each network relay device in units of ports. In addition, connection information for each port that can be acquired from each MIB does not always store connection information for all devices on the network. Connection information for each port may be incomplete and the connection relationship between devices may not be detected. In such a case, the network relay device is classified into a plurality of network relay device models based on the connection information that can be acquired from the MIB (see FIG. 21), the connection relationship model between the devices is defined, and the connection relationship between the devices is defined. The detection conditions and the connection possibility are generalized (see FIG. 46). Due to this generalization, even if the connection information for each port is incomplete and the connection relationship between devices cannot be detected, if the connection relationship information with other devices is combined and the connection relationship detection condition is met, the device The connection relationship between each other can be detected.
Further, by combining a connection relationship model between a plurality of devices, a connection relationship that cannot be detected only with the connection relationship model between individual devices may be detected (see FIG. 55).
[0016]
In the process (5), in order to predict the connection of a non-intelligent hub, it is detected whether multiple devices are connected to the connection destination of one port of the network relay device, and multiple devices are connected Then, the connection of the non-intelligent hub is predicted by determining that at least one non-intelligent hub is operating at the connection destination of the corresponding port of the network relay device.
[0017]
The drawing display program is a program for displaying the network configuration detected by the network configuration automatic recognition service program on the screen as a GUI (see FIG. 62). The network configuration is displayed in a tree structure or displayed on the floor drawing. It is possible to adopt a display form such as.
Note that when the operating status of the device or the network configuration changes, the floor plan needs to be changed promptly accordingly. In addition, examples of the operation status of the device include changes such as start and stop. Further, the change in the network configuration includes a change in the connection destination of the device and a change in the IP address.
The drawing display program collects MIB object values regularly or irregularly according to a predetermined schedule using an auto-discovery module, and monitors changes in MIB object values to change changes in the operating status of devices and networks. A change in the configuration is detected, the change in the network configuration is automatically reflected in the network configuration drawing, and the change is notified to the user (see FIG. 60).
[0018]
FIG. 2 is a diagram showing an SNMP message format, which is a standard protocol for accessing an MIB object used for detecting a connection relationship between devices in the present embodiment.
The SNMP message includes a Version 201 for storing the SNMP version number, a Community 202 for storing the community name, and a PDU (for storing the body of the SNMP message).ProtocolDataUnit) 203 field. SNMP messages are classified into five types of messages: Get-Request, Get-Next, Get-Response, Set-Request, and Trap.
Get-Request and Get-Next are messages for instructing a device having an MIB to return an MIB value, and a Get-Response is returned in response thereto.
A Set-Request is a message issued to change the MIB value. The Trap is a message for autonomously notifying the administrator terminal 71 of an event (an event to be monitored: an important event) that has occurred in a managed device having an MIB.
[0019]
In the network configuration automatic recognition method of the present invention, a message other than Trap is used.
The PDU structure of the Get-Request, Get-Next, Get-Response, and Set-Request messages has a common format, and as shown in FIG. 2, a PDU Type 204 that stores message types (the above four types). Request ID 205 for storing a unique identifier of a message, Error Status 206 for storing an ID of an error message, Error Index 207 for storing an error occurrence location in the message, Lists 208 to 209 storing information for identifying an MIB object to be accessed It is composed of Each element of the list storing information for identifying the MIB object is an OID (identifier for uniquely identifying the MIB object).ObjectIdentifier) and MIB object values.
[0020]
FIG. 3 is a diagram illustrating an Internet OID tree that is a target in the present embodiment. The MIB object 301 is stored as a tree structure in the network relay device. Among these, MIB2 information that is standard in network management is the node 302 of iso (1) -org (3) -dod (6) -internet (1) -mgmt (2) -MIB-2 (2) The OID is "1.3.6.1.2.2".
In the present embodiment, a method using MIB2 is shown. In addition to this, there is a method using vendor MIB (iso (1) -org (3) -dod (6) -internet (1) -private (4) -enterprise (1)) provided by each vendor. However, it is desirable to use MIB2, which is a standard protocol for network management, in order to increase the versatility of the system.
[0021]
FIG. 4 is a diagram showing the configuration of the MIB2 object that is the object of this embodiment. MIB2 currently standardizes 50 objects, and each object is MIB-2 (2) (iso (1) -org (3) -dod (6) -internet (1) -mgmt (2) -MIB -2 (2)) child objects and 401 are managed. MIB2 has group objects of system (1), interfaces (2), at (3), ip (4), ICMP (5), ..., but in this embodiment, system (1), interfaces displayed in bold An example is shown in which the network configuration is automatically recognized by using group objects of (2), ip (4), dot1dBridge (17), SNMPDot3RptrMgt (22), and printMIB (43).
[0022]
FIG. 5 is a diagram showing a configuration of a system group object that is a target in the present embodiment. As a child object 501, sysDescr (1), sysObjecTID (2),... are connected to the system group object. In the present embodiment, an example of automatically recognizing a network configuration by using sysDescr (1) displayed in bold is shown. sysDescr (1) is an object indicating entity (system) information, and the system group object must be implemented on all devices that implement MIB2. Therefore, it grasps the support status of MIB2. Is available for
[0023]
FIG. 6 is a diagram showing the configuration of the interfaces group object that is the object of this embodiment. The interfaces group object is connected with ifNumber (1), ifTable (2),... as child objects 601. ifTable (2) indicates data in a table format, and ifEntry (1) connected in a paragraph under ifTable (1) indicates individual rows of ifTable (2). Further, ifIndex (1), ifDescr (2),..., IfSpecific (22) connected in a paragraph under ifEntry (1) indicate individual columns of ifEntry (1).
In the network relay device, information for each interface (port) of the network relay device is stored in ifTable (2). From now on, it is assumed that table format data in all MIB objects is stored in accordance with the above rules. In this embodiment, ifAdminStatus (7), ifInOctets (10), ifInUcastPkts (11), ifInNUcastPkts (12), ifInDiscards (13), ifInErrors (14), ifOutOctets (16), ifOutUcastPkts (17), ifOutNUcastPkts (18) ), IfOutDiscards (19), and ifOutErrors (20), an example of automatically recognizing the network configuration is shown.
ifAdminStatus (7) is an object indicating the setting of an interface (port), and can be used to control the state of the port from the outside.
ifInOctets (10) is the number of octets received by the interface (port), ifInUcastPkts (11) is the number of unicast packets passed to the upper protocol, ifInNUcastPkts (12) is the number of non-unicast packets passed to the upper protocol, ifInDiscards (13 ) Is the number of arriving packets discarded for reasons other than errors, and ifInErrors (14) is an object indicating the number of arriving packets that were not passed to the upper protocol due to errors.
[0024]
Similarly, ifOutOctets (16) is the number of octets transferred by the interface (port), ifOutUcastPkts (17) is the number of unicast packets received from the upper protocol, ifOutNUcastPkts (18) is the number of non-unicast packets received from the upper protocol, and ifOutDiscards (19) is an object indicating the number of outgoing packets discarded for reasons other than errors, and ifOutErrors (20) is an object indicating the number of outgoing packets that were not transferred due to an error.
ifInOctets (10) to ifOutErrors (20) can be used to detect a port having a connection relationship by comparing statistical information for each port.
[0025]
FIG. 7 is a diagram showing a configuration of an ip group object that is a target in the present embodiment. As a child object 701, ipForwarding (1), ipDefaultTTL (2),... are connected to the ip group object. In this embodiment, an example is shown in which the network configuration is automatically recognized by using ipForwarding (1), ipNetToMediaPhysAddress (2), and ipNetToMediaNetAddress (3) displayed in bold.
ipForwarding (1) is an object indicating whether the entity (system) has an IP routing function, and can be used to determine whether the network relay device is a router.
ipNetToMediaPhysAddress (2) is an object indicating a media-dependent physical address, and ipNetToMediaNetAddress (3) is an object indicating an IP address for the media-dependent physical address.
In a network relay device such as a router, cache information is stored in the ARP (Addres Resolution Protocol; IP address to hardware address conversion procedure) processing of the network segment connected to ipNetToMediaPhysAddress (2) and ipNetToMediaNetAddress (3) Therefore, it can be used to obtain the ARP table (combination of Mac address and IP address) of the segment.
[0026]
FIG. 8 is a diagram showing the configuration of the dot1dBrdige group object that is the object of this embodiment. To the dot1dBrdige group object, dot1Base (1), dot1dStp (2),... are connected as child objects 801.
In the present embodiment, an example in which the network configuration is automatically recognized by using dot1dTpFdbAddress (1) and dot1dTpFdbPort (2) displayed in bold is shown.
dot1dTpFdbAddress (1) is an object indicating the MAC address to which the bridge transmits forwarding / filtering information, and dot1dTpFdbPort (2) is an object indicating the port number of the frame in which dot1dTpFdbAddress is equal to the source address. In a network relay device that supports bridge MIB, a set of Mac addresses of devices connected to each port of the network relay device is stored in dot1dTpFdbAddress (1) and dot1dTpFdbPort (2). It can be used to acquire information on connected devices.
[0027]
FIG. 9 is a diagram showing the configuration of the snmpDot3RptrMgt group object targeted in this embodiment.
rptrBasicPackage (1), rptrMonitorPackage (2),... are connected as child objects 901 to the snmpDot3RptrMgt group object.
In the present embodiment, an example in which the network configuration is automatically recognized by using rptrAddrTrackPortIndex (2), rptrAddrTrackLastSourceAddress (3), and rptrAddrTrackSourceAddrChanges (4) displayed in bold is shown.
rptrAddrTrackPortIndex (2) is an object indicating the identifier of the port belonging to the group, rptrAddrTrackLastSourceAddress (3) is an object indicating the source address of the last received frame, and rptrAddrTrackSourceAddrChanges (4) is an object indicating the change frequency of RptrAddrTrackLastSourceAddress It is.
In the network relay device that supports the repeater MIB, the Mac address of any one device connected to each port of the network relay device is stored in rptrAddrTrackPortIndex (2) and rptrAddrTrackLastSourceAddress (3). In the network relay device implemented according to the specification of RFC (Request for Comment), the value of rptrAddrTrackLastSourceAddress (3) is updated every time a frame is received. Therefore, the network relay device learns the information of rptrAddrTrackLastSourceAddress (3). It is possible to acquire a set of Mac addresses of devices connected to each port. However, in a network relay device that is not implemented according to the RFC specification, the value of rptrAddrTrackLastSourceAddress (3) may not be updated even if a frame is received. RptrAddrTrackSourceAddrChanges (4) can be used to determine whether the network relay device is implemented according to the RFC specifications.
Since RptrAddrTrackSourceAddrChanges (4) indicates the frequency of change of rptrAddrTrackLastSourceAddress (3), the network relay device implemented according to the RFC specifications will increase over time, but the network relay not implemented according to the RFC specifications It does not vary with the equipment. In this case, rptrAddrTrackSourceAddrChanges (4) may store the number of devices detected at the end of each port.
[0028]
FIG. 10 is a diagram showing a configuration of a print MIB group object that is a target in the present embodiment. The print MIB group object is connected as a child object 1001 with ptrGeneral (5), ptrGeneralTable (1),. In the present embodiment, an example of automatically recognizing a network configuration by using ptrGeneralConfigChanges (1) displayed in bold is shown.
ptrGeneralConfigChanges (1) is an object indicating the number of printer setting changes. Since the printMIB group object is implemented by a printer, it can be used to determine whether the device is a printer.
[0029]
FIG. 11 is a diagram showing a program configuration implemented in the administrator terminal 71.
In the system in FIG. 1, in order to automatically recognize the network configuration from one administrator terminal 71 on the network, the communication port 1102, network configuration automatic recognition service program 1103, and drawing display program 1104 are installed in the administrator terminal 71. Has been. The network configuration automatic recognition service program 1103 and the drawing display program 1104 are recorded on a recording medium such as a CD-ROM or DVD-ROM and provided to the user so that they can be installed and executed on a general-purpose computer. Is possible. Further, it can be distributed to users via communication media such as the Internet or communication means for a fee.
The network configuration automatic recognition service program 1103 includes an operation status detection module 1111, a MIB access module 1112, and an auto discovery module 1113.
The MIB access module 1112 manages an OID table (see FIG. 12) that stores MIB2 OID information.
The auto-discovery module 1113 includes an AT table (see FIG. 13) that stores address conversion information from a Mac address to an IP address, a TI table (see FIG. 14) that stores device-specific information, and a network relay device. It manages a PF table (see FIG. 15) that stores connection device information in units of ports, and a TS table (see FIG. 16) that stores connection relation information of the TREE structure of the network configuration.
[0030]
FIG. 12 shows an OID (MIB used by the MIB access module 1112 when transmitting / receiving an SNMP message).ObjectI D(entifier) is a diagram showing the configuration of a table 1121.
The OID table 1121 holds items of Object Name 1201, Object Identifier 1202, type 1203, and Object Path 1204.
The Object Name 1201 stores a unique name of an object used as a key when the MIB access module 1112 searches the OID table 1121, and the Object Identifier 1202 stores a unique identifier of the object to be described in the SNMP message. Type 1203 stores the type of the object, and Object Path 1204 stores the complete path name of the object.
The MIB access module 1112 accesses the OID table 1121 when creating an SNMP message, searches for an identifier of the MIB object to be acquired, and secures a reception buffer according to the object type.
[0031]
FIG. 13 is a diagram showing a configuration of an AT (Address Translation) table 1122 created by the auto-discovery module 1113.
The AT table 1122 holds items of IP Address 1301 and Mac Address 1302. The IP Address 1301 stores the IP address value of the device, and the Mac Address 1302 stores the Mac Address value of the device. Since the AT table 1122 represents a set of sets of IP addresses and Mac addresses of devices, the AT table 1122 is created by acquiring information from a device such as a router that caches address information of the entire segment. This is used when searching for a Mac address using the IP address of the device as a key or when resolving the IP address from the Mac address.
[0032]
FIG. 14 is a diagram showing a configuration of a TI (Terminal Information) table 1123 created by the auto-discovery module 1113.
The TI table 1123 holds items of IP Address 1401, Mac Address 1402, Host Name 1403, type 1404, alive 1405, mib2 1406, forwarding 1407, bridge 1408, repeater 1409, and print 1410.
The IP address 1401 stores the IP address value of the device, the Mac Address 1402 stores the Mac address value of the device, and the Host Name 1403 stores the host name of the device. Type 1404 stores an identifier indicating the type of device. In FIG. 14, 0 is assigned to U representing Unknown, 1 is assigned to R representing Router,..., And 7 is assigned to P representing Printer.
Alive 1405 stores a flag value indicating whether the device is operating or not operating. In FIG. 14, 1 is assigned to On and 0 is assigned to Off. mib2 1406 stores a flag value indicating whether or not the device supports mib2, forwarding 1407 stores a flag value indicating whether or not the device is performing IP forwarding, and bridge 1408 stores the bridge MIB. A flag value indicating whether or not the device is supported is stored, and a repeater 1409 stores a flag value indicating whether or not the device supports the repeater MIB. Print 1410 stores a flag value indicating whether the device supports the printer MIB.
The auto-discovery module 1113 creates a TI table 1123 to facilitate understanding of devices operating in the segment, and searches the TI table 1123 to determine the MIB supported by the device, and to the unsupported MIB. Extra access can be avoided.
[0033]
FIG. 15 is a diagram showing a configuration of a PF (Port Forwarding) table 1124 created by the auto-discovery module 1113.
The PF table 1124 holds items of Source IP Address 1501, Source Mac Address 1502, Source Port 1503, Destination IP Address 1504, and Destination Mac Address 1505.
Source IP Address 1501 stores the IP address value of the network relay device, Source Mac Address 1502 stores the Mac address value of the network relay device, and Source Port 1503 stores the port number of the network relay device.
The Destination IP Address 1504 stores the IP address value of the device operating at the connection destination of the port of the Source Port 1503, and the Destination Mac Address 1505 stores the Mac address value of the device of the Destination IP Address 1504. The PF table 1124 represents connection information between a network relay device operating in a segment and another network relay device or terminal device.
[0034]
FIG. 16 is a diagram showing a configuration of a TS (Tree Structure) table 1125 created by the auto-discovery module 1113.
The TS table 1125 holds items of Terminal IP Address 1601, Terminal Mac Address 1602, Terminal Port 1603, Parent IP Address 1604, Parent Mac Address 1605, and Parent Port 1606.
Terminal IP Address 1601 stores the IP address value of the active device, Terminal Mac Address 1602 stores the Mac address value of the device whose IP address is Terminal IP Address 1601, and Terminal Port 1603 stores the connection port number of the device. . If the device is a terminal device or a network relay device and the port number is unknown, a NULL value is stored in Terminal Port 1603. The Parent IP Address 1604 stores the IP address value of the network relay device directly connected to the port whose terminal number is Terminal Port 1603, and the Parent Mac Address 1605 stores the Mac address value of the network relay device of Parent IP Address 1604. , Parent Port 1606 stores the connection port number.
The difference between the TS table 1125 and the PF table 1124 is that the PF table 1124 stores information on all devices operating at the connection destination of an arbitrary port of the network relay device, so that one device has a plurality of network relay devices. In the TS table 1125, only the information of the network relay device directly connected to one device is added.
[0035]
FIG. 17 is a diagram illustrating a mechanism in which the MIB access module 1112 transmits and receives an SNMP message.
The MIB access module 1112 operating on the administrator terminal 71 creates an SNMP message (Get-Request message or Get-Next message), and on a network relay device (or a device such as a terminal or a printer) 1703 to obtain information. An SNMP message is transmitted to the running SNMP agent 1704. When the SNMP agent 1704 receives the SNMP message, it interprets the SNMP message, creates an SNMP message (Get-Response) storing the value of the requested MIB object, and returns the SNMP message to the MIB access module 1112. As a result, the MIB access module 1112 can acquire the value of an arbitrary MIB object of the network relay apparatus 1703.
[0036]
FIG. 18 is a diagram for explaining a device type detection method.
In the present embodiment, devices that are network configuration recognition targets are a router 1801, a bridge 1802, a switching hub 1803, an intelligent hub 1804, a non-intelligent hub 1805, a printer 1806, and a terminal device 1807. The router 1801 indicates a device whose ip group ipForwarding object has a value “1” and has a bridge MIB, but does not have a repeater MIB or a printer MIB.
The bridge 1802 indicates a device in which the value of the ipForwarding object of the ip group is “0” and the bridge MIB is mounted but the repeater MIB and the printer MIB are not mounted.
The switching hub 1803 indicates a device in which the value of the ipForwarding object of the ip group is “1” or “0”, the bridge MIB and the repeater MIB are mounted, but the printer MIB is not mounted.
The intelligent hub 1804 indicates a device in which the value of the ipForwarding object of the ip group is “0”, the repeater MIB is mounted, but the bridge MIB and printer MIB are not mounted.
A non-intelligent hub 1805 indicates a device in which no MIB is mounted. The printer 1806 indicates a device in which the value of the ipForwarding object in the ip group is “0”, and the printer MIB is mounted but the bridge MIB and the repeater MIB are not mounted.
A terminal device 1807 indicates a device in which the value of the ipForwarding object of the ip group is “0” and the bridge MIB, repeater MIB, and printer MIB are not mounted.
The combination of the value of the ipForwarding object in the ip group, the implementation status of the bridge MIB, the implementation status of the repeater MIB, and the implementation status of the printer MIB is different for each device type, and by detecting this combination, the device type can be detected. It becomes.
[0037]
FIG. 19 is a diagram for explaining a relation definition between network relay devices.
FIG. 19 shows the parent-child relationship of four different network relay devices. The network relay device at the end of the segment is defined as a root device (IP address is “13X.XXX.2.1”) 1901 connected to the backbone network. . Three network relay devices are operating at the Port1 connection destination of the Root device 1901, and the network relay device directly connected to the Port1 of the Root device 1901 is a Parent device (IP address is “13X.XXX.2.246”). ") 1902, the network relay device connected to Port 2 of this Parent device 1902 is the Child 1 device (IP address is" 13X.XXX.2.243 ") 1903, and the network relay device connected to Port 3 of the Parent device 1902 is the Child 2 device ( The IP address is “13X.XXX.2.245”) 1904. Then, an arbitrary network relay device and an arbitrary network relay device that operates at a connection destination of a port different from the port where the Root device exists at the connection destination are defined as parent and child.
[0038]
In the example of FIG. 19, the root device 1901, the parent device 1902, the child 1 device 1903, and the child 2 device 1904 are parent and child. Further, the Parent device 1902, the Child1 device 1903, and the Child2 device 1904 are parent and child.
A set of network relay devices that have the same number of hops to the root device among any network relay device and any network relay device that operates at the connection destination of the port where the root device exists at the connection destination is a sibling. Is defined as
In the example of FIG. 19, the Root device 1901, the Parent device 1902, and the Child2 device 1904 are operating at the Port1 connection destination of the Child1 device 1903, and the number of hops from the Child1 device 1903 to the Root device 1901 is “1”. Since the number of hops from the Child 2 device 1904 to the Root device 1901 is “1”, the Child 1 device 1903 and the Child 2 device 1904 are siblings.
[0039]
FIG. 20 is a diagram for explaining a connection detection method between network relay apparatuses using the interfaces MIB of this embodiment. As shown in the example in the figure, two different network relay devices Unit1 device (IP address is “13X.XXX.2.246”) 2001 and Unit2 device (IP address is “13X.XXX.2.243”) 2002 are operating. In this case, the value of the ifInOctets object and the value of the ifOutOctets object of the interfaces MIB at each port of the network relay device are acquired simultaneously.
The example in FIG. 20 indicates that the value 2003 of the ifInOctets object of Port1 of the Unit1 apparatus 2001, the value 2004 of the ifOutOctets object, the value 2005 of the ifInOctets object of the Unit2 apparatus 2002, and the value 2006 of the ifOutOctets object are acquired.
The difference between the value 2003 of the Port1 ifInOctets object of the Unit1 device 2001 and the value 2006 of the ifOutOctets object of the Unit2 device 2002 or the value 2004 of the ifOutOctets object of the Port1 of the Unit1 device 2001 and the value 2005 of the ifInOctets object of the Unit2 device 2002 is tested. When it is calculated that there is no significant difference, it is detected that there is a connection relationship between Port1 of the Unit1 apparatus 2001 and Port1 of the Unit2 apparatus 2002. Here, as an example, the significant difference indicates that two values are statistically different, such that two values are different when the difference between the two values exceeds a certain threshold.
[0040]
FIG. 21 is a diagram showing a method for classifying network devices in the present embodiment.
The network device models in this embodiment are R2101, CF2102, IF2103, SF2104, NF2105, and Term2106.
R indicates a network relay device (Router) to be divided into segments, and is a parent for all devices in the segment. Also, the network relay device classifies into CF, IF, and SF according to device connection information that can be acquired from the MIB. CF indicates a network relay device that can create a PF table (FIG. 15) that stores connection ports of all network relay devices and terminal devices without any deficiency in MIB object storage information.
IF indicates a network relay device in which there is a case where there is a defect in the storage information of the MIB object and the connection port number to other network relay devices except R cannot be detected.
SF has a deficiency in MIB object storage information, cannot detect connection ports to all other network relay devices including R, and cannot detect a network relay device that can detect connection ports to one or more terminal devices. Show. In addition, non-intelligent hubs and repeaters that do not have MIB installed are designated as NF. Devices other than network relay devices such as printers and terminal devices are termed Term.
[0041]
FIG. 22 shows the connection detection mechanism of the R-CF-CF model of this embodiment.
As an example of the R-CF-CF model, FIG. 22 shows a connection relationship between port 2 of R (IP address “13X.XXX.2.1”) 2201 and port 2 of CF1 (IP address “13X.XXX.2.246”) 2202. Yes, a case where there is a connection relationship between port 1 of CF1 (IP address “13X.XXX.2.246”) 2202 and port 1 of CF2 (IP address “13X.XXX.2.243”) 2203 is shown.
[0042]
FIG. 23 shows an example of entries in the PF table 1124 used for connection detection of the R-CF-CF model of this embodiment. Here, the entries in the PF table 1124 for the R-CF-CF model shown in FIG. Is illustrated.
Here, connection information from CF1 (IP address “13X.XXX.2.246”) 2202 to CF2 (IP address “13X.XXX.2.243”) 2203 is stored in entry 2301. From this connection information, it can be detected that the connection port from CF1 2202 to CF2203 is port 1.
Similarly, entry 2302 stores connection information from CF1 (IP address “13X.XXX.2.246”) 2202 to R (IP address “13X.XXX.2.1”) 2201. From this connection information, it is possible to detect that the connection port from CF1 2202 to R2201 is port 2. Further, since the connection port from CF1 2202 to R2201 and the connection port from CF12202 to CF22203 are different, it can be detected that CF12202 is the parent of CF22203.
Further, connection information from the CF2 (IP address “13X.XXX.2.243”) 2203 to R (IP address “13X.XXX.2.1”) 2201 is stored in the entry 2303. From this connection information, it can be detected that the connection port from CF2203 to R2201 is port 1.
The entry 2304 stores connection information from the CF 2 (IP address “13X.XXX.2.243”) 2203 to the CF 1 (IP address “13X.XXX.2.246”) 2202. From this connection information, it is possible to detect that the connection port from CF2203 to CF12202 is port 1.
In this way, in the R-CF-CF model, it is possible to detect a connection port and a parent-child relationship of a device under an arbitrary condition.
[0043]
FIG. 24 shows the connection detection mechanism of the R-CF-IF model of this embodiment.
As an example of the R-CF-IF model, FIG. 24 shows a connection relationship between port 2 of R (IP address “13X.XXX.2.1”) 2401 and port 2 of CF (IP address “13X.XXX.2.246”) 2402. Yes, it shows a case where there is a connection relationship between port 1 of CF (IP address “13X.XXX.2.246”) 2402 and port 1 of IF (IP address “13X.XXX.2.243”) 2403.
[0044]
FIG. 25 shows an example of entries in the PF table 1124 used for connection detection of the R-CF-IF model of this embodiment. Here, the entries in the PF table 1124 for the R-CF-IF model shown in FIG. Is illustrated.
Here, the entry 2501 stores connection information from the CF (IP address “13X.XXX.2.246”) 2402 to the IF (IP address “13X.XXX.2.243”) 2403. From this connection information, it is possible to detect that the connection port from the CF 2402 to the IF 2403 is port 1.
The entry 2502 stores connection information from the CF (IP address “13X.XXX.2.246”) 2402 to R (IP address “13X.XXX.2.1”) 2401. From this connection information, it is possible to detect that the connection port from the CF 2402 to the R 2401 is port 2. Further, since the connection port from the CF 2402 to the R 2401 is different from the connection port from the CF 2402 to the IF 2403, it can be detected that the CF 2402 is the parent of the IF 2403.
The entry 2503 stores connection information from the IF (IP address “13X.XXX.2.243”) 2403 to the R (IP address “13X.XXX.2.1”) 2401. From this connection information, it can be detected that the connection port from IF 2403 to R 2401 is port 1. Since the connection port from IF 2403 to R 2401 is port 1 and CF 2402 is the parent of IF 2403, the connection port from IF 2403 to CF 2402 is the same as the connection port from IF 2403 to R 2401. Therefore, it can be detected that the connection port from the IF 2403 to the CF 2402 is port 1. In this way, in the R-CF-IF model, it is possible to detect the connection port and the parent-child relationship of the device under arbitrary conditions.
[0045]
FIG. 26 is a diagram showing a connection detection mechanism of the R-CF-SF model of the present embodiment. Here, R (IP address “13X.XXX.2.1”) is taken as an example of the R-CF-SF model. 2601 port 2 and CF (IP address "13X.XXX.2.246") 2602 have a connection relationship, and CF (IP address "13X.XXX.2.246") 2602 port 1 and SF (IP address "13X" .XXX.2.243 ") 2603 has a connection relationship with port 1 and any term 1 (IP address" 13X.XXX.2.102 ") 2604 ahead of port 3 of CF (IP address" 13X.XXX.2.246 ") 2602 Shows the case where is connected.
[0046]
FIG. 27 shows an example of entries in the PF table 1124 used for connection detection of the R-CF-SF model of this embodiment, and exemplifies the entries in the PF table 1124 for the R-CF-SF model shown in FIG. are doing.
The entry 2701 stores connection information from the CF (IP address “13X.XXX.2.246”) 2602 to the SF (IP address “13X.XXX.2.243”) 2603. From this connection information, it can be detected that the connection port from the CF 2602 to the SF 2603 is port 1.
The entry 2702 stores connection information from the CF (IP address “13X.XXX.2.246”) 2602 to R (IP address “13X.XXX.2.1”) 2601. From this connection information, it is possible to detect that the connection port from the CF 2602 to the R 2601 is port 2. Since the connection port from CF 2602 to R 2601 and the connection port from CF 2602 to SF 2603 are different, it can be detected that CF 2602 is the parent of SF 2603.
The entry 2703 stores connection information from the CF (IP address “13X.XXX.2.246”) 2602 to Term1 (IP address “13X.XXX.2.102”) 2604. From this connection information, it is possible to detect that the connection port from the CF 2602 to the Term 12604 is the port 3. Further, since the connection port from the CF 2602 to the SF 2603 is different from the connection port from the CF 2602 to the Term 12604, it can be detected that the Term 12604 is not a device connected to the SF 2603.
The entry 2704 stores connection information from SF (IP address “13X.XXX.2.243”) 2603 to Term1 (IP address “13X.XXX.2.102”) 2604. From this connection information, it is possible to detect that the connection port from SF 2603 to Term 12604 is port 1. Since the connection port from SF 2603 to Term 12604 is port 1 and Term 12604 is not a device connected to SF 2603, the connection port from SF 2603 to CF 2602 is the same as the connection port from SF 2603 to Term 12604.
Therefore, it can be detected that the connection port from the SF 2603 to the CF 2602 is port 1.
In this way, in the R-CF-SF model, it is possible to detect the connection port of the device and the parent-child relationship under the condition that the connection information of CF2602 and Term12604 and the connection information of SF2603 and Term12604 are stored in the PF table 1124. It is.
[0047]
FIG. 28 is a diagram showing a connection detection mechanism of the R-IF-CF model of this embodiment. As an example of the R-IF-CF model, port 2 of R (IP address “13X.XXX.2.1”) 2801 And IF (IP address “13X.XXX.2.246”) 2802 are connected to port 2 of IF (IP address “13X.XXX.2.246”) 2802 and CF (IP address “13X.XXX.2.243”). ") There is a connection relationship with port 1 of 2803, and any term 1 (IP address" 13X.XXX.2.2 ") 2804 is connected to the end of port 2 of CF (IP address" 13X.XXX.2.243 ") 2803 The case is shown as an example.
[0048]
FIG. 29 shows an example of entries in the PF table 1124 used for connection detection of the R-IF-CF model of this embodiment, and exemplifies the entries in the PF table 1124 for the R-IF-CF model shown in FIG. are doing. Here, connection information from IF (IP address “13X.XXX.2.246”) 2802 to Term1 (IP address “13X.XXX.2.2”) 2804 is stored in entry 2901. From this connection information, it is possible to detect that the connection port from IF 2802 to Term 12804 is port 1. In addition, connection information from IF (IP address “13X.XXX.2.246”) 2802 to R (IP address “13X.XXX.2.1”) 2801 is stored in entry 2902. From this connection information, it is possible to detect that the connection port from IF 2802 to R 2801 is port 2. The entry 2903 stores connection information from the CF (IP address “13X.XXX.2.243”) 2803 to the R (IP address “13X.XXX.2.1”) 2801. From this connection information, it can be detected that the connection port from the CF 2803 to the R 2801 is the port 1. The entry 2904 stores connection information from the CF (IP address “13X.XXX.2.243”) 2803 to the IF (IP address “13X.XXX.2.246”) 2802. From this connection information, it can be detected that the connection port from the CF 2803 to the IF 2802 is port 1. Further, since the connection port from CF2803 to R2801 is equal to the connection port from CF2803 to IF2802, it can be detected that IF2802 is the parent of CF2803 or IF2802 and CF2803 are siblings. The entry 2905 stores connection information from the CF (IP address “13X.XXX.2.243”) 2803 to Term1 (IP address “13X.XXX.2.2”) 2804. With this connection information, the connection port from CF2803 to Term12804 is the port2It can be detected. Since the connection port from CF2803 to R2801 is different from the connection port from CF2803 to Term12804, Term12804 is a device connected to CF2803, and the connection port from IF2802 to R2801 and the connection port from IF2802 to Term12804 different. Therefore, IF 2802 is the parent of CF 2803, and it can be detected that the connection port from IF 2802 to CF 2803 is port 1. In this way, in the R-IF-CF model, it is possible to detect the connection port of the device and the parent-child relationship under the condition that the connection information of IF 2802 and Term 12804 and the connection information of CF 2803 and Term 12804 are stored in the PF table 1124. It is.
[0049]
FIG. 30 is a diagram showing a connection detection mechanism of the R-IF-IF model of this embodiment. As an example of the R-IF-IF model, port 2 of R (IP address “13X.XXX.2.1”) 3001 is shown. And IF1 (IP address “13X.XXX.2.246”) 3002 have a connection relationship, and IF1 (IP address “13X.XXX.2.246”) 3002 port 1 and IF2 (IP address “13X.XXX.2.246”) ") There is a connection relationship with port 1 of 3003, and any term 1 (IP address" 13X.XXX.2.102 ") 3004 is connected to port 3 of IF1 (IP address" 13X.XXX.2.246 ") 3002. In this example, an arbitrary Term2 (IP address “13X.XXX.2.2”) 3005 is connected to the end of the port 2 of the IF2 (IP address “13X.XXX.2.243”) 3003.
[0050]
FIG. 31 shows an example of entries in the PF table 1124 used for connection detection of the R-IF-IF model of this embodiment, and exemplifies the entries in the PF table 1124 for the R-IF-IF model shown in FIG. are doing.
Here, connection information from IF1 (IP address “13X.XXX.2.246”) 3002 to Term2 (IP address “13X.XXX.2.2”) 3005 is stored in entry 3101. From this connection information, it is possible to detect that the connection port from IF 13002 to Term 23005 is port 1.
The entry 3102 stores connection information from IF1 (IP address “13X.XXX.2.246”) 3002 to R (IP address “13X.XXX.2.1”) 3001. From this connection information, it is possible to detect that the connection port from the IF 13002 to the R 3001 is port 2.
The entry 3103 stores connection information from the IF1 (IP address “13X.XXX.2.246”) 3002 to the Term1 (IP address “13X.XXX.2.102”) 3004. From this connection information, it is possible to detect that the connection port from IF 13002 to Term 13004 is port 3.
The entry 3104 stores connection information from IF2 (IP address “13X.XXX.2.243”) 3003 to R (IP address “13X.XXX.2.1”) 3001. Based on this connection information, it is possible to detect that the connection port from IF 2303 to R 3001 is port 1.
[0051]
The entry 3105 stores connection information from the IF2 (IP address “13X.XXX.2.243”) 3003 to Term1 (IP address “13X.XXX.2.102”) 3004. From this connection information, it is possible to detect that the connection port from IF 2303 to Term 13004 is port 1.
The entry 3106 stores connection information from IF2 (IP address “13X.XXX.2.243”) 3003 to Term2 (IP address “13X.XXX.2.2”) 3005. From this connection information, it is possible to detect that the connection port from IF 2303 to Term 23005 is port 2. Further, since the connection port from IF13002 to R3001 and the connection port from IF13002 to Term13004 are different, it is possible to detect that IF13002 is a device connected between R3001 and Term13004.
[0052]
Similarly, since the connection port from IF23003 to R3001 is equal to the connection port from IF23003 to Term13004, it is possible to detect that Term13004 is a device connected between R3001 and IF23003. Therefore, it is possible to detect that IF13002 is a device connected between R3001 and IF23003, and that IF13002 is a parent of IF23003. Since IF13002 is the parent of IF23003, the connection port from IF23002 to R3001 is equal to the connection port from IF23003 to IF13002, and therefore it can be detected that the connection port from IF23003 to IF13002 is port1. Further, since the connection port from IF2303 to R3001 is different from the connection port from IF23003 to Term23005, it is possible to detect that IF23003 is a device connected between R3001 and Term23005. Since IF13002 is the parent of IF23003, IF23003 is connected between IF13002 and Term23005, so the connection port from IF13002 to Term23005 and the connection port from IF13002 to IF23003 are the same.
Therefore, it is possible to detect that the connection port from IF13002 to IF23003 is port 1.
In this way, in the R-IF-IF model, the connection port of the device and the parent-child relationship under the condition that the connection information of IF13002 and Term13004, Term23005 and the connection information of IF23003, Term13004, and Term23005 are stored in the PF table 1124. Can be detected.
[0053]
FIG. 32 is a diagram illustrating a connection detection mechanism of the R-IF-SF model according to the present embodiment. As an example of the R-IF-SF model, a port of R (IP address “13X.XXX.2.1”) 3201 is illustrated. 2 and IF (IP address “13X.XXX.2.246”) 3202 have a connection relationship with port 2 of IF (IP address “13X.XXX.2.246”) 3202 and SF (IP address “13X.XXX. 2.243 ") Port 3 of 3203 is connected, and any Term1 (IP address" 13X.XXX.2.102 ") 3204 is connected to the port 3 of IF (IP address" 13X.XXX.2.246 ") 3202 Arbitrary Term2 (IP address “13X.XXX.2.2”) 3205 is connected to the end of port 2 of SF (IP address “13X.XXX.2.243”) 3203, and SF (IP address “13X” .XXX.2.243 ") 3203 port 3 is connected to an arbitrary Term3 (IP address" 13X.XXX.2.110 ") 3206.
[0054]
FIG. 33 shows an example of entries in the PF table 1124 used for connection detection of the R-IF-SF model of the present embodiment. The entries in the PF table 1124 for the R-IF-SF model shown in FIG. Illustrated.
The entry 3301 stores connection information from the IF (IP address “13X.XXX.2.246”) 3202 to the Term2 (IP address “13X.XXX.2.2”) 3205. From this connection information, it can be detected that the connection port from IF 3202 to Term 2 3205 is port 1.
The entry 3302 stores connection information from the IF (IP address “13X.XXX.2.246”) 3202 to Term3 (IP address “13X.XXX.2.110”) 3206. From this connection information, it can be detected that the connection port from IF 3202 to Term 3206 is port 1.
The entry 3303 stores connection information from the IF (IP address “13X.XXX.2.246”) 3202 to the R (IP address “13X.XXX.2.1”) 3201. From this connection information, it is possible to detect that the connection port from IF 3202 to R3201 is port 2.
[0055]
The entry 3304 stores connection information from the IF (IP address “13X.XXX.2.246”) 3202 to Term1 (IP address “13X.XXX.2.102”) 3204. From this connection information, it is possible to detect that the connection port from IF 3202 to Term 1 3204 is port 3.
In addition, connection information from SF (IP address “13X.XXX.2.246”) 3203 to Term1 (IP address “13X.XXX.2.102”) 3204 is stored in entry 3305. From this connection information, it can be detected that the connection port from SF 3203 to Term 1 3204 is port 1.
The entry 3306 stores connection information from the SF (IP address “13X.XXX.2.243”) 3203 to the Term2 (IP address “13X.XXX.2.2”) 3205. From this connection information, it is possible to detect that the connection port from SF 3203 to Term 2 3205 is port 2.
The entry 3307 stores connection information from SF (IP address “13X.XXX.2.243”) 3203 to Term3 (IP address “13X.XXX.2.110”) 3206. From this connection information, it is possible to detect that the connection port from SF 3203 to Term 3206 is port 3. Further, since the connection port from IF 3202 to R3201 is different from the connection port from IF 3202 to Term2 3205, it is possible to detect that IF3202 is a device connected between R3201 and Term23205. Similarly, since the connection port from IF 3202 to R3201 is different from the connection port from IF 3202 to Term3 3206, it is possible to detect that IF3202 is a device connected between R3201 and Term33206.
[0056]
Further, since the connection port from SF 3203 to Term 2 3205 and the connection port from SF 3203 to Term 3 3206 are different, it is possible to detect that SF 3203 is an apparatus connected between Term 2 3205 and Term 3 3206. Accordingly, it is possible to detect that SF 3203 is a device connected between IF 3202 and Term 2 3205 and Term 3 3206, and it is possible to detect that IF 3202 is the parent of SF 3203. Further, since the connection port from IF 3202 to SF 3203 is equal to the connection port from IF 3202 to Term 2 3205 and Term 3 3206, it can be detected that the connection port from IF 3202 to SF 3203 is port 1.
Further, since the connection port from IF 3202 to R3201 is different from the connection port from IF 3202 to Term 1 3204, it can be detected that IF 3202 is a device connected between R 3201 and Term 1 3204.
[0057]
Similarly, since the connection port from IF 3202 to SF 3203 is different from the connection port from IF 3202 to Term 1 3204, it is possible to detect that IF 3202 is a device connected between SF 3203 and Term 1 3204. Therefore, the connection port from SF 3203 to IF 3202 is equal to the connection port from SF 3203 to Term 1 3204. Therefore, it can be detected that the connection port from the SF 3203 to the IF 3202 is port 1.
In this way, in the R-IF-SF model, the connection port of the device and the parent-child relationship under the condition that the connection information of IF 3202 and Term 13204 to Term 33206 and the connection information of SF 3203 and Term 1320 to Term 33206 are stored in the PF table 1124. Can be detected.
[0058]
FIG. 34 is a diagram showing a connection detection mechanism of the R-SF-CF model of this embodiment. As an example of the R-SF-CF model, a port of R (IP address “13X.XXX.2.1”) 3401 2 and NF (no IP address) 3402 have a connection relationship, and NF (no IP address) port 2 and SF (IP address “13X.XXX.2.246”) 3403 have a connection relationship, Furthermore, there is a connection relationship between port 1 of SF (IP address “13X.XXX.2.246”) 3403 and port 1 of CF (IP address “13X.XXX.2.243”) 3404, and port 1 of NF (no IP address) 3402. Arbitrary Term1 (IP address “13X.XXX.2.51”) 3205 is connected to the end of port 2 of Arbitrary Term2 (IP address “13X.XXX.2.243”) 3404. 13X.XXX.2.2 ") 3406 is connected.
[0059]
FIG. 35 shows an example of entries in the PF table 1124 used for connection detection of the R-SF-CF model of this embodiment, and exemplifies the entries in the PF table 1124 for the R-SF-CF model shown in FIG. are doing.
The entry 3501 stores connection information from SF (IP address “13X.XXX.2.246”) 3403 to Term2 (IP address “13X.XXX.2.2”) 3406. From this connection information, it can be detected that the connection port from SF 3403 to Term 23406 is port 1.
In addition, connection information from SF (IP address “13X.XXX.2.246”) 3403 to Term1 (IP address “13X.XXX.2.51”) 3405 is stored in entry 3502. From this connection information, it can be detected that the connection port from SF 3403 to Term 13405 is port 2.
In addition, connection information from the CF (IP address “13X.XXX.2.243”) 3404 to R (IP address “13X.XXX.2.1”) 3401 is stored in the entry 3503. From this connection information, it is possible to detect that the connection port from the CF 3404 to R3401 is port 1.
[0060]
The entry 3504 stores connection information from the CF (IP address “13X.XXX.2.243”) 3304 to Term1 (IP address “13X.XXX.2.51”) 3405. From this connection information, it is possible to detect that the connection port from CF 3404 to Term 13405 is port 1.
The entry 3505 stores connection information from the CF (IP address “13X.XXX.2.243”) 3404 to the SF (IP address “13X.XXX.2.246”) 3403. From this connection information, it can be detected that the connection port from the CF 3404 to the SF 3403 is port 1.
The entry 3506 stores connection information from the CF (IP address “13X.XXX.2.243”) 3404 to the Term2 (IP address “13X.XXX.2.2”) 3406. From this connection information, it is possible to detect that the connection port from CF 3404 to Term 2 3406 is port 2. Since the connection port from CF 3404 to R 3401 and the connection port from CF 3404 to SF 3403 are equal, it can be detected that SF 3403 is a parent or sibling of CF 3404 and the connection port from CF 3404 to SF 3403 is 1. Further, since the connection port from SF 3403 to Term 13405 is different from the connection port from SF 3403 to Term 23406, it can be detected that SF 3403 is a device connected between Term 13405 and Term 23406.
[0061]
Since the connection port from CF 3404 to SF 3403 is different from the connection port from CF 3404 to Term 2 3406, CF 3404 is a device connected between SF 3403 and Term 2 3406. The connection port from SF 3403 to Term 2 3406 and from SF 3403 to CF 3404 Connection ports are equal. Therefore, it can be detected that the connection port from SF 3403 to CF 3404 is 1. In addition, since the connection port from SF 3403 to R 3401 cannot be detected, the parent-child relationship between SF 3403 and CF 3404 cannot be detected (if NF 3402 is connected between SF 3403 and CF 3404, SF 3403 and CF 3404 are siblings. Become).
In this way, in the R-SF-CF model, only the connection port of the device is detected under the condition that the connection information of SF 3403 and Term 13405 and Term 23406 and the connection information of CF and Term 13405 and Term 23406 are stored in the PF table 1124. Is possible.
[0062]
FIG. 36 is a diagram showing a connection detection mechanism of the R-SF-IF model of this embodiment. As an example of the R-SF-IF model, a port of R (IP address “13X.XXX.2.1”) 3601 is shown. 2 and port 3 of NF (no IP address) 3602 have a connection relationship, and port 2 of NF (no IP address) 3602 and port 2 of SF (IP address “13X.XXX.2.246”) 3603 have a connection relationship Furthermore, there is a connection relationship between port 1 of SF (IP address “13X.XXX.2.246”) 3603 and port 1 of IF (IP address “13X.XXX.2.243”) 3604, and port of NF (no IP address) 3602 Arbitrary Term 1 (IP address “13X.XXX.2.51”) 3605 is connected ahead of 1 and further Term 2 (IP address “13X.XXX.2.246”) 3603 is ported ahead of port 3 of SF (IP address “13X.XXX.2.246”). Address “13X.XXX.2.102”) 3606 is connected, and any term 3 (I) is connected to port 2 of IF (IP address “13X.XXX.2.243”) 3604. Shows the case where the address "13X.XXX.2.2") 3607 are connected.
[0063]
FIG. 37 shows an example of entries in the PF table 1124 used for connection detection of the R-SF-IF model of this embodiment, and exemplifies the entries in the PF table 1124 for the R-SF-IF model shown in FIG. are doing.
An entry 3701 stores connection information from SF (IP address “13X.XXX.2.246”) 3603 to Term3 (IP address “13X.XXX.2.2”) 3607. From this connection information, it is possible to detect that the connection port from SF 3603 to Term 3 3607 is port 1.
The entry 3702 stores connection information from SF (IP address “13X.XXX.2.246”) 3603 to Term1 (IP address “13X.XXX.2.51”) 3605. From this connection information, it is possible to detect that the connection port from SF 3603 to Term 13605 is port 2.
The entry 3703 stores connection information from SF (IP address “13X.XXX.2.246”) 3603 to Term2 (IP address “13X.XXX.2.102”) 3606. From this connection information, it is possible to detect that the connection port from SF 3603 to Term 2 3606 is port 3.
[0064]
The entry 3704 stores connection information from IF (IP address “13X.XXX.2.243”) 3604 to R (IP address “13X.XXX.2.1”) 3601. From this connection information, it is possible to detect that the connection port from IF 3604 to R 3601 is port 1.
The entry 3705 stores connection information from IF (IP address “13X.XXX.2.243”) 3604 to Term1 (IP address “13X.XXX.2.51”) 3605. Based on this connection information, it can be detected that the connection port from IF 3604 to Term 13605 is port 1.
Also, entry 3706 stores connection information from IF (IP address “13X.XXX.2.243”) 3604 to Term2 (IP address “13X.XXX.2.102”) 3606. From this connection information, it is possible to detect that the connection port from IF 3604 to Term 2 3606 is port 1.
Also, entry 3707 stores connection information from IF (IP address “13X.XXX.2.243”) 3604 to Term3 (IP address “13X.XXX.2.2”) 3607. Based on this connection information, it is possible to detect that the connection port from IF 3604 to Term 3 3607 is port 2. Further, since the connection port from IF 3604 to R 3601 is equal to the connection port from IF 3604 to Term 13605, it can be detected that Term 13605 is a device connected between R 3601 and IF 3604.
[0065]
Similarly, since the connection port from IF 3604 to R 3601 is equal to the connection port from IF 3604 to Term 2 3606, it is possible to detect that Term 2 3606 is a device connected between R 3601 and IF 3604. Further, since the connection port from SF 3603 to Term 13605 is different from the connection port from SF 3603 to Term 2 3606, it is possible to detect that SF 3603 is a device connected between Term 13605 and Term 2 3606.
Therefore, since the connection port from IF 3604 to SF 3603 is equal to the connection port from IF 3604 to Term 13605 and Term 2 3606, it can be detected that the connection port from IF 3604 to SF 3603 is 1. Further, since the connection port from IF 3604 to R 3601 and the connection port from IF 3604 to Term 33607 are different, it is possible to detect that IF 3604 is a device connected between R 3601 and Term 33607. Furthermore, since SF 3603 is connected between R 3601 and IF 3604, it can be detected that IF 3604 is connected between SF 3603 and Term 3607.
[0066]
Therefore, since the connection port from SF 3603 to IF 3604 is equal to the connection port from SF 3603 to Term3 3607, it can be detected that the connection port from SF 3603 to IF 3604 is 1. In addition, since the connection port from SF 3603 to R 3601 cannot be detected, the parent-child relationship between SF 3603 and IF 3604 cannot be detected.is there. thisIn this way, in the R-IF-SF model, only the connection port of the device is detected under the condition that the connection information of SF 3603 and Term 13605 to Term 33607 and the connection information of IF 3604 and Term 13605 to Term3 3607 are stored in the PF table 1124. It becomes possible.
[0067]
FIG. 38 is a diagram showing a mechanism for connection detection of the R-SF-SF model of the present embodiment. As an example of the R-SF-SF model,R(IP address “13X.XXX.2.1”) Port 2 of 3801 and port 3 of NF (no IP address) 3802 are connected, and port 2 of NF (no IP address) 3802 and SF1 (IP address “13X.XXX”). XXX.2.246 ") 3803 is connected to port 2, and SF1 (IP address" 13X.XXX.2.246 ") 3803 is connected to port 1 and SF2 (IP address" 13X.XXX.2.243 ") 3804 is connected to port 1 Arbitrary Term1 (IP address “13X.XXX.2.51”) 3805 is connected to the end of port 1 of NF (no IP address) 3802, and SF2 (IP address “13X.XXX.2.243” ) The case where an arbitrary Term2 (IP address “13X.XXX.2.2”) 3806 is connected to the port 2 of 3804 is shown.
[0068]
FIG. 39 shows an example of entries in the PF table 1124 used for connection detection of the R-SF-SF model of this embodiment, and exemplifies the entries in the PF table 1124 for the R-SF-SF model shown in FIG. are doing.
First, connection information from SF1 (IP address “13X.XXX.2.246”) 3803 to Term2 (IP address “13X.XXX.2.2”) 3806 is stored in entry 3901. From this connection information, it is possible to detect that the connection port from SF 13803 to Term 2 3806 is port 1.
The entry 3902 stores connection information from SF1 (IP address “13X.XXX.2.246”) 3803 to Term1 (IP address “13X.XXX.2.51”) 3805. From this connection information, it is possible to detect that the connection port from SF 13803 to Term 13805 is port 2.
[0069]
The entry 3903 stores connection information from SF2 (IP address “13X.XXX.2.246”) 3804 to Term1 (IP address “13X.XXX.2.51”) 3805. From this connection information, it is possible to detect that the connection port from SF 23804 to Term 13805 is port 1.
The entry 3903 stores connection information from SF2 (IP address “13X.XXX.2.243”) 3804 to Term2 (IP address “13X.XXX.2.2”) 3806. Based on this connection information, it is possible to detect that the connection port from SF23804 to Term2806 is port 2.
However, from the entry in the PF table 1124, it is not possible to determine when there is a connection relationship between port 1 of SF13803 and port 1 of SF23804 and when there is a connection relationship between port 2 of SF13803 and port 2 of SF23804. Can not. Further, since the connection relationship between SF13803 and R3801 and the connection relationship between SF23804 and R3801 cannot be detected, the parent-child relationship cannot be detected. In the R-SF-SF model, it is impossible to detect the connection port and parent-child relationship of devices under arbitrary conditions.
[0070]
FIG. 40 is a diagram showing a connection detection mechanism of the R-CF model of this embodiment. As an example of the R-CF model, port 2 of R (IP address “13X.XXX.2.1”) 4001 and CF (IP The address “13X.XXX.2.246”) 4002 port 2 has a connection relationship.
[0071]
FIG. 41 shows an example of entries in the PF table 1124 used for connection detection of the R-CF model of this embodiment, and exemplifies the entries in the PF table 1124 for the R-CF model shown in FIG.
In an entry 4101, connection information from R (IP address “13X.XXX.2.1”) 4001 to CF (IP address “13X.XXX.2.246”) 4002 is stored. From this connection information, it is possible to detect that the connection port from R4001 to CF4002 is port2.
In addition, connection information from CF (IP address “13X.XXX.2.246”) 4002 to R (IP address “13X.XXX.2.1”) 4001 is stored. From this connection information, it is possible to detect that the connection port from the CF 4002 to the R4001 is port 2. Even when there is no connection information from R (IP address “13X.XXX.2.1”) 4001 to CF (IP address “13X.XXX.2.246”) 4002, R (IP address “13X.XXX.2.1”) If connection information of 4001 and an arbitrary device on the “13X.XXX.2. *” Network exists, that port becomes a connection port from the R4001 to the CF4002. Even if there is no connection information from CF (IP address “13X.XXX.2.246”) 4002 to R (IP address “13X.XXX.2.1”) 4001, CF (IP address “13X.XXX.2.246”) If connection information of a device connected to a different segment from 4002 exists, that port becomes a connection port from the CF 4002 to the R4001.
In this way, in the R-CF model, it is possible to detect the connection port and the parent-child relationship of the device under arbitrary conditions.
[0072]
FIG. 42 is a diagram showing a connection detection mechanism of the R-IF model of this embodiment. As an example of the R-IF model, port 2 of IF (IP address “13X.XXX.2.1”) 4201 and IF (IP The address “13X.XXX.2.246”) 4202 port 2 has a connection relationship.
[0073]
FIG. 43 shows an example of entries in the PF table 1124 used for connection detection of the R-IF model of this embodiment, and exemplifies entries in the PF table 1124 for the R-IF model shown in FIG.
The entry 4301 stores connection information from the R (IP address “13X.XXX.2.1”) 4201 to the IF (IP address “13X.XXX.2.246”) 4202. From this connection information, it is possible to detect that the connection port from R4201 to IF4202 is port2.
The entry 4302 stores connection information from the IF (IP address “13X.XXX.2.246”) 4202 to the R (IP address “13X.XXX.2.1”) 4201. From this connection information, it is possible to detect that the connection port from IF 4202 to R4201 is port 2.
Even if there is no connection information from R (IP address “13X.XXX.2.1”) 4201 to IF (IP address “13X.XXX.2.246”) 4202, R (IP address “13X.XXX.2.1”) If there is connection information of any device on the network 4201 and “13X.XXX.2. *” Network, that port becomes a connection port from R4201 to IF4202. Even if there is no connection information from IF (IP address “13X.XXX.2.246”) 4202 to R (IP address “13X.XXX.2.1”) 4201, IF (IP address “13X.XXX.2.246”) If connection information of a device connected to a different segment from 4202 exists, that port becomes a connection port from IF 4202 to R4201.
In this way, in the R-IF model, it is possible to detect the connection port and the parent-child relationship of the device under arbitrary conditions.
[0074]
FIG. 44 is a diagram showing a connection detection mechanism of the R-SF model of this embodiment. As an example of the R-SF model, port 2 of R (IP address “13X.XXX.2.1”) 4401 and SF (IP Address “13X.XXX.2.246”) is connected to port 2 of 4402, and port 1 of R (IP address “13X.XXX.2.1”) 4401 has an arbitrary Term1 (IP address “13X.XXX. 1.1 ") 4403 is connected.
[0075]
FIG. 45 shows an example of entries in the PF table 1124 used for connection detection of the R-SF model of the present embodiment, and exemplifies entries in the PF table 1124 for the R-SF model shown in FIG.
The entry 4501 stores connection information from R (IP address “13X.XXX.2.1”) 4401 to SF (IP address “13X.XXX.2.246”) 4402. From this connection information, it is possible to detect that the connection port from R4401 to SF4402 is port 2.
In addition, in the entry 4502, connection information of a device connected to another segment from SF (IP address “13X.XXX.2.246”) (device “Term1” (“13X” which is not a network device of “13X.XXX.2. *”). .XXX.1.1 ") 4403 is stored. With this connection information, it is possible to detect that the connection port from SF 4402 to R 4401 is port 2.
Even when there is no connection information from R (IP address “13X.XXX.2.1”) 4401 to SF (IP address “13X.XXX.2.246”) 4402, R (IP address “13X.XXX.2.1”) If connection information of 4401 and an arbitrary device on the “13X.XXX.2. *” Network exists, that port becomes a connection port from R4401 to SF4402.
In this way, in the R-SF model, it is possible to detect the connection port and the parent-child relationship of the device under the condition that the connection information of the device connected to another segment can be acquired.
[0076]
46 and 47 are diagrams for explaining a method for detecting connection between network relay devices according to this embodiment.
46 and 47 summarize the detection conditions of the connection relations and the parent-child relations between the network relay apparatuses shown in FIGS. 22 to 45 in a table format.
Detection conditions are set for each of the connection models 4601 and 4701, and the detection possibility of the parent-to-child connection ports 4602 and 4702, the child-to-parent connection ports 4603 and 4703, and the parent-child relationships 4604 and 4704 is shown. .
The item with “◯” indicates that detection is possible regardless of the conditions 4605 and 4705 for detecting connection, and the item with “△” indicates that the condition for detecting connection is satisfied. This indicates that detection is possible, and an item marked with “x” indicates that detection is impossible under any conditions.
[0077]
FIG. 48 is a diagram showing a mechanism for detecting the connection of the CF-Term model of this embodiment. As an example of the CF-Term model, port 3 of CF (IP address “13X.XXX.2.246”) 4801 and Term1 ( The IP address “13X.XXX.2.102”) 4802 has a connection relationship.
[0078]
FIG. 49 is a diagram showing an example of entries in the PF table 1124 used for detecting the connection of the CF-Term model of this embodiment, and exemplifies entries in the PF table for the CF-Term model shown in FIG.
In an entry 4901, connection information from CF (IP address “13X.XXX.2.246”) 4801 to Term1 (IP address “13X.XXX.2.102”) 4802 is stored. From this connection information, it can be detected that the connection port from CF 4801 to Term 14802 is port 3.
In this case, even when an arbitrary number of devices are connected to the port 3 of the CF 4801, connection information for the number of devices is stored in the PF table 1124, so that an arbitrary number of terms can be detected. It is.
In this way, in the CF-Term model, it is possible to detect the connection port and the parent-child relationship of the device under arbitrary conditions.
FIG. 50 is a diagram showing the connection detection mechanism of the IF-Term model of this embodiment. As an example of the IF-Term model, port 3 of IF (IP address “13X.XXX.2.246”) 5001 and Term1 ( The IP address “13X.XXX.2.102”) 5002 has a connection relationship.
[0079]
FIG. 51 is a diagram illustrating an example of entries in the PF table 1124 used for connection detection of the IF-Term model according to the present embodiment, and illustrates the entries in the PF table 1124 for the IF-Term model illustrated in FIG. .
The entry 5101 stores connection information from the IF (IP address “13X.XXX.2.246”) 5001 to Term1 (IP address “13X.XXX.2.102”) 5002. From this connection information, it is possible to detect that the connection port from IF 5001 to Term 15002 is port 3.
In this case, even when an arbitrary number of devices are connected to the port 3 of the IF 5001, connection information for the number of devices is stored in the PF table 1124, so an arbitrary number of terms can be detected. It is.
In this way, in the IF-Term model, it is possible to detect a connection port and a parent-child relationship of a device under an arbitrary condition.
[0080]
FIG. 52 is a diagram showing a mechanism for detecting connection of the SF-Term model of this embodiment. As an example of the SF-Term model, port 3 of SF (IP address “13X.XXX.2.246”) 5201 and Term 1 (IP The address “13X.XXX.2.102”) 5202 has a connection relationship.
FIG. 53 is a diagram showing an example of entries in the PF table 1124 used for connection detection of the IF-Term model of this embodiment, and exemplifies entries in the PF table 1124 for the SF-Term model shown in FIG.
An entry 5301 stores connection information from SF (IP address “13X.XXX.2.246”) 5201 to Term1 (IP address “13X.XXX.2.102”) 5202. From this connection information, it can be detected that the connection port from SF to Term1 is port 3.
In this case, when multiple devices are connected to the end of port 3 of SF5201, connection information for one device is stored in the PF table 1124, so that any one term can be detected. It is.
In this way, in the SF-Term model, it is possible to detect the connection port and the parent-child relationship of a device under the condition that one device is connected to each port of the network relay device.
[0081]
FIG. 54 is a diagram for explaining a connection detection method between a network relay device and a terminal device in the network configuration automatic recognition method of this embodiment. FIG. 54 summarizes the detection conditions of the connection relationship and the parent-child relationship between the network relay device and the terminal device shown in FIGS. 48 to 53 in a table format.
Each connection model 5401 shows the possibility of the connection detection 5302 of the terminal device, and the connection detection possibility changes depending on the condition 5403 for detecting the connection.
Items marked with “○” indicate that detection is possible regardless of the conditions for detecting connection, and items marked with “△” can be detected only when the conditions for detecting connection are satisfied. It is shown that.
[0082]
FIG. 55 is a diagram for explaining detection of a parent-child relationship by combining a plurality of models of this embodiment. FIG. 55 shows an example in which the parent-child relationship of the R-SF-CF model is detected by combining the R-CF-CF model and the R-CF-SF model.
Here, there is a connection relationship between port 2 of R (IP address “13X.XXX.2.1”) 5501 and port 2 of CF1 (IP address “13X.XXX.2.246”) 5502, and CF1 (IP address “13X.XXX”). XXX.2.246 ") 5502 port 1 and SF (IP address" 13X.XXX.2.243 ") 5503 have a connection relationship with SF (IP address" 13X.XXX.2.243 ") 5503 port 2 and CF2 (IP address “13X.XXX.2.247”) is connected to port 2 of 5504, and any term 1 (IP address “13X.13”) is connected to port 3 of CF1 (IP address “13X.XXX.2.246”) 5502. XXX.2.102 ") 5505 is connected, and any Term2 (IP address" 13X.XXX.2.2 ") 5506 is connected to the port 1 of CF2 (IP address" 13X.XXX.2.247 ") 5504 Shows the case.
[0083]
FIG. 56 is a diagram showing entries in the TS table 1125 used for detecting a parent-child relationship by combining a plurality of models of the present embodiment. The R-CF-CF model and the R-CF-SF shown in FIG. The entry for detecting the R-SF-CF model from the model is illustrated.
In the R-CF-SF model, since the parent-child relationship can be detected under the condition where both CF and SF hold the connection information to Term1, CF1 (IP address “13X.XXX.2.246”) 5502 The TS table 1125 stores an entry 5601 indicating that it is the parent of SF (IP address “13X.XXX.2.243”) 5503.
In the R-CF-CF model, since the parent-child relationship can be detected under arbitrary conditions, CF1 (IP address “13X.XXX.2.246”) 5502 is CF2 (IP address “13X.XXX.2.247”). ) An entry 5602 indicating the parent of 5504 is stored in the TS table 1125. Since the parent-child relationship cannot be detected in the R-SF-CF model, the parent-child relationship between SF (IP address “13X.XXX.2.243”) 5503 and CF2 (IP address “13X.XXX.2.247”) 5504 Is unknown.
[0084]
Therefore, in FIG. 56, as an example showing a case where the connection relationship (connection port) can be detected but the parent-child relationship cannot be detected, CF2 (IP address “13X.XXX.2.247”) 5504 is SF (IP An entry 5603 indicating that it is the parent of the address “13X.XXX.2.243”) 5503 and SF (IP address “13X.XXX.2.243”) 5503 are the parents of CF2 (IP address “13X.XXX.2.247”) 5504. An entry 5604 indicating that it exists is stored at the same time. Since the connection port from SF5503 to CF15502 is different from the connection port from SF5503 to CF25504, it can be detected that SF5503 is connected between CF1552 and CF25504. Since CF15502 is the parent of SF5503, it can be detected that SF5503 is the parent of CF25504.
In this way, the R-SF-CF model cannot detect parent-child relationships, but by combining parent-child relationships that can be detected from the R-CF-CF model and R-CF-SF model, Can be detected.
[0085]
FIG. 57 is a diagram illustrating a method for predicting the connection of the Non Intelligent Hub according to the present embodiment. Here, as an example of predicting the connection of the Non Intelligent Hub, a unit (IP address “13X.XXX.2.246”) 5701 is used. There is a connection relationship between port 1 and port 1 of NF (no IP address) 5702, and any term 1 (IP address "13X.XXX.2.98") 5703 is connected to the end of port 2 of NF (no IP address) 5702 In this example, an arbitrary term 2 (IP address “13X.XXX.2.13”) 5704 is connected to the end of port 3 of NF (no IP address) 5702.
[0086]
FIG. 58 is a diagram illustrating an example of entries in the TS table 1125 used for prediction of connection of the Non Intelligent Hub according to the present embodiment, and illustrates entries of the TS table 1125 for prediction of connection of the Non Intelligent Hub illustrated in FIG. are doing.
The entry 5801 stores connection information indicating that Term1 (IP address “13X.XXX.2.98”) 5703 is connected as a child beyond the port 1 of Unit (IP address “13X.XXX.2.246”) 5701. Has been.
[0087]
Similarly, an entry 5802 indicates that Term2 (IP address “13X.XXX.2.13”) 5704 is connected as a child ahead of port 1 of Unit (IP address “13X.XXX.2.246”) 5701. Stores connection information.
As a result, when a plurality of devices are connected as a child to a common port of the network relay device, and there is no other network relay device, it can be detected that at least one Non Intelligent Hub is connected. . A plurality of devices are connected as a child to a common port of the network relay device, and even if another network relay device exists, a plurality of devices are connected between the connection ports of the network relay device and the network relay device. If the connected device does not include a network relay device, it can be detected that at least one Non Intelligent Hub is connected.
[0088]
FIG. 59 is a diagram for explaining a detection method of a non-operating terminal device according to this embodiment. Port 2 of R (IP address “13X.XXX.2.1”) 5901 and Unit (IP address “13X.XXX.2.243”) ) There is a connection relationship with port 2 of 5902, and an arbitrary term (IP address “13X.XXX.2.2”) 5903 is connected to the end of port 1 of Unit (IP address (“13X.XXX.2.243”) 5902 first. However, Term 5903 shows a case of a non-operating terminal device.
In the example of FIG. 59, as an example of detecting the connection relationship and the parent-child relationship of the non-operating terminal device 5903, when an IP address in the network is polled and there is an IP address device that does not respond to polling, Assume that no device corresponding to the IP address exists or is not operating, and an entry with an alive value of FALSE in the TI table 1123 (FIG. 14) is added. Next, referring to the router's ARP cache, if an entry for an IP address that does not return a response to polling is included in the ARP cache, the device corresponding to that IP address is detected as being inactive. . Further, when the connection information of the non-operating terminal device is included in the MIB object used for detecting the connection relationship between the network relay devices and the parent-child relationship, the non-operating terminal device is included in the PF table 1124 and the TS table 1125. Thus, it is possible to detect the connection relationship and the parent-child relationship of the non-operating terminal device.
[0089]
FIG. 60 is a diagram for explaining a connection destination change detection method according to the present embodiment. An arbitrary term (IP address “13X.XXX” is added to the end of port 2 of Unit (IP address “13X.XXX.2.243”) 6001. .2.2 ") 6002 is connected, but the connection destination is changed to port 3 of Unit6001.
[0090]
FIG. 61 is a diagram showing an example of an entry in the TS table 1125 used for detecting the change of the connection destination according to this embodiment, and illustrates the entry for the detection of the change of the connection destination shown in FIG.
In the entry 6101 of the TS table 1125 before changing the connection destination, the terminal (IP address “13X.XXX.2.2”) 6002 is a child of the port 2 of the Unit (IP address “13X.XXX.2.243”) 6001. Connection information indicating that the connection is established is stored. In the entry in the TS table after changing the connection destination, Term (IP address "13X.XXX.2.2") 6002 is connected as a child to the end of port 2 of Unit (IP address "13X.XXX.2.243") 6001. There is an entry 6103 in which Term (IP address “13X.XXX.2.2”) 6002 is connected as a child to port 6 of entry 6102 and Unit (IP address “13X.XXX.2.243”) 6001. In the TS table 1125 before changing the connection destination and the TS table 1125 after changing the connection destination, the information on the connection destination of the device is also changed. Therefore, the TS table 1125 is periodically created and the difference is taken to establish the connection. The previous change can be detected.
Further, there is no problem even when the MIB object remains in the cache of old connection information as in the entry 6102. Further, when the IP address of the device is changed, it can be detected in the form that a device with the IP address is newly added on the network.
[0091]
FIG. 62 is a diagram showing a display example of a network configuration drawing created by the drawing display program 1104 of this embodiment.
The GUI of the drawing display program 1104 includes a Network Map display portion 6201 and a Terminal Information display portion 6202.
In the Network Map display portion 6201, the structure of the network segment automatically detected by executing the auto-discovery module is displayed in a tree structure as shown in the figure. When a cursor is used to display an arbitrary device in the Network Map display portion 6201 using a pointing device such as a mouse, the device display is highlighted as indicated by reference numeral 6203, and device information is displayed in the Terminal Information display portion 6202. Is displayed.
[0092]
The example of FIG. 62 shows an example in which information on the corresponding device in the TI table 1123 (FIG. 14) is displayed. It is also possible to display the Non Intelligent Hub 6204 predicted to be connected.
The user can recognize a non-operating terminal device by referring to the information in the Terminal Information display portion 6202. However, the GUI is used to draw the display of the corresponding device in the Network Map display portion 6201 with low luminance or lightness. Expression is also possible. The user can edit the connection destination independently by dragging and dropping each device with a porting device.
[0093]
The operation of this embodiment will be described below using a flowchart.
FIG. 63 is a flowchart showing a process in which the operating status detection module 1111 of this embodiment transmits and receives an ICMP echo request.
The operating status detection module 1111 waits for an operating status check request from the auto-discovery module 1113 (step 6301). When an IP address is received as the operating status check request (step 6302), the device specified by the IP address is pinged (ICMP). Echo request message) is transmitted (step 6303).
It is checked whether or not an ICMP echo reply message is received within the ping timeout (step 6304). If an echo reply message is received, True is returned to the auto-discovery module 1113 (step 6305), otherwise False. Is returned (step 6306).
After step 6305 or step 6306 ends, the processing is repeated from step 6301.
The operating status detection module 1111 detects the operating status of the device based on the presence or absence of a Ping response.
[0094]
FIG. 64 is a flowchart showing processing in which the MIB access module 1112 of this embodiment creates a PDU (Protocol Data Unit) and transmits / receives an SNMP message.
The MIB access module 1112 waits for an SNMP Get-Request (or Get-Next / Set-Request) PDU creation request from the auto-discovery module 1113 (step 6401), and the SNMP Get (or Get-Next / Set-Request) PDU. When the IP address, community name, and object name are received as a creation request (step 6402), the OID table 1121 shown in FIG. 12 is searched using the object name as a key (step 6403).
It is checked whether or not there is an entry whose object name item 1201 is an object name in the OID table 1121 (step 6404). If the entry is hit, the value of the object IDentifier item 1202 of the entry, the IP address, and the community name are used. An SNMP Get (or Get-Next / Set-Request) PDU is created (step 6405). If the entry does not hit, an error is returned to the auto-discovery module 1113 (step 6410).
[0095]
After step 6405 is completed, an SNMP message is created based on the PDU and transmitted (step 6406). Waiting for the reception of SNMP (Get-Response) PDU as a response to the SNMP message (step 6407). If a response is received, type conversion of the received value is performed based on the value of the type item 1203 of the entry of the OID table 1121. (Step 6408), and if reception of the response fails, an error is returned to the auto-discovery module 1113 (Step 6410).
After completion of step 6408, the value of the SNMP response subjected to the type conversion is returned to the auto-discovery module 1113 (step 6409). After step 6409 or step 6410 ends, the processing is repeated from step 6401. The process of FIG. 64 is called when the processes of FIGS. 65 to 68 are executed.
[0096]
FIG. 65A is a flowchart showing processing in which the MIB access module 1112 of this embodiment checks the MIB2 support status of a device.
In response to the MIB2 support status check request from the auto-discovery module 1113, the MIB access module 1112 specifies sysDescr as the object name, and executes the transmission / reception process of the SNMP Get-Request message in the flow shown in FIG. 64 (step 6501). . Check whether the SNMP Get-Request message transmission / reception is successful (check whether an error is returned) (step 6502). If the SNMP Get-Request message transmission / reception is successful, it is determined that the device supports MIB2. (Step 6503) If the transmission / reception of the SNMP Get-Request message fails, it is determined that the device does not support MIB2 (Step 6504), and MIB2 support status information is returned to the auto-discovery module 1113.
After step 6503 or step 6504 is completed, the processing is repeated from step 6501.
[0097]
FIG. 65B is a flowchart showing processing in which the MIB access module 1112 of this embodiment checks whether or not the device has an IP forwarding function.
In response to the IP forwarding function check request from the auto-discovery module 1113, the MIB access module 1112 designates ipForwarding as the object name, and executes the SNMP Get-Request message transmission / reception processing in the flow shown in FIG. 64 (step 6511). . Check whether the SNMP Get-Request message transmission / reception is successful (check whether an error is returned) (step 6512). If the SNMP Get-Request message transmission / reception is successful, the ipForwarding value is “1” (True). Whether or not the SNMP Get-Request message transmission / reception fails is determined (step 6515).
If the value of ipForwarding is “1” (True) after the end of Step 6513, it is determined that the device has the IP forwarding function (Step 6514), and the value of ipForwarding is “0” (False). Determines that the device does not have an IP forwarding function (step 6515). After the end of step 6514 or step 6515, information on the presence / absence of the IP forwarding function of the device is returned to the auto-discovery module 1113, and the processing from step 6511 is repeated.
[0098]
FIG. 66 is a flowchart showing processing in which the MIB access module 1112 of this embodiment checks the bridge MIB support status of a device.
In response to the bridge MIB support status check request from the auto-discovery module 1113, the MIB access module 1112 designates dot1dBaseBridgeAddress (which can be any implementation object of the bridge MIB) as the object name, and SNMP Get- Request message transmission / reception processing is executed (step 6601). Check whether the SNMP Get-Request message transmission / reception is successful (check whether an error is returned) (step 6602). If the SNMP Get-Request message transmission / reception is successful, it is determined that the device supports the bridge MIB. If the transmission / reception of the SNMP Get-Request message fails, the device determines that the bridge MIB is not supported (step 6604), and returns information on the bridge MIB support status to the auto-discovery module 1113. After step 6603 or step 6604 is completed, the processing is repeated from step 6601.
[0099]
FIG. 67 is a flowchart showing processing in which the MIB access module 1112 of this embodiment checks the repeater MIB support status of a device.
In response to the repeater MIB support status check request from the auto-discovery module 1113, the MIB access module 1112 designates rptrGroupCapacity (may be any implementation object of the repeater MIB) as an object name, and SNMP Get- Request message transmission / reception processing is executed (step 6701). Check whether the SNMP Get-Request message transmission / reception is successful (check whether an error is returned) (step 6702). If the SNMP Get-Request message transmission / reception is successful, it is determined that the device supports the repeater MIB. If the transmission / reception of the SNMP Get-Request message fails, the device determines that the repeater MIB is not supported (step 6704), and returns information about the repeater MIB support status to the auto-discovery module 1113. After the end of step 6703 or step 6704, the processing is repeated from step 6701.
[0100]
FIG. 68 is a flowchart showing processing in which the MIB access module 1112 of this embodiment checks the printer MIB support status of the device.
In response to the printer MIB support status check request from the auto-discovery module 1113, the MIB access module 1112 designates prtGeneralConfigChanges (which can be any mounting object of the printer MIB) as an object name, and SNMP Get− Request message transmission / reception processing is executed (step 6801). Check whether the SNMP Get-Request message transmission / reception is successful (check whether an error is returned) (step 6802). If the SNMP Get-Request message transmission / reception is successful, it is determined that the device supports the printer MIB. If the transmission / reception of the SNMP Get-Request message is unsuccessful (step 6803), the device determines that the printer MIB is not supported (step 6804), and returns information on the printer MIB support status to the auto-discovery module 1113. After the end of step 6803 or step 6804, the processing is repeated from step 6801.
[0101]
FIG. 69 is a flowchart showing a process of creating the AT table 1122 by the auto-discovery module 1113 of this embodiment.
The auto-discovery module 1113 waits for an AT table creation request (step 6901). When an IP address range of a network to be searched is designated as an AT table creation request (step 6902), all of the network ranges included in the designated network range are specified. IP address search is started. Whether or not there is an unsearched IP address is checked (step 6903). If there is no unsearched IP address, the processing is repeated from step 6901. If there is an unsearched IP address, an IP address is designated to specify FIG. The MIB 2 support status check process of the MIB access module 1112 shown in a) is executed (step 6904). It is checked from the return value of the MIB access module 1112 whether or not the device specified by the IP address supports MIB2 (step 6905). If MIB2 is supported, SNMP Get- shown in FIG. 64 using ipNetMediaPhysAddress as a key. Next message transmission / reception processing is executed (step 6906), and SNMP Get-Next message transmission / reception processing shown in FIG. 64 is executed using ipNetToMediaNetAddress as a key (step 6907).
[0102]
If the device does not support MIB2, the processing is repeated from step 6903. After the completion of step 6907, it is checked whether the SNMP Get-Next message transmission / reception processing in steps 6906 and 6907 has succeeded twice (step 6908). If both have succeeded, ipNetToMediaNetAddress is set in the IP Address item of the AT table 1122. And an entry in which the value of ipNetMediaPhysAddress is set in the Mac Address item is added to the AT table 1122 (step 6909). If there is a failure in the SNMP Get-Next message transmission / reception process, or after the end of step 6909, the process is repeated from step 6903.
[0103]
FIG. 70 is a flowchart showing a process of creating the TI table 1123 by the auto-discovery module 1113 of this embodiment. The auto-discovery module 1113 waits for a TI table creation request (step 7001). When a range of IP addresses of a network to be searched is designated as the TI table creation request (step 7002), all of the networks included in the designated network range are designated. IP address search is started. It is checked whether or not there is an unsearched IP address (step 7003). If there is no unsearched IP address, the processing is repeated from step 7001. Processing for acquiring the value of each item in the indicated TI table is executed (step 7004). Step 7004After completing the above, a new entry is added to the TI table 1123 (step 7005), and the processing is repeated from step 7003.
[0104]
FIG. 71 is a flowchart showing a process in which the auto-discovery module 1113 according to the present embodiment acquires the value of each item in the TI table 1123 when the TI table 1123 is created.
The auto-discovery module 1113 waits for an acquisition request for the value of each item in the TI table 1123 (step 7101), and receives an IP address to be searched as the acquisition request for the value of each item in the TI table 1123 (step 7102). The IP address of the AT table 1122 is searched for the key, and the value of the Mac Address item of the acquired entry is set in the Mac Address item of the TI table 1123 (step 7103).
Next, the host name of the device is resolved using the IP address as a key, and the host name is set in the Host Name item of the TI table 1123 (step 7104). Next, the operating status check process shown in FIG. 63 is executed using the IP address as a key (step 7105), and the return value of the operating status check process is set in the alive item of the TI table 1123. Next, the MIB2 support status check process shown in FIG. 65A is executed (step 7106), and the return value of the MIB2 support status check process is set in the MIB2 item of the TI table 1123.
[0105]
Next, the IP forwarding function check process shown in FIG. 65B is executed (step 7107), and the return value of the IP forwarding function check process is set in the forwarding item of the TI table 1123. Next, the bridge MIB support status check process shown in FIG. 66 is executed (step 7108), and the return value of the bridge MIB support status check process is set in the bridge item of the TI table 1123.
Next, the repeater MIB support status check process shown in FIG. 67 is executed (step 7109), and the return value of the repeater MIB support status check process is set in the repeater item of the TI table 1123. Next, the printer MIB support status check process shown in FIG. 68 is executed (step 7110), and the return value of the printer MIB support status check process is set in the printer item of the TI table 1123. Next, the device type recognition process shown in FIG. 72 is executed (step 7111), and the return value of the device type recognition process is set in the type item of the TI table 1123. After step 7111 ends, the processing is repeated from step 7101.
[0106]
FIG. 72 is a flowchart illustrating processing in which the auto-discovery module 1113 of this embodiment recognizes a device type when creating the TI table 1123. The auto-discovery module 1113 waits for a device type recognition request (step 7201), and receives the values of the forwarding item, bridge item, repeater item, and printer item of the corresponding entry in the TI table 1123 as a device type recognition request (step 7201). 7202) and whether the value of the forwarding item is “1” (True) or not (step 7203).
If the value of the forwarding item is “1” (True), it is checked whether the value of the bridge item is “1” (True) (Step 7204).
If the value of the forwarding item is “1” (True) and the value of the bridge item is “1” (True), the device is recognized as a router (Step 7205). If the value of the forwarding item is “1” (True) and the value of the bridge item is “0” (False), the device is recognized as a switching hub (step 7206).
If the value of the forwarding item is “0” (False) in Step 7203, it is checked whether the value of the bridge item is “1” (True) (Step 7207). If the value of the bridge item is “1” (True), it is checked whether the value of the repeater item is “1” (True) (Step 7208). If the value of the forwarding item is “0” (False), the value of the bridge item is “1” (True), and the value of the repeater item is “1” (True), the device is recognized as a switching hub (Step 7206). .
[0107]
If the value of the forwarding item is “0” (True), the value of the bridge item is “1” (True), and the value of the repeater item is “0” (False), the device is recognized as a bridge (Step 7209). If the value of the bridge item is “0” (False) in step 7207, it is checked whether the value of the repeater item is “1” (True) (step 7210). If the value of the forwarding item is “0” (False), the value of the bridge item is “0” (False), and the value of the repeater item is “1” (True), the device is recognized as an intelligent hub (step 7211).
If the value of the repeater item is “0” (False) in step 7210, it is checked whether the value of the printer item is “1” (True) (step 7212). When the forwarding item value is “0” (False), the bridge item value is “0” (False), the repeater item value is “0” (False), and the printer item value is “1” (True) The device is recognized as a printer (step 7213). When the forwarding item value is “0” (False), the bridge item value is “0” (False), the repeater item value is “0” (False), and the printer item value is “0” (False) The device is recognized as a terminal device (step 7214). After any step of Step 7205, Step 7206, Step 7209, Step 7211, Step 7213, and Step 7214 is completed, the processing is repeated from Step 7201.
[0108]
FIG. 73 is a flowchart showing a process of creating the PF table 1124 by the auto-discovery module 1113 of this embodiment.
The auto-discovery module 1113 waits for a request to create the PF table 1124 (step 7301), and when receiving the request to create the PF table 1124 (step 7302), starts searching for all entries in the TI table 1123. It is checked whether there is an unsearched entry in the TI table 1123 (step 7303). If there is no unsearched entry in the TI table 1123, the process is repeated from step 7301. If there is an unsearched entry in the TI table 1123, It is checked whether the value of the bridge item of the corresponding entry in the TI table 1123 is “1” (true) (step 7304). If the value of the bridge item is “1” (True), processing for the bridge MIB support device shown in FIG. 74 is executed (step 7305). If the value of the bridge item is “0” (False), it is checked whether the value of the repeater item of the corresponding entry in the TI table 1123 is “1” (True) (step 7306).
[0109]
If the value of the repeater item is “1” (True), the processing for the repeater MIB support device shown in FIG. 75 is executed (step 7307). If the value of the bridge item is “0” (False), it is checked whether the value of the MIB2 item of the corresponding entry in the TI table 1123 is “1” (True) (step 7308). If the value of the MIB2 item is “1” (True), the process for the interface MIB support device shown in FIG. 76 is executed (step 7309). If the value of the MIB2 item is “0” (False), the processing is repeated from step 7303. After completion of any of the steps 7305, 7307, and 7309, the processing is repeated from step 7303.
[0110]
FIG. 74 is a flowchart showing processing executed by the auto-discovery module 1113 of this embodiment on the bridge MIB support device when the PF table 1124 is created.
The auto-discovery module 1113 waits for a processing request for the bridge MIB support device (step 7401), receives the value of the IP Address item of the TI table 1123 as the processing request for the bridge MIB support device, and sets it in the Source IP Address item of the PF table 1124. If this is done (step 7402), the IP Address item of the AT table 1122 is searched using the value of the IP Address item as a key, and the value of the Mac Address item of the hit entry is set in the Source Mac Address item of the PF table 1124 (Step 7403). ). Next, it is checked whether there is unsearched forwarding information for the device specified by the IP address (processing is executed until an error occurs in SNMP Get-Next message transmission / reception) (step 7404), and there is no unsearched forwarding information. In this case, the processing is repeated from step 7401. If there is unsearched forwarding information, dot1dTpFdbAddress is specified as the object name, SNMP Get-Next message transmission / reception processing is executed in the flow shown in FIG. 64, and the return value is set in the Destination Mac Address item of the PF table 1124 ( Step 7405).
[0111]
Similarly, dot1dTpFdbPort is specified as the object name, SNMP Get-Next message transmission / reception processing is executed in the flow shown in FIG. 64, and the return value is set in the Source Port item of the PF table 1124 (step 7406). Next, the Mac Address item of the AT table 1122 is searched using the value of the set Destination Mac Address item as a key, and the value of the IP Address item of the hit entry is set in the Destination IP Address item of the PF table 1124 (step 7407). . Finally, a new entry is added to the PF table 1124 (step 7408), and the processing is repeated from step 7404.
[0112]
FIG. 75 is a flowchart showing processing executed by the auto-discovery module 1113 of the present embodiment on the repeater MIB support device when the PF table 1124 is created.
The auto-discovery module 1113 waits for a processing request for the repeater MIB support device (step 7501), receives the value of the IP Address item of the TI table 1123 as a processing request for the repeater MIB support device, and stores it in the Source IP Address item of the PF table 1124. When set (step 7502), the IP address item in the AT table 1122 is searched using the value of the IP address item as a key, and the value of the Mac Address item of the hit entry is set in the Source Mac Address item of the PF table 1124 (step) 7503).
Next, a threshold value is set in advance for the number of times of SNMP Get-Next message transmission / reception, and it is checked whether or not the number of accesses exceeds the threshold (step 7504). The forwarding information prediction process shown is executed (step 7509). If the access count does not exceed the threshold, rptrAddrTrackLastSourceAddrChanges is specified and the SNMP Get-Next message transmission / reception process shown in FIG. 64 is executed (step 7505).
[0113]
After step 7505 is completed, the value of rptrAddrTrackLastSourceAddrChanges, which is the return value of the SNMP Get-Next message transmission / reception process, is stored, and compared with the previous access value to check whether the object value has changed (step 7506). If there is no change in the value of the object, the process is temporarily stopped (Sleep process) (Step 7507), and the process is repeated from Step 7504 until the access count exceeds the threshold value. If there is a change in the object value in step 7506, a thread different from the currently executing thread is created, and the forwarding information learning process shown in FIG. 76 is started in the created thread (step 7508).
After completion of any of the steps 7508 and 7509, the processing is repeated from step 7501. The forwarding information learning process is a process of collecting information by accessing the repeater MIB at regular intervals for a device whose repeater MIB specification is compliant with RFC, and the forwarding information prediction process is a process where the repeater MIB specification is compliant with RFC. This is a process of detecting forwarding information for a device that is not using the interface MIB.
[0114]
FIG. 76 is a flowchart showing processing in which the auto-discovery module 1113 learns forwarding information when creating the PF table 1124.
The auto-discovery module 1113 waits for a forwarding information learning process request (step 7601), receives the value of the IP Address item of the TI table 1123 as a forwarding information learning process request, and sets it in the Source IP Address item of the PF table 1124 (step). 7602), it is checked whether or not the search for all the ports of the device designated by the IP address has been completed (step 7603). If all ports have been searched, the process is repeated from step 7601. If all ports have not been searched, rptrAddrTrackLastSourceAddress is designated as a key and the SNMP Get-Next message transmission / reception process shown in FIG. 64 is performed. The return value of the SNMP Get-Next message transmission / reception process is set in the Destination Mac Address item of the PF table 1124 (step 7604).
[0115]
Next, it is checked whether the value of the set Destination Mac Address item has already been detected (step 7605). If it has been detected, the processing is repeated from step 7603, and if it has not been detected, rptrAddrTrackPortIndex is designated as a key. The SNMP Get-Next message transmission / reception process shown in FIG. 64 is executed, and the return value is set in the Source Port item of the PF table 1124 (step 7606).
[0116]
Next, the Mac Address item in the AT table 1122 is searched using the value of the set Destination Mac Address item as a key, and the value of the IP Address item of the hit entry is set in the Destination IP Address item of the PF table 1124 (step 7607). . Finally, a new entry is added to the PF table 1124 (step 7608), and the processing is repeated from step 7603.
[0117]
FIG. 77 is a flowchart showing a process in which the auto-discovery module 1113 predicts forwarding information when the PF table 1124 is created. The auto-discovery module 1113 waits for a forwarding information prediction processing request (step 7701), receives the value of the IP Address item of the TI table 1123 as a forwarding information prediction processing request, and sets it in the SourceIP Address item of the PF table 1124 (step 7702). ), It is checked whether or not the search for all the ports of the device designated by the IP address has been completed (step 7703). If all port searches have been completed, the processing is repeated from step 7701. If all port searches have not been completed, rptrAddrTrackLastSourceAddress is designated as a key, as shown in FIG.S NThe MP Get-Next message transmission / reception process is executed, and the return value of the SNMPGet-Next message transmission / reception process is set in the DestinationMac Address item of the PF table 1124 (step 7704). The SNMP Get-Next message transmission / reception process shown in FIG. 64 is executed by specifying rptrAddrTrackPortIndex as a key, and the return value is set in the Source Port item of the PF table 1124 (step 7705).
[0118]
Next, the Mac Address item in the AT table is searched using the value of the set Destination Mac Address item as a key, and the value of the IP Address item of the entry that has been hit is set in the Destination IP Address item of the PF table 1124 (step 7706). Next, a new entry is added to the PF table 1124 (step 7707). After adding one entry to the PF table 1124, the RPtrAddrTrackLastSourceAddrChanges is specified as a key and the SNMP Get-Next message transmission / reception process shown in FIG. 64 is executed (step 7708). It is checked whether the value of a certain rptrAddrTrackLastSourceAddrChanges is larger than “1” (step 7709).
When the value of rptrAddrTrackLastSourceAddrChanges is larger than “1”, processing to be performed on the MIB2 (interfaces MIB) supporting device is executed to add the remaining entries to the PF table 1124 (step 7710), and the value of rptrAddrTrackLastSourceAddrChanges is “1”. "In the following cases, the processing is repeated from step 7703. Similarly, after the end of step 7710, the processing is repeated from step 7703.
[0119]
FIG. 78 is a flowchart showing processing executed by the auto-discovery module 1113 for a MIB2 (interfaces MIB) support device when the PF table 1124 is created.
The auto-discovery module 1113 waits for a processing request to be executed with respect to the MIB2 (interfaces MIB) supporting device (step 7801), and receives the value of the IP Address item of the TI table 1123 as a processing request to be executed with respect to the MIB2 supporting device. When the Source IP Address item of the PF table 1124 is set (step 7802), the connection port detection process of the administrator terminal shown in FIG. 79 is executed (step 7803).
Next, a connection port detection process for devices other than the administrator terminal shown in FIG. 80 is executed (step 7804). Finally, a new entry is added to the PF table 1124 (step 7805), and the processing is repeated from step 7801.
[0120]
FIG. 79 is a flowchart showing a process in which the auto-discovery module 1113 detects the connection port of the administrator terminal 71 when the PF table 1124 is created. The auto-discovery module 1113 waits for a request for detecting the connection port of the administrator terminal 71 (step 7901), and receives the IP address value of the network relay device using the connection port of the administrator terminal 71 as a detection processing request (step 7902). Then, it is checked whether or not the search for all the ports of the network relay device designated by the IP address has been completed (step 7903). If all ports have been searched, a port number whose array alive [port number] is “0” (False) is returned (step 7906). If the search for all the ports has not been completed, specify ifAdminStatus as the key, specify the value as "0" (False), execute the SNMP Set-Request message transmission / reception process shown in Fig. 64, and use the SNMP management protocol. The corresponding port is closed (step 7904). The network relay device specified by the IP address is specified, and the ICMP echo request transmission / reception process shown in FIG. 63 is executed. If "is set and the return value is" 0 "(False), the alive [port number] variable" 0 "Is set (step 7905). However, the initial value of alive [port number] is “0” (False). After the end of step 7905, the processing is repeated from step 7903. After step 7906 ends, the process is repeated from step 7901. When a port other than the port to which the administrator terminal 71 is connected is blocked, the ICMP echo request transmission / reception process from the administrator terminal 71 to the network relay device is successful, but the port to which the administrator terminal 71 is connected is blocked. In this case, the fact that the response of the ICMP echo request transmission / reception process from the administrator terminal 71 to the network relay device is not returned is used.
[0121]
FIG. 80 is a flowchart showing processing in which the auto-discovery module 1113 detects a connection port of a device other than the administrator terminal when the PF table 1124 is created.
The auto-discovery module 1113 waits for a connection port detection processing request for a device other than the administrator terminal 71 (step 8001), and the IP address value of the network relay device and the administrator as a connection port detection processing request for a device other than the administrator terminal 71. When the port number on the network relay device to which the terminal 71 is connected is received (step 8002), the search of the TI table 1123 is started to check whether there is an unsearched device (step 8003). If there is an unsearched device, the value of the alive item of the entry in the TI table 1123 is set in the pre_alive variable (step 8004). If there is no unsearched device, the processing is repeated from step 8001.
[0122]
After step 8004 is completed, it is checked whether the search for all ports of the network relay device designated by the IP address has been completed (step 8005). If all ports have been searched, it is checked whether there is a port number in which the pre_alive variable is “1” (True) and alive [port number] is “0” (False) (step 8008). If all ports have not been searched, the SNMP Set-Request message transmission / reception process shown in FIG. 64 is executed using ifAdminStatus as the key and the value set to “0” (False), and the SNMP management protocol is used. If the corresponding port is blocked (step 8006), the network relay device specified by the IP address is specified, and the ICMP echo request transmission / reception process shown in FIG. 63 is executed, and the return value is “1” (True) Sets "1" in the alive [port number] variable, and sets "0" in the alive [port number] variable when the return value is "0" (False) (step 8007). However, the initial value of alive [port number] is “0” (False).
[0123]
After step 8007 ends, the process is repeated from step 8005. If no port satisfying the condition is found after step 8008, the connection port number of the administrator terminal 71 is returned (step 8009). If a port satisfying the condition is found, the alive [port number] variable is “0”. The port number that becomes (False) is returned (step 8010). After completion of arbitrary steps of Step 8009 and Step 8010, the processing is repeated from Step 8001.
When a specific port of the network relay device is blocked and an ICMP echo request response to an arbitrary device cannot be received, the corresponding port becomes a connection port.
[0124]
FIG. 81 is a flowchart showing a process in which the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a request to create the PF table 1124 (step 8101), and when receiving the request to create the PF table 1124 (step 8102), executes the root device determination process shown in FIG. 82 and sets the IP address of the root device. It is set in the Root variable, and all items of the Units list variable are deleted and initialized (step 8103).
Next, the process for determining the connection between the network relay devices shown in FIG. 83 is executed (step 8104). Next, the process for determining the connection between the network relay device and the terminal device shown in FIG. 114 is executed (step 8105). Finally, the interface MIB evaluation process shown in FIG. 115 is executed (step 8106), and the process from step 8101 is repeated.
[0125]
FIG. 82 is a flowchart showing a process in which the auto-discovery module 1113 determines a root device when the TS table 1125 is created.
The auto-discovery module 1113 waits for a root device determination processing request (step 8201), and when receiving the root device determination processing request (step 8202), starts searching for the TI table 1123 and checks whether there is an unsearched device (step). 8203). If there is no unsearched device, the process is repeated from step 8201. If there is an unsearched device, it is checked whether the value of the type item of the corresponding entry in the TI table 1123 is R (identifier indicating Router) (step 8204). If the value of the type item is other than R, step The process is repeated from 8203. If the value of the type item is R, the IP address of the router is added to the root variable (step 8205). Finally, a root entry addition process is executed for the TS table 1125 shown in FIG. 103 (step 8206). After step 8206 is completed, the processing is repeated from step 8201.
[0126]
FIG. 83 is a flowchart illustrating processing in which the auto-discovery module 1113 determines a connection between network relay devices when the TS table 1125 is created.
The auto-discovery module 1113 waits for a determination processing request for connection between network relay devices (step 8301), and when receiving a determination processing request for connection between network relay devices (step 8302), all entries in the PF table 1124 are entered in the Units list variable. Among all the values of the Source IP Address item, all values except the same as the Root variable are added (step 8303).
Next, a set of arbitrary two element combinations is selected from the elements of the Units list variable, and it is checked whether there is an unsearched combination (set to Unit1 variable and Unit2 variable) (step 8304). If there is an unsearched combination, the connection model determination process shown in FIG. 84 is executed (step 8305), and the entry addition process for the TS table 1125 shown in FIG. 102 is executed (step 8306). repeat. In the connection model determination process, the connection models related to Unit1 and Unit2 are determined in the format shown in FIGS. In the process of adding entries to the TS table 1125, the entries are stored in the TS table 1125 in a format determined for each determined connection model.
If there is no unsearched combination in step 8304, the parent-child relationship determination process shown in FIG. 107 is executed (step 8307), and the process from step 8301 is repeated. In the parent-child relationship determination process, only the entries of devices having a parent-child relationship are extracted from the TS table 1125 and the final form of the TS table 1123 is determined.
[0127]
FIG. 84 is a flowchart showing connection model determination processing when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a connection model determination processing request (step 8401), and receives the connection model determination processing request (step 8402). When the connection model determination processing request is received (step 8402), the network device related to the device whose IP address is equal to the Unit1 variable is A classification process is executed (step 8403). Similarly, a network device classification process for a device whose IP address is equal to the Unit2 variable is executed by the method shown in FIG. 85 (step 8404). In the network device classification process, the classification shown in FIG. 21 is determined. Finally, after executing the connection detection condition check process (step 8405), the process is repeated from step 8401. In the connection detection condition check process, the connection detection condition check shown in FIG. 46 is executed.
[0128]
FIG. 85 is a flowchart showing network device classification processing when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a network device classification processing request (step 8501). When the network device classification processing request is received (step 8502), the value of the Source IP Address item among all entries in the PF table 1124 is Unit1. Alternatively, an entry that is equal to Unit2 and whose Destination IP Address item value is equal to the Root variable value is searched (step 8503).
It is checked whether the searched entry exists (step 8504). If there is an entry searched in step 8504, all network relay device entries included in the Units list variable are set as target variables in order, and it is checked whether the target variable is an unsearched one (step 8505).
[0129]
If the entry searched in step 8504 does not exist, SF is set in the Category1 variable if the value of the Source IP Address item is equal to Unit1 in Step 8503, and if the value of the Source IP Address item is equal to Unit2 in Step 8503 Set SF to Category2 variable. If the Target variable has not been searched in Step 8505, an entry is searched from all entries in the PF table 1124 for which the value of the Source IP Address item is Unit1 or Unit2 and the value of the Destination IP Address item is equal to the Target variable (Step 8506). ). If there is no unsearched Target variable in step 8505, the processing is repeated from step 8501. Next, it is checked whether or not there is a search item in step 8506 (step 8507). If there is a search item in step 8507, if the value of the Source IP Address item is equal to Unit1 in Step 8503, CF is set in the Category1 variable. If the value of the Source IP Address item is equal to Unit2 in Step 8503, the Category2 variable is set. Set CF to. If there is no search item in step 8507, if the value of the Source IP Address item is equal to Unit1 in step 8503, the value is set in the Category1 variable.I FIf the value of the Source IP Address item is equal to Unit2 in Step 8503, set it to the Category2 variable.I FSet(Step 8509). CF is set when there is connection information for all devices included in the Units list variable, and IF is set when connection information is not included even for one unit.
[0130]
FIG. 86 is a flowchart showing connection detection condition check processing when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a connection detection condition check processing request (step 8601), and as a connection detection condition check processing request, the Unit1 variable, the Unit2 variable, and the two network devices that store the IP addresses of two network devices. When the Category1 variable and the Category2 variable storing the classification are received (step 8602), it is checked whether the Category1 variable is equal to CF and the Category2 variable is equal to CF (step 8603).
If the Category1 variable is equal to CF and the Category2 variable is equal to CF in step 8603, the connection (R, CF, CF) connection detection condition check process shown in FIG. 87 is executed (step 8604), and the process is repeated from step 8601.
In step 8602, if the condition that the Category1 variable is equal to CF and the Category2 variable is equal to CF is not satisfied, the Category1 variable is equal to CF and the Category2 variable is equal to IF, or the Category1 variable is equal to IF, and the Category2 variable is equal to It is checked whether it is equal to CF (step 8605). In step 8605, if the Category1 variable is equal to CF and the Category2 variable is equal to IF, or the Category1 variable is equal to IF and the Category2 variable is equal to CF, the connection detection condition of the set (R, CF, IF) shown in FIG. Check processing is executed (step 8606), and the processing is repeated from step 8601.
[0131]
In step 8605, if the condition that the Category1 variable is equal to CF and the Category2 variable is equal to IF, or the Category1 variable is equal to IF and the Category2 variable is equal to CF is not satisfied, the Category1 variable is equal to CF, and the Category2 variable is It is checked whether it is equal to SF, or the Category1 variable is equal to SF and the Category2 variable is equal to CF (step 8607). In step 8607, if the Category1 variable is equal to CF and the Category2 variable is equal to SF, or if the Category1 variable is equal to SF and the Category2 variable is equal to CF, the connection detection condition of the set (R, CF, SF) shown in FIG. Check processing is executed (step 8608), and the processing is repeated from step 8601.
In step 8607, if the condition that the Category1 variable is equal to CF and the Category2 variable is equal to SF, or the Category1 variable is equal to SF and the Category2 variable is equal to CF is not satisfied, the Category1 variable is equal to IF, and the Category2 variable is It is checked whether it is equal to IF (step 8609). If the Category1 variable is equal to IF and the Category2 variable is equal to IF in step 8609, the connection detection condition check process for the set (R, IF, IF) shown in FIG. 94 is executed (step 8610), and the process is repeated from step 8601. If the condition that the Category1 variable is equal to IF and the Category2 variable is equal to IF is not satisfied in step 8609, the Category1 variable is equal to IF, the Category2 variable is equal to SF, or the Category1 variable is equal to SF, and the Category2 variable is It is checked whether it is equal to IF (step 8611).
[0132]
When the Category1 variable is equal to IF and the Category2 variable is equal to SF in Step 8611, or the Category1 variable is equal to SF and the Category2 variable is equal to IF, the connection detection condition of the set (R, IF, SF) shown in FIG. Check processing is executed (step 8612), and the processing is repeated from step 8601.
In step 8611, if the Category1 variable is equal to IF and the Category2 variable is equal to SF, or the Category1 variable is equal to SF and the Category2 variable is equal to IF, the Category1 variable is equal to SF, and the Category2 variable is It is checked whether it is equal to SF (step 8613). If the Category1 variable is equal to SF and the Category2 variable is equal to SF in step 8613, the connection detection condition check process for the set (R, SF, SF) shown in FIG. 101 is executed (step 8614), and the process is repeated from step 8601. If the condition that the Category 1 variable is equal to SF and the Category 2 variable is equal to SF is not satisfied in step 8613, the processing is repeated from step 8601.
[0133]
FIG. 87 is a flowchart showing the connection condition check processing for the set (R, CF, CF) when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a connection condition check processing request for the set (R, CF, CF) (step 8701), and upon receiving the connection condition check processing request for the set (R, CF, CF) (step 8702), the PF table. From all entries of 1124, search for an entry whose Source IP Address item value is the CF1 variable (equal to the Unit1 variable) and Destination IP Address item value is the same as the Root variable. Set to the CF1R variable (step 8703).
Similarly, an entry in which all of the entries in the PF table 1124 have a Source IP Address item value equal to a CF2 variable (equal to a Unit2 variable) and a Destination IP Address item value equal to a Root variable is searched. The value of the Source Port item is set in the CF2R variable (step 8704).
Also, from all the entries in the PF table 1124, search for an entry in which the value of the Source IP Address item is equal to the CF1 variable (equal to the Unit1 variable) and the value of the Destination IP Address item is equal to the CF2 variable (equal to the Unit2 variable) The value of the Source Port item of the corresponding entry is set in the CF1CF2 variable (step 8705).
[0134]
Similarly, from all entries of the PF table 1124, search for an entry in which the value of the Source IP Address item is equal to the CF2 variable (equal to the Unit2 variable) and the value of the Destination IP Address item is equal to the CF1 variable (equal to the Unit1 variable). Then, the value of the Source Port item of the corresponding entry is set in the CF2CF1 variable (step 8706). The value of the CF1R variable is compared with the value of the CF1CF2 (step 8707), and it is checked from the CF1 whether R and CF2 are connected to different ports (it is possible to compare the CF2R variable and the CF2CF1 variable).
If the value of CF1R variable is equal to the value of CF1CF2 in step 8707, the value of CF2 variable is set to Paddr variable, the value of CF1 variable is set to Caddr variable, the value of CF2CF1 variable is set to Pport variable, the value of CF1CF2 variable is set to Cport variable, the model variable R-CF-CF is set in (Step 8708), and the processing is repeated from Step 8701.
If the value of CF1R variable is not equal to the value of CF1CF2 in step 8707, the value of CF1 variable for Paddr variable, the value of CF2 variable for Caddr variable, the value of CF1CF2 variable for Pport variable, the value of CF2CF1 variable for Cport variable, Model R-CF-CF is set as a variable (step 8709), and the processing is repeated from step 8701. Since there is no connection detection condition in the R-CF-CF model of FIG. 46, FIG. 87 detects the connection relation by the method shown in FIG.
[0135]
FIG. 88 is a flowchart showing connection condition check processing for a set (R, CF, IF) when the TS table 1125 is created by the auto-discovery module 1113.
The auto-discovery module 1113 waits for the connection condition check processing request for the set (R, CF, IF) (step 8801), and receives the connection condition check processing request for the set (R, CF, IF) (step 8802). From all the entries of 1124, search for an entry in which the value of the Source IP Address item is a CF variable (a device recognized as CF in the Unit1 variable and Unit2 variable) and the value of the Destination IP Address item is equal to the Root variable, The value of the Source Port item of the corresponding entry is set in the CFR variable (step 8803).
Similarly, the value of the Source IP Address item among all entries of the PF table 1124 is the CF variable (the device recognized as CF among the Unit1 variable and Unit2 variable), and the value of the Destination IP Address item is the IF variable ( An entry equal to the device recognized as IF in the Unit1 variable and Unit2 variable is searched, and the value of the Source Port item of the corresponding entry is set in the CFIF variable (step 8804). The value of the CFR variable is compared with the CFIF value (step 8805), and it is checked whether R and IF are connected to different ports as seen from the CF. If the value of the CFR variable is equal to the value of CFIF in step 8805, the value of the IF variable is set in the Paddr variable, the value of the CF variable is set in the Caddr variable, and R-IF-CF is set in the Model variable. The IF-CF model connection detection condition check process is executed (step 8806), and the process is repeated from step 8801.
If the value of the CFR variable is not equal to the value of CFIF in step 8805, the value of the CF variable is set to the Paddr variable, the value of the IF variable is set to the Caddr variable, and R-CF-IF is set to the Model variable. -CF-IF model connection detection condition check processing is executed (step 8807), and the processing is repeated from step 8801.
[0136]
FIG. 89 is a flowchart showing the connection condition check process of the R-IF-CF model when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for an R-IF-CF model connection condition check processing request (step 8901), and receives an R-IF-CF model connection condition check processing request (step 8902). Among the entries, the value of the Source IP Address item is a CF variable (the device recognized as CF in Figure 88 within the Unit1 variable and Unit2 variable), and the value of the Destination IP Address item is the IF variable (Unit1 variable and Unit2 variable In FIG. 88, an entry equal to the device recognized as IF in FIG. 88 is searched, and the value of the Source Port item of the corresponding entry is set in the CFIF variable (step 8903).
[0137]
Similarly, among all entries in the PF table 1124, the value of the Source IP Address item is a CF variable (a device recognized as CF among the Unit1 variable and Unit2 variable), and the value of the Source Port item is different from the CFIF variable. The entry is searched, and the value of the Destination IP Address item of the corresponding entry is set in the Target variable (step 8904). All the Target variables in Step 8904 are acquired in order, and it is checked whether the value of the Target variable is not equal to the null value (Step 8905).
If the Target variable is not equal to the NULL value in step 8905, the value of the Source IP Address item is recognized as IF variable (in the Unit1 variable and Unit2 variable, as IF in FIG. 88) among all entries of the PF table 1124. Device), the value of the Destination IP Address item is equal to the Target variable, and the value of the Source Port item of the corresponding entry is set to the IFT variable (step 8906).
If the Target variable is equal to the null value in step 8905, the null value is set in the Pport variable and the null value is set in the Cport variable (step 8909), and the process is repeated from step 8901.
[0138]
In step 8906, it is checked whether the corresponding entry exists and the value of the IFT variable is not equal to NULL (step 8907). If the value of the IFT variable is not equal to NULL in step 8907, the value of the IFT variable is set in the Pport variable. The value of the CFIF variable is set in the Cport variable (step 8908), and the process is repeated from step 8901.
If it is determined in step 8907 that the value of the IFT variable is equal to NULL, the process is repeated from step 8904. Based on the connection detection conditions shown in the R-IF-CF model of FIGS. 46 and 47, the connection relation is detected by the method shown in FIG. 28 in the flow of FIG.
[0139]
FIG. 90 is a flowchart showing the connection condition check processing of the R-CF-IF model when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for an R-CF-IF model connection condition check processing request (step 9001), and receives an R-CF-IF model connection condition check processing request (step 9002). Among the entries, the value of the Source IP Address item is a CF variable (the device recognized as CF in Figure 88 within the Unit1 variable and Unit2 variable), and the value of the Destination IP Address item is the IF variable (Unit1 variable and Unit2 variable In FIG. 88, an entry equal to the device recognized as IF in FIG. 88 is searched, and the value of the Source Port item of the corresponding entry is set in the CFIF variable (step 9003).
[0140]
Similarly, out of all entries in the PF table 1124, the value of the Source IP Address item is an IF variable (a device recognized as IF in the Unit1 variable and Unit2 variable), and the value of the Destination IP Address item is a Root variable. An equal entry is searched, and the value of the Source Port item of the corresponding entry is set in the IFR variable (step 9004).
Finally, the value of the CFIF variable is set in the Pport variable and the value of the IFR variable is set in the Cport variable (step 9005), and the process is repeated from step 9001. In the R-CF-IF model of FIGS. 46 and 47, since there is no connection detection condition, the connection relationship is detected by the method shown in FIG. 24 in the flow of FIG.
[0141]
FIG. 91 is a flowchart showing connection condition check processing for a set (R, CF, SF) when the TS table 1125 is created by the auto-discovery module 1113.
The auto-discovery module 1113 waits for the connection condition check processing request for the set (R, CF, SF) (step 9101), and receives the connection condition check processing request for the set (R, CF, SF) (step 9102). From all the entries of 1124, search for an entry in which the value of the Source IP Address item is a CF variable (a device recognized as CF in the Unit1 variable and Unit2 variable) and the value of the Destination IP Address item is equal to the Root variable, The value of the Source Port item of the corresponding entry is set in the CFR variable (step 9103).
[0142]
Similarly, among all entries of the PF table 1124, the value of the Source IP Address item is a CF variable (a device recognized as CF among the Unit1 variable and Unit2 variable), and the value of the Destination IP Address item is an SF variable ( An entry equal to the device recognized as SF in the Unit1 variable and Unit2 variable) is searched, and the value of the Source Port item of the corresponding entry is set in the CFSF variable (step 9104). The value of the CFR variable is compared with the CFSF value (step 9105), and it is checked whether R and SF are connected to different ports as seen from the CF.
If the value of the CFR variable is equal to the value of CFSF in step 9105, the value of the SF variable is set in the Paddr variable, the value of the CF variable is set in the Caddr variable, and R-SF-CF is set in the Model variable. The SF-CF model connection detection condition check process is executed (step 9106), and the process is repeated from step 9101.
If the value of the CFR variable and the value of CFSF are not equal in step 9105, the value of the CF variable is set in the Paddr variable, the value of the SF variable is set in the Caddr variable, and R-CF-SF is set in the Model variable. -CF-SF model connection detection condition check processing is executed (step 9107), and the processing is repeated from step 9101.
[0143]
FIG. 92 is a flowchart showing the connection condition check processing of the R-SF-CF model when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for an R-SF-CF model connection condition check processing request (step 9201), and receives an R-SF-CF model connection condition check processing request (step 9202). Among the entries, the value of the Source IP Address item is a CF variable (the device recognized as CF in Fig. 91 in the Unit1 variable and Unit2 variable), and the value of the Destination IP Address item is an SF variable (Unit1 variable and Unit2 variable). , The entry equal to the device recognized as SF in FIG. 91 is searched, and the value of the Source Port item of the corresponding entry is set in the CFSF variable (step 9203).
[0144]
Similarly, the value of the Source IP Address item among all entries in the PF table 1124 is a CF variable (a device recognized as CF among the Unit1 variable and Unit2 variable), and the value of the Source Port item is different from the CFSF variable. The entry is searched, and the value of the Destination IP Address item of the corresponding entry is set in the Target variable (step 9204).
All the Target variables in Step 9204 are obtained in order, and it is checked whether the value of the Target variable is not equal to the null value (Step 9205). If the Target variable is not equal to the null value in step 9205, the value of the Source IP Address item among all entries in the PF table 1124 is recognized as SF variable (of the Unit1 variable and Unit2 variable, it is recognized as SF in FIG. 91). And the value of the Source Port item of the corresponding entry is set in the SFT variable (step 9206).
[0145]
If the Target variable is equal to the null value in step 9205, a null value is set in the Pport variable and a null value is set in the Cport variable (step 9209), and the process is repeated from step 9201. In step 9206, it is checked whether the corresponding entry exists and the value of the SFT variable is not equal to NULL (step 9207). If the value of the SFT variable is not equal to NULL in step 9207, the value of the SFT variable is set in the Pport variable, The CFSF variable value is set in the Cport variable (step 9208), and the process is repeated from step 9201.
If the value of the SFT variable is equal to NULL in step 9207, the process is repeated from step 9204. Based on the connection detection condition shown in the R-SF-CF model of FIGS. 46 and 47, in FIG. 92, the connection relation is detected by the method shown in FIG.
[0146]
FIG. 93 is a flowchart showing the connection condition check processing of the R-CF-SF model when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for an R-CF-SF model connection condition check processing request (step 9301), and receives an R-CF-SF model connection condition check processing request (step 9302). Among the entries, the value of the Source IP Address item is a CF variable (the device recognized as CF in Fig. 91 in the Unit1 variable and Unit2 variable), and the value of the Destination IP Address item is an SF variable (Unit1 variable and Unit2 variable). , The entry equivalent to the device recognized as SF in FIG. 91 is searched, and the value of the Source Port item of the corresponding entry is set in the CFSF variable (step 9303).
[0147]
Similarly, the value of the Source IP Address item among all entries in the PF table 1124 is a CF variable (a device recognized as CF among the Unit1 variable and Unit2 variable), and the value of the Source Port item is different from the CFSF variable. The entry is searched, and the value of the Destination IP Address item of the corresponding entry is set in the Target variable (step 9304).
All the Target variables in Step 9304 are acquired in order, and it is checked whether the value of the Target variable is not equal to the null value (Step 9305). If the Target variable is not equal to the NULL value in step 9305, the value of the Source IP Address item among all the entries in the PF table 1124 is recognized as SF variable (in the Unit1 variable and Unit2 variable, it is recognized as SF in FIG. 91). And the value of the Source Port item of the corresponding entry is set in the SFT variable (step 9306).
[0148]
If the Target variable is equal to the null value in step 9305, the null value is set in the Pport variable and the null value is set in the Cport variable (step 9309), and the process is repeated from step 9301. In step 9306, it is checked whether the corresponding entry exists and the value of the SFT variable is not equal to NULL (step 9307). If the value of the SFT variable is not equal to NULL in step 9307, the value of the CFSF variable is added to the Pport variable, The value of the SFT variable is set in the Cport variable (step 9308), and the process is repeated from step 9301.
If the value of the SFT variable is equal to NULL in step 9307, the process is repeated from step 9304. Based on the connection detection conditions shown in the R-CF-SF model of FIGS. 46 and 47, in FIG. 93, the connection relation is detected by the method shown in FIG.
[0149]
FIG. 94 is a flowchart showing connection condition check processing for a set (R, IF, IF) when the TS table 1125 is created by the auto-discovery module 1113.
The auto-discovery module 1113 waits for a connection condition check processing request for the set (R, IF, IF) (step 9401), and receives the connection condition check processing request for the set (R, IF, IF) (step 9402). From all the entries of 1124, search for an entry whose Source IP Address item value is an IF1 variable (either one of Unit1 variable or Unit2 variable) and the Destination IP Address item value is equal to the Root variable. The value of the Source Port item is set in the IF1R variable (step 9403).
[0150]
Similarly, out of all entries in the PF table 1124, the value of the Source IP Address item is an IF2 variable (unit1 variable or a device different from IF1 in the Unit2 variable), and the value of the Destination IP Address item is equal to the Root variable. The entry is searched, and the value of the Source Port item of the corresponding entry is set in the IF2R variable (step 9404).
Next, R-IF-IF model connection detection condition check processing shown in FIG. 95 is executed (step 9405), and a connection port is determined (IF1IF2 (IF2IF1)).
It is checked whether the condition that the value of the IF1IF2 variable is not equal to NULL and the condition that the value of the IF2IF1 variable is not equal to NULL are satisfied at the same time (step 9406), and it is checked whether the connection port of IF1 and IF2 has been found. If the value of the IF1IF2 variable is not equal to NULL in step 9406 and the value of the IF2IF1 variable is not equal to NULL, the value of the IF1 variable is set to the Paddr variable, the value of the IF2 variable is set to the Caddr variable, the value of IF1IF2 is set to the Pport variable, Cport The value of IF2R (IF2IF1) is set in the variable, and R-IF-IF is set in the Model variable (step 9407), and the processing is repeated from step 9401.
[0151]
If the value of the IF1IF2 variable is equal to NULL in step 9406, or the value of the IF2IF1 variable is equal to NULL, the IF1R variable value and the IF2R variable value, and the IF1 variable value and the IF2 variable value are switched, as shown in FIG. The R-IF-IF model connection detection condition check process is executed (step 9408), and the connection port is determined (IF1IF2 (IF2IF1)). It is checked whether the condition that the value of the IF1IF2 variable is not equal to NULL and the condition that the value of the IF2IF1 variable is not equal to NULL are satisfied at the same time (step 9409, whether the connection port of IF1 and IF2 has been found. If the value of the variable is not equal to NULL and the value of the IF2IF1 variable is not equal to NULL, the value of the IF1 variable for the Paddr variable, the value of the IF2 variable for the Caddr variable, the value of IF1IF2 for the Pport variable, and IF2R ( IF-IF-IF is set to the value of IF2IF1) and the Model variable (step 9410), and the processing is repeated from step 9401. However, the values of the IF1 variable and IF2 variable set in step 9410 are the IF1 variable and IF2 set in step 9407. If the value of the IF1IF2 variable is equal to NULL or the value of the IF2IF1 variable is equal to NULL in step 9409, the process is repeated from step 9401.
[0152]
FIG. 95 is a flowchart showing the connection condition check processing of the R-IF-IF model when the TS table 1125 is created by the auto-discovery module 1113.
The auto-discovery module 1113 waits for a connection condition check processing request for the R-IF-IF model (step 9501), and receives the connection condition check processing request for the R-IF-IF model (step 9502). Among the entries, the value of the Source IP Address item is the IF1 variable (the device recognized as IF1 in FIG. 94 among the Unit1 variable and Unit2 variable), and the value of the Source Port item is the IF1R variable (from IF1 to Root in FIG. 94) The entry that is not equal to the connection port) is searched, and the value of the Destination IP Address item of the corresponding entry is set in the Target1 variable (step 9503).
All the Target1 variables in step 9503 are obtained in order, and it is checked whether the value of the Target1 variable is not equal to the null value (step 9504). If the Target1 variable is not equal to the NULL value in step 9504, the value of the Source IP Address item among all the entries in the PF table 1124 is recognized as the IF2 variable (in the Unit1 variable and Unit2 variable, it is recognized as IF2 in FIG. 94). Search for an entry whose value of the Destination IP Address item is equal to the Target1 variable, and sets the value of the Source Port item of the corresponding entry to the IF2T1 variable (step 9505).
[0153]
If the Target1 variable is equal to the null value in step 9504, the null value is set in the IF1IF2 variable and the null value is set in the IF2IF1 variable (step 9512), and the process is repeated from step 9501.
[0154]
In step 9505, it is checked whether the corresponding entry exists and the condition that the value of the IF2T1 variable is not equal to NULL and the condition that the value of the IF2T1 variable is equal to the value of the IF2R variable are simultaneously satisfied (step 9506), and in step 9506, IF2T1 If the value of the variable is not equal to NULL and the value of the IF2T1 variable is equal to the value of the IF2R variable, the value of the Source IP Address item among all the entries in the PF table 1124 is the IF2 variable (Unit1 variable and Unit2 variable 94, search for an entry whose Source Port item value is not equal to the IF2R variable (the connection port from IF2 to Root in FIG. 94) in the device recognized as IF2 in FIG. 94, and the Destination IP Address item of the corresponding entry Is set to the Target2 variable (step 9507).
If the value of the IF2T1 variable is equal to NULL in step 9506, or the value of the IF2T1 variable is not equal to the value of the IF2R variable, the processing is repeated from step 9503. All the Target2 variables in step 9507 are acquired in order, and it is checked whether the value of the Target2 variable is not equal to the null value (step 9508).
[0155]
If the Target2 variable is not equal to the NULL value in step 9508, the value of the Source IP Address item among all the entries in the PF table 1124 is recognized as IF1 variable (in the Unit1 variable and Unit2 variable, it is recognized as IF1 in FIG. 94). Device), the value of the Destination IP Address item is equal to the Target2 variable, and the value of the Source Port item of the corresponding entry is set to the IF1T2 variable (step 9509).
If it is determined in step 9508 that the Target2 variable is equal to the null value, the process repeats from step 9503. In step 9509, it is checked whether a corresponding entry exists and the condition that the value of the IF1T2 variable is not equal to NULL and the condition that the value of the IF1T2 variable is not equal to the value of the IF1R variable are simultaneously satisfied (step 9510). If the value of the IF1T2 variable is not equal to NULL and the value of the IF1T2 variable is not equal to the value of the IF1R variable, the value of the IF1T2 variable is set to the IF1IF2 variable, and the value of the IF2T1 variable is set to the IF2IF1 variable (step 9511). Repeat from 9501. If it is determined in step 9510 that the value of the IF1T2 variable is equal to NULL, or the value of the IF1T2 variable is equal to the value of the IF2R variable, the processing is repeated from step 9507.
Based on the connection detection conditions shown in the R-IF-IF model of FIGS. 46 and 47, the connection relationship is detected in FIG. 95 by the method shown in FIG.
[0156]
FIG. 96 is a flowchart showing connection condition check processing for the set (R, IF, SF) when the TS table 1125 is created by the auto-discovery module 1113.
The auto-discovery module 1113 waits for a connection condition check processing request for the set (R, IF, SF) (step 9601), and when receiving a connection condition check processing request for the set (R, IF, SF) (step 9602), the PF table. From all the entries of 1124, search for an entry in which the value of the Source IP Address item is an IF variable (a device recognized as IF in the Unit1 variable and Unit2 variable) and the value of the Destination IP Address item is equal to the Root variable, The value of the Source Port item of the corresponding entry is set in the IFR variable (step 9603).
[0157]
The R-SF-IF model connection detection condition check process shown in FIG. 97 is executed (step 9604), and it is checked whether the value of the Paddr variable set in step 9604 is equal to the null value (step 9605). If the value of the Paddr variable is equal to the NULL value in step 9605, the R-IF-SF model connection detection condition check process shown in FIG. 99 is executed (step 9606), and the process is repeated from step 9601. If the value of the Paddr variable is not equal to the null value in step 9605, the process repeats from step 9601.
[0158]
97 and 98 are flowcharts showing the connection condition check process of the R-SF-IF model when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a connection condition check processing request for the R-SF-IF model (step 9701), and receives the connection condition check processing request for the R-SF-IF model (step 9702). Search for entries in which the value of the Source IP Address item is the IF variable (the device recognized as IF in FIG. 96 among the Unit1 and Unit2 variables) and the value of the Destination IP Address item is equal to the Root variable. The value of the Source Port item of the corresponding entry is set in the IFR variable (step 9703).
[0159]
Similarly, the value of the Source IP Address item among all the entries in the PF table 1124 is the IF variable (the device recognized as IF in FIG. 96 among the Unit1 variable and Unit2 variable), and the value of the Source Port item is Two entries equal to the IFR variable are searched, and the values of the Destination IP Address item of the corresponding entry are set in the Target1 variable, Target2 variable, and the Source Port item in the IFT1 variable and IFT2 variable, respectively (step 9704).
[0160]
All combinations of Target1 variable and Target2 variable in step 9704 are acquired in order, and it is checked whether the value of Target1 variable is not equal to the null value and the value of Target2 variable is not equal to the null value (step 9705). When the condition of step 9705 is satisfied, the value of the Source IP Address item among all the entries of the PF table 1124 is the Destination in the SF variable (the device recognized as SF in FIG. 96 among the Unit1 variable and the Unit2 variable). Search for an entry in which the value of the IP Address item is equal to the Target1 variable, and set the value of the Source Port item of the corresponding entry to the SFT1 variable.
Similarly, the value of the Source IP Address item among all the entries in the PF table 1124 is the SF variable (the device recognized as SF in FIG. 96 among the Unit1 variable and Unit2 variable), and the value of the Destination IP Address item is The entry equal to the Target2 variable is searched, and the value of the Source Port item of the corresponding entry is set in the SFT2 variable (step 9706).
If the condition of step 9705 is not satisfied, a NULL value is set for the Paddr variable, a NULL value for the Caddr variable, a NULL value for the Pport variable, a NULL value for the Cport variable, and an R-SF-IF for the Model variable (step 9713) Repeat from step 9701.
[0161]
In step 9706, it is checked whether the corresponding entry exists, the value of the SFT1 variable is not equal to NULL, the value of the SFT2 variable is not equal to NULL, and the value of the SFT1 variable is not equal to the value of the SFT2 variable (step 9707). ), If the condition of step 9707 is satisfied, the value of the Source IP Address item is an IF variable (a device recognized as IF in FIG. 96 among the Unit1 variable and Unit2 variable) among all entries of the PF table 1124. Searches for an entry whose Source Port item value is not equal to the IFR variable (the connection port from IF to Root in Fig. 96), is not equal to the IFT1 variable, and is not equal to the IFT2 variable, and the Destination IP Address item of the corresponding entry Is set to Target3 variable, and Source Port item value is set to IFT3 (step 9708).
[0162]
If the condition of step 9707 is not satisfied, the process is repeated from step 9704.
All the Target3 variables in Step 9708 are acquired in order, and it is checked whether the value of the Target3 variable is not equal to the null value (Step 9709). If the Target3 variable is not equal to the NULL value in step 9709, the value of the Source IP Address item among all the entries in the PF table 1124 is recognized as SF variable (in the Unit1 variable and Unit2 variable, it is recognized as SF in FIG. 96). Search for an entry whose value of the Destination IP Address item is equal to the Target3 variable, and sets the value of the Source Port item of the corresponding entry to the SFT3 variable (step 9710).
[0163]
If it is determined in step 9709 that the Target3 variable is equal to the null value, the process repeats from step 9704. In step 9710, it is checked whether the corresponding entry exists (step 9711). If the condition of step 9711 is satisfied, the value of SF variable is set to Paddr variable, the value of IF variable is set to Caddr variable, the value of SFT3 variable is set to Pport variable, The value of the IFR variable (the value of the IFT1 variable, the value of the IFT2 variable) and Model = R-SF-IF are set in the Cport variable (step 9712), and the processing is repeated from step 9701.
If the condition of step 9711 is not satisfied, the process is repeated from step 9708. Based on the connection detection condition shown in the R-SF-IF model of FIGS. 46 and 47, the connection relation is detected by the method shown in FIG. 36 in FIGS.
[0164]
99 and 100 are flowcharts showing the connection condition check processing of the R-IF-SF model when the TS table 1125 is created by the auto-discovery module 1113. FIG.
The auto-discovery module 1113 waits for a connection condition check processing request for the R-IF-SF model (step 9901). When the auto discovery module 1113 receives the connection condition check processing request for the R-IF-SF model (step 9902), all of the PF table 1124 Search for entries in which the value of the Source IP Address item is the IF variable (the device recognized as IF in FIG. 96 among the Unit1 and Unit2 variables) and the value of the Destination IP Address item is equal to the Root variable. The value of the Source Port item of the corresponding entry is set in the IFR variable (step 9903).
[0165]
Similarly, the value of the Source IP Address item in all entries of the PF table 1124 is the IF variable (the device recognized as IF in FIG. 96 among the Unit1 variable and Unit2 variable), and the value of the Source Port item is Two entries that are not equal to the IFR variable are searched, and the value of the Destination IP Address item of the corresponding entry is set to the Target1 variable, the Target2 variable, and the value of the Source Port item to the IFT1 variable and IFT2 variable, respectively (step 9904).
[0166]
All combinations of Target1 variable and Target2 variable in step 9904 are acquired in order, and it is checked whether the value of Target1 variable is not equal to the null value and the value of Target2 variable is not equal to the null value (step 9905).
When the condition of step 9905 is satisfied, the value of the Source IP Address item among all the entries of the PF table 1124 is the Destination in the SF variable (the device recognized as SF in FIG. 96 among the Unit1 variable and the Unit2 variable). Search for an entry in which the value of the IP Address item is equal to the Target1 variable, and set the value of the Source Port item of the corresponding entry to the SFT1 variable.
[0167]
Similarly, the value of the Source IP Address item among all the entries of the PF table 1124 is the SF variable (the device recognized as SF in FIG. 96 among the Unit1 variable and Unit2 variable), and the value of the Destination IP Address item is The entry equal to the Target2 variable is searched, and the value of the Source Port item of the corresponding entry is set in the SFT2 variable (step 9906).
[0168]
If the condition in step 9905 is not satisfied, a NULL value is set in the Paddr variable, a NULL value is set in the Caddr variable, a NULL value is set in the Pport variable, a NULL value is set in the Cport variable, and R-IF-SF is set in the Model variable (step 9913). Repeat from step 9901.
It is checked in step 9906 whether the corresponding entry exists, the value of the SFT1 variable is not equal to NULL, the value of the SFT2 variable is not equal to NULL, and the value of the SFT1 variable is equal to the value of the SFT2 variable (step 9907). If the condition of step 9907 is satisfied, the value of the Source IP Address item is an IF variable (the device recognized as IF in FIG. 96 among the Unit1 variable and Unit2 variable) among all entries of the PF table 1124. A search is made for an entry whose Source Port item value is not equal to the IFR variable (the connection port from IF to Root in FIG. 96), not equal to the IFT1 variable, and not equal to the IFT2 variable, and the Destination IP Address item of the corresponding entry is searched. The value is set to the Target3 variable, and the value of the Source Port item is set to IFT3 (step 9908). If the condition of step 9907 is not satisfied, the process is repeated from step 9804.
[0169]
All the Target3 variables in step 9908 are acquired in order, and it is checked whether the value of the Target3 variable is not equal to the null value (step 9909). If the Target3 variable is not equal to the null value in step 9909, the value of the Source IP Address item among all the entries in the PF table 1124 is recognized as SF variable (in the Unit1 variable and Unit2 variable, it is recognized as SF in FIG. 96). Search for an entry whose value of the Destination IP Address item is equal to the Target3 variable, and sets the value of the Source Port item of the corresponding entry to the SFT3 variable (step 9910). If it is determined in step 9909 that the Target3 variable is equal to the null value, the processing is repeated from step 9904.
[0170]
In step 9910, the corresponding entry exists, the SFT3 variable value is not equal to NULL, the SFT3 variable value is not equal to the SFT1 variable value, and the SFT3 variable value is not equal to the SFT2 variable value. (Step 9911) If the conditions of Step 9911 are satisfied, the IFr value is the Paddr variable, the SF variable value is the Caddr variable, the IFT1 variable value (IFT1 variable value, IFT2 variable value), Cport The value of the SFT3 variable, Model = R-IF-SF, is set as the variable (step 9912), and the process is repeated from step 9901.
If the condition of step 9911 is not satisfied, the process is repeated from step 9908. Based on the connection detection condition shown in the R-IF-SF model of FIGS. 46 and 47, the connection relation is detected in the method shown in FIG. 32 in FIGS.
[0171]
FIG. 101 is a flowchart showing the connection condition check processing for the set (R, SF, SF) when the TS table 1125 is created by the auto-discovery module 1113. The auto-discovery module 1113 waits for the connection condition check processing request for the set (R, SF, SF) (step 10101), and receives the connection condition check processing request for the set (R, SF, SF) (step 10102), the Paddr variable Set NULL value to Caddr variable, NULL value to Pport variable, NULL value to Cport variable, Model = R-SF-SF (Step 11003), Step 1010Repeat from 1. In the R-SF-SF model shown in FIGS. 46 and 47, connection detection is impossible under arbitrary conditions. Therefore, in FIG. 101, the connection relationship detection is stopped as shown in FIG.
[0172]
FIG. 102 is a flowchart showing entry addition processing to the TS table when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for an entry addition processing request for the TS table 1125 (step 10201), and when receiving an entry addition processing request for the TS table (step 10202), the Paddr variable is equal to the NULL value and the Caddr variable is set to the NULL value. It is checked whether the Pport variable is equal to the null value and the Cport variable is equal to the null value (step 10203). If the condition of step 10203 is satisfied, the network relay with unknown parent-child relationship and connection relationship shown in FIG. The device entry addition processing is executed (step 10204), and the processing is repeated from step 10201.
[0173]
If the condition of step 10203 is not satisfied, it is checked whether the Model variable is equal to R-SF-CF or R-SF-IF (step 10205). If the condition of step 10205 is satisfied, the parent and child shown in FIG. An entry addition process is executed for the network relay device whose relationship is unknown (step 10206), and the process is repeated from step 10201.
If the condition of step 10205 is not satisfied, the entry addition processing of the network relay device with the obvious parent-child relationship and connection relationship shown in FIG. 106 is executed (step 10207), and the processing is repeated from step 10201.
[0174]
FIG. 103 is a flowchart showing root entry addition processing for the TS table 1125 when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a Root entry addition processing request for the TS table 1125 (step 10301). When receiving the Root entry addition processing request for the TS table 1125 (step 10302), the IP address of the Root variable using the AT table 1122 To resolve the Mac address and set it in the Rphysaddr variable (step 10303). Finally, in the TS table 1125, the Terminal IP Address item is the value of the Root variable, the Terminal Mac Address item is the value of the Rphysaddr variable, the Terminal Port item is the NULL value, the ParentTIP Address item is the NULL value, the Parent Mac Address item is the NULL value, An entry having a NULL value in the Parent Port item is added (step 10304), and the processing is repeated from step 10301.
[0175]
FIG. 104 is a flowchart showing entry addition processing of a network relay device whose parent-child relationship and connection relationship are unknown when the TS table 1125 is created by the auto-discovery module 1113.
The auto-discovery module 1113 waits for an entry addition processing request for a network relay device with an unknown parent-child relationship and connection relationship (step 10401), and receives an entry addition processing request for a network relay device with an unknown parent-child relationship and connection relationship (step 10402). ), The Mac address is resolved from the IP addresses of the Unit1 variable and the Unit2 variable (Unit1 variable and Unit2 variable in FIG. 83 (FIG. 102)) using the AT table 1122, and set to the U1physaddr variable and the U2physaddr variable, respectively (step 10403). ). Finally, in TS table 1125, Terminal IP Address item is the value of Unit1 variable, Terminal Mac Address item is the value of U1physaddr variable, Terminal Port item is NULL value, Parent IP Address item is NULL value, Parent Mac Address item is NULL value , An entry with a NULL value in the Parent Port item is added (Step 10404), the Terminal IP Address item is the value of the Unit2 variable, the Terminal Mac Address item is the value of the U2physaddr variable, the Terminal Port item is the NULL value, and the Parent IP Address item is NULL An entry is added in which the value and the Parent Mac Address item are NULL values and the Parent Port item is NULL values (Step 10405), and the processing is repeated from Step 10401.
[0176]
FIG. 105 is a flowchart showing entry addition processing of a network relay device in which only the parent-child relationship at the time of creation of the TS table 1125 by the auto-discovery module 1113 is unknown.
The auto-discovery module 1113 waits for an entry addition processing request for a network relay device whose parent-child relationship is unknown (step 10501), and receives an entry addition processing request for a network relay device whose parent-child relationship is unknown (step 10502). The Mac address is resolved from the IP address of the Paddr variable and the Caddr variable (FIG. 87 to FIG. 100 Paddr variable, Caddr variable) using 1122 and set to the Pphysaddr variable and Cphysaddr variable, respectively (step 10503).
Finally, in the TS table 1125, the Terminal IP Address item is the value of the Paddr variable, the Terminal Mac Address item is the value of the Pphysaddr variable, the Terminal Port item is the value of the Pport variable, the Parent IP Address item is the value of the Caddr variable, and the Parent Mac Address item Is an entry for the value of the Cphysaddr variable, the Parent Port item is the value of the Cport variable (Step 10504), the Terminal IP Address item is the value of the Caddr variable, the Terminal Mac Address item is the value of the Cphysaddr variable, and the Terminal Port item is the Cport variable , The Parent Tip Address item is the Paddr variable value, the Parent Mac Address item is the Pphysaddr variable value, and the Parent Port item is the Pport variable value entry (Step 10505).
[0177]
FIG. 106 is a flowchart showing entry addition processing of a network relay device with a clear parent-child relationship and connection relationship when the TS table 1125 is created by the auto-discovery module 1113.
The auto-discovery module 1113 waits for an entry addition processing request for a network relay device with an obvious parent-child relationship and connection relationship (step 10601), and receives an entry addition processing request for a network relay device with an obvious parent-child relationship and connection relationship (step 10602). ) Using the AT table 1122, the Mac address is resolved from the IP address of the Paddr variable and the Caddr variable (Paddr variable, Caddr variable in FIGS. 87 to 100), and set to the Pphysaddr variable and the Cphysaddr variable, respectively (step 10603). .
Finally, in the TS table 1125, the Terminal IP Address item is the value of the Caddr variable, the Terminal Mac Address item is the value of the Cphysaddr variable, the Terminal Port item is the value of the Cport variable, the Parent IP Address item is the value of the Paddr variable, and the Parent Mac Address item Is added to the Pphysaddr variable value and the Parent Port item is the Pport variable value entry (step 10604).
[0178]
107 and 108 are flowcharts showing parent-child relationship determination processing when the TS table 1125 is created by the auto-discovery module 1113. FIG.
The auto-discovery module 1113 waits for a parent-child relationship determination processing request (step 10701). When the parent-child relationship determination processing request is received (step 10702), the value of the Parent IP Address item among all entries in the TS table 1125 is changed. It is checked whether there are two common entries. If there are two entries, the values of the Terminal IP Address item are set in the Child1 variable, Child2 variable, and the Parent IP Address item in the Parent variable, respectively. This time, there is an entry where the value of the Parent IP Address item is equal to the value of the Child1 variable, the value of the Terminal IP Address item is equal to the value of the Parent variable, and the value of the Parent IP Address item is equal to the value of the Child2 variable, It is checked whether there is an entry in which the value of the Terminal IP Address item is equal to the value of the Parent variable (step 10703).
[0179]
If the condition of step 10703 is satisfied, of all the entries in the TS table 1125, an entry and a terminal IP address whose Terminal IP Address item value is equal to the Child1 variable value and whose Parent IP Address item value is equal to the Child2 variable. It is checked whether there are both entries in which the value of the Address item is equal to the value of the Child2 variable and the value of the Parent IP Address item is equal to the Child1 variable (step 10704).
[0180]
If the condition of step 10703 is not satisfied, the determination processing of the network relay device with an unknown connection relationship shown in FIG. 111 is executed (step 10708), and the parent-child relationship determination processing of the root and the network relay device shown in FIG. 112 is executed. (Step 10709) and Step 10701 are repeated.
If the condition of step 10704 is satisfied, a combination process of a plurality of models shown in FIG. 109 is executed (step 10705), and the process is repeated from step 10703.
If the condition of step 10704 is not satisfied, among all the entries of the TS table 1125, an entry and a terminal that have the Terminal IP Address item value equal to the value of the Child1 variable and the Parent IP Address item value equal to the Child2 variable It is checked whether only one of the entries in which the value of the IP Address item is equal to the value of the Child2 variable and the value of the Parent IP Address item is equal to the Child1 variable exists (step 10706). 110, the TS table entry combining process shown in FIG. 110 is executed (step 10707), and the processing is repeated from step 10703. If the condition of step 10706 is not satisfied, the process is repeated from step 10703.
[0181]
FIG. 109 is a flowchart showing a process of combining a plurality of models when the TS table 1125 is created by the auto-discovery module 1113.
The auto-discovery module 1113 waits for a combination processing request for a plurality of models (step 10901). Upon receiving the combination processing request for a plurality of models (step 10902), the terminal IP address item of all entries in the TS table 1125 An entry having a value equal to the Child1 variable (Child1 variable in FIG. 107) and the value of the Parent IP Address item equal to the Parent variable (Parent variable in FIG. 107) is searched, and the value of the Terminal Port item of the corresponding entry is set to the C1Pport variable. And the value of the Parent Port item is set in the PC1port variable (step 10903).
[0182]
Similarly, among all entries in the TS table 1125, the value of the Terminal IP Address item is equal to the Child2 variable (Child2 variable in FIG. 107), and the value of the Parent IP Address item is the Parent variable (Parent variable in FIG. 107). ), The value of the Terminal Port item of the corresponding entry is set in the C2Pport variable, and the value of the Parent Port item is set in the PC2port variable (step 10904).
[0183]
Similarly, in all entries of the TS table 1125, the value of the Terminal IP Address item is equal to the Child1 variable (Child1 variable in FIG. 107), and the value of the Parent IP Address item is the Child2 variable (Child2 variable in FIG. 107). ), The value of the Terminal Port item of the corresponding entry is set in the C1C2port variable, and the value of the Parent Port item is set in the C2C1port variable (step 10905).
Next, it is checked whether the value of the C1Pport variable is equal to the value of the C1C2port variable (it is also possible to compare the value of the C2Pport variable and the C2C1port variable) (step 10906), and the parent and child2 are connected to the same port as viewed from Child1 Check if you are doing.
If the condition of step 10906 is satisfied, an entry is deleted from the TS table 1125 where Terminal IP Address is equal to the value of the Child2 variable and the value of the Parent IP Address item is equal to the value of the Child1 variable (step 10907). .
[0184]
If the condition of step 10906 is not satisfied, an entry is deleted from the TS table 1125 where Terminal IP Address is equal to the value of the Child1 variable and the value of the Parent IP Address item is equal to the value of the Child2 variable (step 10908). repeat.
In the flow of FIG. 106, the parent-child relationship of the entry whose parent-child relationship is unknown is detected by the method shown in FIG. 55 (unnecessary entries are deleted from the two entries storing Child1 and Child2).
[0185]
FIG. 110 is a flowchart showing the TS table 1125 joining process when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a TS table join processing request (step 11001). When the TS table join process request is received (step 11002), the value of the Terminal IP Address item among all entries in the TS table 1125 is changed. It is checked whether there is an entry equal to the Child1 variable (Child1 variable in FIG. 107) and the value of the ParentIP Address item is equal to the Child2 variable (Child2 variable in FIG. 107) (step 11003). Deletes an entry from the TS table 1125 whose Terminal IP Address is equal to the value of the Child1 variable and whose Parent IP Address item is equal to the value of the Parent variable (Parent variable in FIG. 107) (Step 11004), and repeats from Step 11001. .
[0186]
If the condition of step 11003 is not satisfied, an entry is deleted from the TS table 1125 where Terminal IP Address is equal to the value of the Child2 variable and the value of the Parent IP Address item is equal to the value of the Parent variable (Parent variable in FIG. 107). (Step 11005) and Step 11001 are repeated.
[0187]
FIG. 111 is a flowchart showing a process for determining a network relay device whose connection relationship is unknown when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a determination processing request for a network relay device with an unknown connection relationship (step 11101), and upon receiving a determination processing request for a network relay device with an unknown connection relationship (step 11102), the Units list variable (FIG. 83). All entries in (Units list variable in FIG. 107) are obtained in order, the value of the item is set in the Unit variable, and it is checked whether there is an unsearched Unit variable (step 11103).
If there is an unsearched Unit variable in Step 11103, the TS table 1125 is searched for an entry whose Terminal IP Address item is equal to the value of the Unit variable (Step 11104).
If there is no unsearched unit variable in step 11103, the processing is repeated from step 11101. It is checked whether or not there is an entry searched in step 11104 (step 11105). If there is a corresponding entry in step 11105, it is checked whether or not only an entry whose Parent IP Address item is equal to the null value exists (step 11105). Step 11107).
[0188]
If there is no corresponding entry in step 11105, the value of the Unit variable is set in the Paddr variable and the Caddr variable, and the entry addition process of the network relay device with the obvious parent-child relationship and connection relationship shown in FIG. Step 11106) and Step 11103 are repeated.
If there is only an entry in which the Parent IP Address item is equal to the null value in step 11107, the processing is repeated from step 11103.
If only the entry whose Parent IP Address item is equal to the NULL value is included in Step 11107, the entry whose Terminal IP Address item is equal to the Unit variable is deleted from the TS table 1125 (Step 11108), and the processing is repeated from Step 11103.
[0189]
FIG. 112 is a flowchart showing parent-child relationship determination processing between the root and the network relay device when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a parent-child relationship determination processing request between the Root and the network relay device (step 11201), and when receiving a parent-child relationship determination processing request between the Root and the network relay device (step 11202), the Units list variable (FIG. 83 (FIG. 83)). 107) (Units list variable) are acquired in order, the value of the item is set in the Unit variable, and it is checked whether there is an unsearched Unit variable (step 11203).
If there is an unsearched Unit variable in Step 11203, the TS table 1125 is searched for an entry whose Terminal IP Address item is equal to the value of the Unit variable (Step 11204).
[0190]
If there is no unsearched unit variable in step 11203, the processing is repeated from step 11201. If there is a corresponding entry in step 11204, it is checked whether there is only an entry whose Parent IP Address item is equal to the null value (step 11205). If there is only an entry in which the Parent IP Address item is equal to the null value in step 11205, the root and network relay device connection port determination processing shown in FIG. 113 is executed (step 11206), and values are set in the Cport variable and the Pport variable. Set. Finally, set the value of the Unit variable in the Terminal IP Address item of the corresponding entry in the TS table 1125, the NULL value in the Parent IP Address item, the value of the Cport variable in the Terminal Port item, and the value of the Pport variable in the Parent Port item. After updating the entry, repeat from step 11203.
[0191]
FIG. 113 is a flowchart showing processing for determining the connection port between the root and the network relay device when the auto discovery module 1113 creates the TS table 1125.
[0192]
The auto-discovery module 1113 waits for a connection port determination processing request between the Root and the network relay device (step 11301), and receives a connection port determination processing request between the Root and the network relay device (step 11302). ) As an argument, the network device classification process shown in FIG. 85 is executed (step 11303), and the unit variable device classification is set in the Category variable. Next, it is checked whether the Category variable is equal to SF (step 11304). If the value of the Category variable in step 11304 is equal to SF, the Source IP Address item from the PF table 1124 is equal to the value of the Unit variable, and the Destination IP Address Network segment whose value is being searchedOutsideAn entry equal to the IP address is searched, and the value of the Source Port item of the corresponding entry is set in the Cport variable (step 11305).
[0193]
If the value of the Category variable in step 11304 is not equal to SF, an entry is searched from the PF table 1124 for the Source IP Address item equal to the Unit variable value and the Destination IP Address item value equal to the Root variable value. The value of the Source Port item of the entry to be set is set in the Cport variable (step 11306). After the steps 11305 and 11306 are completed, the Source IP Address item is equal to the value of the Root variable from the PF table 1124, and the Destination IP Address item is set to the value of the Unit variable (or an arbitrary IP address of the network segment being searched). Search for equal entries, set the value of the Source Port item of the corresponding entry to the Pport variable, and repeat from step 11301.
Based on the connection detection conditions shown in the R-CF model, the R-IF model, and the R-SF model in FIGS. 46 and 47, the connection relationship is obtained by the method shown in FIGS. 40, 42, and 44 in the flow of FIG. Is detected.
[0194]
FIG. 114 is a flowchart showing a process for determining the connection between the network relay device and the terminal device when the auto discovery module 1113 creates the TS table 1125.
The auto-discovery module 1113 waits for a request for determining the connection between the network relay device and the terminal device (step 11401), and when receiving a request for determining the connection between the network relay device and the terminal device (step 11402), the Units list variable (FIG. 83). All entries in (Units list variable in FIG. 107) are obtained in order, the value of the item is set in the Parent variable, and it is checked whether there is an unsearched Parent variable (step 11403).
If there is an unsearched Parent variable in step 11403, the TS table 1125 is searched for an entry whose Terminal IP Address item is equal to the value of the Parent variable or an entry whose Parent IP Address item is equal to the value of the Parent variable. Add all the values of the Terminal Port item of the entry corresponding to the variable (when the Terminal IP Address item is equal to the value of the Parent variable) or the value of the Parent Port item (when the Parent IP Address item is equal to the value of the Parent variable) (Step 11404).
[0195]
If there is no unsearched parent variable in step 11403, the processing is repeated from step 11401. After the end of step 11404, the PF table 1124 is searched for an entry in which the Source IP Address item is equal to the Parent variable and the Source Port item is not equal to the port number included in the Port list variable, and the Destination IP Address item of the corresponding entry is searched. The values of the Child variable and Destination Port item are set in the Cport variable (step 11405).
[0196]
Next, using the AT table 1122, the IP addresses of the Parent variable and Child variable are converted into Mac addresses and set to the Pphysaddr variable and Cphysaddr variable, respectively (step 11406), and the Terminal IP Address item in the TS table 1125 is the Child variable. Value, Terminal Mac Address item is Cphysaddr variable value, Terminal Port item is Cport variable value, ParentIP Address item is Parent variable value, Parent Mac Address item is Pphysaddr variable value, Parent Port item is Pport variable value Add an entry (if the same entry already exists, do nothing) (step 11407), and repeat from step 11403.
[0197]
FIG. 115 is a flowchart showing a process in which the auto-discovery module 1113 evaluates the interface MIB when the TS table 1125 is created.
The auto-discovery module 1113 waits for an interface MIB evaluation process request (step 11501), and receives the value of the IP address of the root device (set to the root variable) as an interface MIB evaluation process request (step 11502), the terminal port of the TS table 1125 Specify the item as a key and search for an entry whose Terminal Port item is a null value. Set the value of the Terminal IP Address item of the entry that was found to be a Terminal variable, the value of the Parent IP Address item as the parent variable, and the Parent Port item. Is set in the Pport variable (step 11503).
[0198]
Next, the IP address item of the TI table 1123 is designated as a key to search for an entry equal to the Terminal variable (step 11504), and it is checked whether the value of the MIB2 item of the hit entry is “1” (True) (step 11505). ).
If the value of the MIB2 item is “0” (False), the processing is repeated from step 11503. If the value of the MIB2 item is “1” (True), ifInOctets (ifOutOctets) is specified as the object name for the port whose IP address is the Parent variable and the port number is equal to the Pport variable, the flow shown in FIG. Executes the SNMP Get-Request message transmission / reception process, acquires the statistical distribution, and sets it in the statisticsP variable.
[0199]
Similarly, for all port numbers of devices whose IP address is a Terminal variable, ifOutOctets (ifInOctets) is specified as the object name, and SNMP Get-Request message transmission / reception processing is executed with the flow shown in FIG. Is set in the statisticsT [port number] variable (step 11506).
After the end of step 11506, it is checked whether there is a port number that does not have a significant difference between the statisticsP variable and statisticsT [port number] variable (step 11507). If there is no port number that does not have a significant difference, step 11503 is performed. Repeat the process. Here, the significant difference means that, for example, a certain threshold is provided for the difference between two values, and when the difference between the two values exceeds the threshold, it is determined that the two values are different. If there is a port number that does not have a significant difference, the corresponding port number is set in the Terminal Port item of the corresponding entry in the TS table 1125 and the entry in the TS table 1125 is updated (step 11508). After the end of step 11508, the processing is repeated from step 11503.
[0200]
FIG. 116 is a flowchart showing a process in which the drawing display program 1104 displays a network configuration drawing.
The drawing display program 1104 waits for a network configuration drawing display request (step 11601), and upon receiving the network configuration drawing display request (step 11602), executes the creation request processing of the AT table 1122 of the auto-discovery module 1113 shown in FIG. (Step 11603).
Next, the creation request processing of the TI table 1123 of the auto-discovery module 1113 shown in FIG. 70 is executed (step 11604). Next, the creation request processing of the PF table 1124 of the auto-discovery module 1113 shown in FIG. 73 is executed (step 11605).
Next, the creation request process of the TS table 1125 of the auto-discovery module 1113 shown in FIG. 81 is executed (step 11606). Finally, the drawing process shown in FIG. 117 is executed (step 11607), and the process from step 11601 is repeated.
[0201]
117 and 118 are flowcharts showing the process of drawing on the screen by the drawing display program 1104 during the network configuration drawing display process.
The drawing display program 1104 waits for a drawing process request (step 11701). When the drawing process request is received (step 11702), it starts searching for all entries in the TS table 1125 and checks whether there are unsearched entries in the TS table 1125. If there is no unsearched entry, the processing is repeated from step 11701. If there is an unsearched entry, the value of the Parent IP Address item of the entry corresponding to the Parent variable is set, and the value of the Terminal IP Address item is set to the Child variable. Setting is made (step 11703).
Next, it is checked whether or not the value of the Parent variable is equal to the NULL value (step 11704). If the value of the Parent variable is equal to the NULL value, the user is notified that the connection relation of the child variable device cannot be detected (step 11705). ), And repeats from step 11703.
[0202]
If the value of the Parent variable is not equal to the NULL value, among all the entries in the TS table 1125, there is an entry in which the value of the Parent IP Address item is equal to the Child variable and the value of the Terminal IP Address item is equal to the value of the Parent variable. Check whether it exists, and set the value of the Parent Port item in the Pport variable (step 11706).
If the corresponding entry exists, the user is notified that the parent-child relationship of the device of the Child variable cannot be detected (step 11707), and the process is repeated from step 11703. If there is no corresponding entry, the values of the Parent variable and Child variable are designated as keys, the IP Address item of the TI table 1123 is searched, and the value of the Host Name item for the parent variable of the hit entry is drawn on the screen. (Step 11708).
However, if Parent is already drawn or if the Parent variable is a null value, it is left unprocessed.
[0203]
After the end of step 11708, the non-intelligent hub prediction process shown in FIG. 119 is executed (step 11709), and it is checked whether the non-intelligent hub is operating between the Parent variable device and the Child variable device (step 11709).
If the return value of the non-intelligent hub prediction processing is “1” (True), the non-intelligent hub is drawn directly under the device of the Parent variable, and the value of the Host Name item for the child variable device of the hit entry is non-intelligent. Drawing is performed immediately below the hub (step 11710). However, if the non-intelligent hub has already been drawn directly under the Parent variable device, it is not processed.
When the return value of the non-intelligent hub prediction process is “0” (False), the value of the Host Name item for the device of the Child variable of the hit entry is drawn immediately below Parent (step 11711). After any step of Step 11710 and Step 11711 is completed, the processing is repeated from Step 11703.
The non-intelligent hub prediction process is intended to recognize that the non-intelligent hub is operating, and since the hierarchical structure and the number of stages of the non-intelligent hub cannot be predicted, the actual connection configuration is selected from the possible connection configurations. It is also possible to add a process for the user to select by, for example.
[0204]
FIG. 119 is a flowchart showing a process in which the drawing display program 1104 predicts a non-intelligent hub when drawing a network configuration drawing.
The drawing display program 1104 waits for a non-intelligent hub prediction processing request (step 11901), and as a non-intelligent hub prediction processing request, the value of the Parent IP Address item (set in the Parent variable) and the value of the Parent Port item ( (Set Pport variable) is received (step 11902), the Parent variable and the Pport variable are designated as keys, the Parent IP Address item and the Parent Port item of the TS table 1125 are searched, and it is checked whether there is a hit entry (step 11903).
If there is a hit entry, the value of the Count variable is incremented (the initial value of the Count variable is “0”) (step 11904), and the processing is repeated from step 11903.
If there is no hit entry, it is checked whether the Count variable is greater than “1” (step 11905). If the Count variable is “1” or less, False is returned (step 11906), and the Count variable is greater than “1”. In this case, True is returned (step 11907).
After completion of the arbitrary steps of Step 11906 and Step 11907, the processing is repeated from Step 11901.
The non-intelligent hub prediction process predicts that a non-intelligent hub exists when multiple devices are directly connected to the same port of a single network relay device.
[0205]
FIG. 120 is a flowchart showing processing in which the drawing display program 1104 displays device information in response to a user event.
The drawing display program 1104 waits for a device information display request (step 12001), and when the user receives a device information display request based on a user's mouse event such as clicking a device display part on the network configuration drawing using a mouse or the like ( Step 12002) After executing the GUI display such that the display part of the device on the network configuration drawing is highlighted, the corresponding host name is acquired (Step 12003).
The acquired host name is designated as a key, the Host Name item in the TI table 1123 is searched, and the value of the IP Address item of the entry is set in the ipaddress variable (step 12004). Finally, by specifying the ipaddress variable as a key, the AT table 1122, the TI table 1123, and the TS table 1125 are searched, and the acquired entry information is drawn on the device information display portion (step 12005), and the processing from step 12001 is repeated. .
[0206]
FIG. 121 is a flowchart showing processing in which the drawing display program 1104 monitors the change of the connection destination.
The drawing display program 1104 waits for a processing request for monitoring the connection destination change (step 12101), and receives the processing request for monitoring the connection destination change (step 12102), and executes the network configuration drawing display processing shown in FIG. Then, the detected network configuration is drawn (step 12103).
Next, the data of the TS table created when the network configuration is detected is stored in the TS_NEW area (step 12104).
Here, TS_NEW and TS_OLD (the initial value is a null value) are compared to check whether the number of entries has decreased (step 12105). However, if TS_OLD is equal to NULL value, it cannot be compared and ignored. When the number of entries is smaller than TS_OLD, TS_NEW notifies the user that the device has been stopped or disconnected (step 12106), and repeats from step 12101.
[0207]
If TS_NEW does not reduce the number of entries compared to TS_OLD, check whether the entries have been replaced by TS_NEW and TS_OLD (if the value of Terminal IP Address item is equal but ParentIP Address and Parent Port are different) (step 12107), If the entry is changed between TS_NEW and TS_OLD, the user is notified that the device has moved (step 12108), and the process is repeated from step 12101.
If no entry has been changed between TS_NEW and TS_OLD, TS_NEW checks whether the number of entries is greater than TS_OLD (step 12109). If the number of entries is larger than TS_OLD, TS_NEW notifies the user that a new device has been added (step 12110) and repeats from step 12101.
TS_NEW is repeated from step 12101 even when the number of entries is not increased compared to TS_OLD.
[0208]
In the embodiment of the present invention described above, an ICMP echo request is transmitted to each network device in the network node from the administrator terminal in which the SNMP manager is installed, and the network device in the active state is detected by the response, The type of the network device existing in the network node is transmitted to the detected SNMP agent of each network device by transmitting a management information-based storage information transfer request in the network device and the returned management information-based storage information. Therefore, it is not necessary to implement special software other than SNMP, and without depending on how SNMP is implemented, physical devices in the network node can be connected from at least one management terminal. It is possible to automatically detect configurations including types. That.
[0209]
Also, a set of physical addresses of network devices connected to each port of the network device is acquired from the management information base of the network device having the bridge function as a device type, and the physical information is acquired from the management information base of the network device having the routing function. Because the correspondence information between the address and the IP address is acquired, and the connection destination device of each port of the network device having the bridge function is recognized at the IP level based on the acquired correspondence information between the physical address and the IP address. The connection relationship of each port of the network device can be detected at the IP level.
[0210]
Further, it is recognized that the network device to which a response to the ICMP echo request is returned is in operation, and that there is no network device to which no response is returned, and further, the correspondence between the physical address and the IP address is referred to and is recognized as operating. When there is correspondence information other than the network device that has been changed, the network device is recognized as being inactive, so it detects not only network devices that are in operation but also temporarily stopped network devices. be able to.
[0211]
Further, the management information base of the network device having the bridge function or the repeater function is examined to determine whether or not the information of the non-operating network device existing at the connection destination of each port of the network device is stored. In this case, the connection relation of the non-operating network device is detected based on the stored information, so even if the management information base storage information of the non-operating network device cannot be obtained, the connection relation is detected. can do.
[0212]
Further, it is detected whether or not there are a plurality of network devices having a bridge function. When a plurality of network devices are detected, a network device having an arbitrary bridge function is set as a parent device, and a connection to a specific port of the parent device is performed. First, it is further detected whether or not there is a network device having another bridge function. When it is detected that the network device is present, the network device is set as a slave device, and the configuration of the connection destination of each port of the slave device Since the connection relationship between network devices having a bridge function is recognized on a port basis, the connection relationship in the parent-child relationship can be detected.
[0213]
Also, a set of physical addresses of network devices existing at the connection destination of the parent device port connected to the child device, and a connection destination of ports excluding the ports connected to the parent device from all ports of the child device Because the difference between the set of physical addresses of the network devices to be calculated is obtained and the network device existing between the parent device and the child device is recognized, the connection relationship in the parent-child relationship or sibling relationship is detected. Can do.
[0214]
Furthermore, when it is recognized that there are multiple devices between the parent device and the child device, it detects whether all devices hold the routing function, bridge function, or repeater function, and holds all of them. If not, it is predicted that there is a non-intelligent network relay device, and therefore the presence of the non-intelligent network relay device can be detected.
[0215]
Further, the physical address held in the management information base of each of the parent device and the child device that have recognized the connection relationship is checked, and the physical address of the child device is not held in the management information base of the parent device If the physical address of the parent device does not exist in the management information base of the child device and the child device, any arbitrary address that is commonly included in the set of physical addresses of devices existing at the connection destination of the specific port of the parent device and the child device Select a device and narrow down and recognize the connection relationship between the parent device and child device based on the connection port of the parent device and child device for the selected device. Can respond.
[0216]
Also, obtain the value of the update frequency of the source physical address of the latest received frame at any port of a network device that has a repeater function, and recognize the number of devices operating at the connection destination of that port by this value In addition, when the value of the update frequency is other than “0” or “1”, the value of the source physical address of the latest received frame at the arbitrary port is acquired at predetermined time intervals, and the connection of the arbitrary port is performed. Since the physical addresses of all the existing network devices are recognized, the number of network devices connected to an arbitrary port of the network device having a repeater function and the physical addresses thereof can be detected.
[0217]
Further, the network device having the repeater function is obtained by acquiring the update frequency value of the source physical address of the latest received frame at an arbitrary port of the network device having the repeater function at predetermined time intervals, and depending on whether or not this value has changed. It is possible to detect whether or not is compliant with the RFC specification.
[0218]
In addition, for a network device having a bridge function and a network device that cannot recognize a connection relationship based on the management information base storage information of the network device having a repeater function, any port of the network device having the bridge function and the network device having the repeater function If the device has a response to the ICMP echo request packet before the block and no response after the block, the device may recognize that the device exists at the connection destination of the arbitrary port. it can.
[0219]
Further, for a network device that cannot recognize a connection relationship based on management information base storage information of a network device having a bridge function and a network device having a repeater function, a port unit of the network device having the bridge function and the network device having a repeater function. If statistics of transmission / reception frames are collected at predetermined time intervals and there is a set of ports with no significant difference, this set of ports can be recognized as a port having a connection relationship.
[0220]
Also, storage information in the management information base of the network devices in operation is collected at predetermined time intervals and stored in the storage area of the administrator terminal, and whether there is a difference between the previous collection contents and the current collection contents or not. By comparison, it is possible to detect activation, stop, change of connection destination, change of IP address, and the like of an operating network device.
[0221]
Furthermore, by creating a connection relationship model between devices based on information on the connection relationship between network devices, each network device can be connected to each other by combining each device connection relationship model or a plurality of device connection relationship models. Can be detected and the detection conditions can be presented.
[0222]
In addition, although the said embodiment was comprised according to the present SNMP protocol, when updating the SNMP protocol, it cannot be overemphasized that a detailed structure can be changed and implemented.
Further, the network device is not limited to a device connected by a wired line, but may be a device connected by a wireless line.
[0223]
【The invention's effect】
As is apparent from the above description, according to the present invention, it is not necessary to install special software other than SNMP in a network environment in which an intelligent network relay device that implements SNMP is operating, and SNMP. The physical device configuration inside the network node can be automatically detected from at least one management terminal without depending on the mounting method.
[0224]
Further, the present invention is not limited to the detection of a network device existing between a bridge and a device to which the bridge is connected, and it is possible to detect the configuration of all devices in the network, the connection relationship, and the like.
[0225]
Furthermore, even when the hubs are cascade-connected or when a plurality of terminals are connected to the connection destination of the repeater, the connection relationship can be detected.
[0226]
Moreover, even if it is a non-intelligent device that does not implement the SNMP protocol, it is possible to obtain such an effect that its existence can be predicted.
[Brief description of the drawings]
FIG. 1 is a diagram showing an embodiment of a network system targeted by a network configuration automatic recognition method according to the present invention.
FIG. 2 is a diagram showing an SNMP message format used in the network configuration automatic recognition method according to the present invention.
FIG. 3 is a diagram showing an Internet OID tree used in the network configuration automatic recognition method according to the present invention.
FIG. 4 is a diagram showing a configuration of an MIB object used in the network configuration automatic recognition method according to the present invention.
FIG. 5 is a diagram showing a configuration of a system group object used in the network configuration automatic recognition method according to the present invention.
FIG. 6 is a diagram showing a configuration of an interfaces group object used in the network configuration automatic recognition method according to the present invention.
FIG. 7 is a diagram showing a configuration of an ip group object used in the network configuration automatic recognition method according to the present invention.
FIG. 8 is a diagram showing a configuration of a dot1dBridge group object used in the network configuration automatic recognition method according to the present invention.
FIG. 9 is a diagram showing a configuration of an snmpDot3RptrMgt group object used in the network configuration automatic recognition method according to the present invention.
FIG. 10 is a diagram showing a configuration of a printmib group object used in the network configuration automatic recognition method according to the present invention.
FIG. 11 is a diagram showing a program configuration example in an administrator terminal for realizing the network configuration automatic recognition method according to the present invention.
FIG. 12 is a diagram showing a configuration of an OID table used in the network configuration automatic recognition method according to the present invention.
FIG. 13 is a diagram showing a configuration of an AT table used in the network configuration automatic recognition method according to the present invention.
FIG. 14 is a diagram showing a configuration of a TI table 1123 used in the network configuration automatic recognition method according to the present invention.
FIG. 15 is a diagram showing a configuration of a PF table 1124 used in the network configuration automatic recognition method according to the present invention.
FIG. 16 is a diagram showing the structure of a TS table used in the network configuration automatic recognition method according to the present invention.
FIG. 17 is a diagram showing an SNMP message transmission / reception mechanism in the network configuration automatic recognition method according to the present invention;
FIG. 18 is a diagram for explaining a device type detection method in the network configuration automatic recognition method according to the present invention;
FIG. 19 is a diagram showing a relation definition between network relay apparatuses when considering the network configuration automatic recognition method according to the present invention.
FIG. 20 is a diagram showing a connection detection method between network relay devices using interfaces MIB in the network configuration automatic recognition method according to the present invention.
FIG. 21 is a diagram showing a network device classification method in the network configuration automatic recognition method according to the present invention;
FIG. 22 is a diagram showing an R-CF-CF model connection detection mechanism in the network configuration automatic recognition method according to the present invention.
FIG. 23 is a diagram showing an example of entries in a PF table used for connection detection of an R-CF-CF model in the network configuration automatic recognition method according to the present invention.
FIG. 24 is a diagram showing a connection detection mechanism of the R-CF-IF model in the network configuration automatic recognition method according to the present invention.
FIG. 25 is a diagram showing an example of entries in a PF table used for connection detection of the R-CF-IF model in the network configuration automatic recognition method according to the present invention.
FIG. 26 is a diagram showing a connection detection mechanism of the R-CF-SF model in the network configuration automatic recognition method according to the present invention.
FIG. 27 is a diagram showing an example of entries in a PF table used for connection detection of an R-CF-SF model in the network configuration automatic recognition method according to the present invention.
FIG. 28 is a diagram showing a connection detection mechanism of the R-IF-CF model in the network configuration automatic recognition method according to the present invention.
FIG. 29 is a diagram showing an example of entries in a PF table used for connection detection of the R-IF-CF model in the network configuration automatic recognition method according to the present invention.
FIG. 30 is a diagram showing a connection detection mechanism of the R-IF-IF model in the network configuration automatic recognition method according to the present invention.
FIG. 31 is a diagram showing an example of entries in a PF table used for connection detection of the R-IF-IF model in the network configuration automatic recognition method according to the present invention.
FIG. 32 is a diagram showing a connection detection mechanism of the R-IF-SF model in the network configuration automatic recognition method according to the present invention.
FIG. 33 is a diagram showing an example of entries in a PF table used for connection detection of the R-IF-SF model in the network configuration automatic recognition method according to the present invention.
FIG. 34 is a diagram showing a connection detection mechanism of the R-SF-CF model in the network configuration automatic recognition method according to the present invention.
FIG. 35 is a diagram showing an example of entries in a PF table used for connection detection of an R-SF-CF model in the network configuration automatic recognition method according to the present invention.
FIG. 36 is a diagram showing a connection detection mechanism of the R-SF-IF model in the network configuration automatic recognition method according to the present invention.
FIG. 37 is a diagram showing an example of entries in a PF table used for connection detection of the R-SF-IF model in the network configuration automatic recognition method according to the present invention.
FIG. 38 is a diagram showing a connection detection mechanism of the R-SF-SF model in the network configuration automatic recognition method according to the present invention.
FIG. 39 is a diagram showing an example of entries in a PF table used for connection detection of the R-SF-SF model in the network configuration automatic recognition method according to the present invention.
FIG. 40 is a diagram showing an R-CF model connection detection mechanism in the network configuration automatic recognition method according to the present invention.
FIG. 41 is a diagram showing an example of entries in a PF table used for connection detection of an R-CF model in the network configuration automatic recognition method according to the present invention.
FIG. 42 is a diagram showing an R-IF model connection detection mechanism in the network configuration automatic recognition method according to the present invention.
FIG. 43 is a diagram showing an example of entries in a PF table used for connection detection of an R-IF model in the network configuration automatic recognition method according to the present invention.
FIG. 44 is a diagram showing an R-SF model connection detection mechanism in the network configuration automatic recognition method according to the present invention;
FIG. 45 is a diagram showing an example of entries in a PF table used for connection detection of an R-SF model in the network configuration automatic recognition method according to the present invention.
FIG. 46 is a diagram for explaining a method for detecting connection between network relay devices in the network configuration automatic recognition method according to the present invention;
FIG. 47 is a diagram showing a continuation of FIG. 46;
FIG. 48 is a diagram showing a CF-Term model connection detection mechanism in the network configuration automatic recognition method according to the present invention.
FIG. 49 is a diagram showing an example of entries in a PF table used for connection detection of a CF-Term model in the network configuration automatic recognition method according to the present invention.
FIG. 50 is a diagram showing an IF-Term model connection detection mechanism in the network configuration automatic recognition method according to the present invention.
FIG. 51 is a diagram showing an example of entries in a PF table used for IF-Term model connection detection in the network configuration automatic recognition method according to the present invention.
FIG. 52 is a diagram showing a connection detection mechanism of the SF-Term model in the network configuration automatic recognition method according to the present invention.
FIG. 53 is a diagram showing an example of entries in a PF table used for connection detection of SF-Term models in the network configuration automatic recognition method according to the present invention.
FIG. 54 is a diagram for explaining a connection detection method between a network relay device and a terminal device in the network configuration automatic recognition method according to the present invention.
FIG. 55 is a diagram for explaining a parent-child relationship detection method by combining a plurality of models in the network configuration automatic recognition method according to the present invention.
FIG. 56 is a diagram showing an example of entries in a TS table used for detecting a parent-child relationship by combining a plurality of models in the network configuration automatic recognition method according to the present invention.
FIG. 57 is a diagram showing a method for predicting connection of a Non Intelligent Hub in the network configuration automatic recognition method according to the present invention.
FIG. 58 is a diagram showing an example of entries in a TS table used for prediction of Non Intelligent Hub connection in the network configuration automatic recognition method according to the present invention.
FIG. 59 is a diagram showing a detection method of a non-operating terminal device in the network configuration automatic recognition method according to the present invention.
FIG. 60 is a diagram showing a connection destination change detection method in the network configuration automatic recognition method according to the present invention;
FIG. 61 is a diagram showing an example of entries in a TS table used for detecting connection destination change in the network configuration automatic recognition method according to the present invention;
FIG. 62 is a diagram showing a network configuration drawing display example in the network configuration automatic recognition method according to the present invention.
FIG. 63 is a flowchart showing a process of transmitting and receiving an ICMP echo request by the operation status detection module in the network configuration automatic recognition method according to the present invention.
FIG. 64 is a flowchart showing a process in which the MIB access module creates a PDU and transmits / receives an SNMP message in the network configuration automatic recognition method according to the present invention.
FIG. 65 is a flowchart showing a process of checking whether or not an IP forwarding function exists in the MIB access module for checking the MIB2 support status of a device in the network configuration automatic recognition method according to the present invention.
FIG. 66 is a flowchart showing processing in which the MIB access module in the network configuration automatic recognition method according to the present invention checks the bridge MIB support status of a device.
FIG. 67 is a flowchart showing processing in which the MIB access module checks the repeater MIB support status of a device in the network configuration automatic recognition method according to the present invention.
FIG. 68 is a flowchart showing processing in which the MIB access module checks the printer MIB support status of the device in the network configuration automatic recognition method according to the present invention.
FIG. 69 is a flowchart showing a process of creating an AT table by the auto discovery module in the network configuration automatic recognition method according to the present invention.
FIG. 70 is a flowchart showing a process of creating a TI table by the auto discovery module in the network configuration automatic recognition method according to the present invention.
FIG. 71 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention acquires values of each item of the TI table when creating the TI table.
FIG. 72 is a flowchart showing a process in which the auto-discovery module recognizes a device type when creating a TI table in the network configuration automatic recognition method according to the present invention.
FIG. 73 is a flowchart showing a process of creating a PF table by the auto discovery module in the network configuration automatic recognition method according to the present invention.
FIG. 74 is a flowchart showing processing executed by the auto-discovery module for the bridge MIB support device when creating the PF table in the network configuration automatic recognition method according to the present invention.
FIG. 75 is a flowchart showing processing executed by the auto-discovery module for the repeater MIB support device when creating the PF table in the network configuration automatic recognition method according to the present invention.
FIG. 76 is a flowchart showing a process in which the auto-discovery module learns forwarding information when creating a PF table in the network configuration automatic recognition method according to the present invention.
FIG. 77 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention predicts forwarding information when creating a PF table.
FIG. 78 is a flowchart showing processing executed by the auto-discovery module for the MIB 2 (interfaces MIB) support device when creating the PF table in the network configuration automatic recognition method according to the present invention.
FIG. 79 is a flowchart showing a process of detecting a connection port of an administrator terminal when the auto discovery module in the network configuration automatic recognition method according to the present invention creates a PF table.
FIG. 80 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention detects a connection port of a device other than the administrator terminal when creating a PF table.
FIG. 81 is a flowchart showing a process of creating a TS table by the auto-discovery module in the network configuration automatic recognition method according to the present invention.
FIG. 82 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention determines a root device when creating a TS table.
FIG. 83 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention determines a connection between network relay devices when creating a TS table.
FIG. 84 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention determines a connection model when creating a TS table.
FIG. 85 is a flowchart showing a process of classifying network devices when the auto-discovery module in the network configuration automatic recognition method according to the present invention creates a TS table.
FIG. 86 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks connection detection conditions when creating a TS table.
FIG. 87 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks the connection detection conditions of a set (R, CF, CF) when creating a TS table.
FIG. 88 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks the connection (R, CF, IF) connection detection conditions when creating a TS table.
FIG. 89 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks the connection detection condition of the R-IF-CF model when creating a TS table.
FIG. 90 is a flowchart showing processing in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks connection detection conditions of the R-CF-IF model when creating a TS table.
FIG. 91 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks the connection detection conditions of a set (R, CF, SF) when creating a TS table.
FIG. 92 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks the connection detection condition of the R-SF-CF model when creating a TS table.
FIG. 93 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks the connection detection condition of the R-CF-SF model when creating a TS table.
FIG. 94 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks a connection (R, IF, IF) connection detection condition when creating a TS table.
FIG. 95 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks the connection detection condition of the R-IF-IF model when creating a TS table.
FIG. 96 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks the connection detection conditions of a set (R, IF, SF) when creating a TS table.
FIG. 97 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks the connection detection condition of the R-SF-IF model when creating a TS table.
FIG. 98 is a flowchart showing a continuation of FIG. 97;
FIG. 99 is a flowchart showing processing in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks connection detection conditions of the R-IF-SF model when creating a TS table.
FIG. 100 is a flowchart showing a continuation of FIG. 99;
FIG. 101 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention checks the connection detection conditions of a set (R, SF, SF) when creating a TS table.
FIG. 102 is a flowchart showing processing for adding an entry to the TS table when the auto discovery module in the network configuration automatic recognition method according to the present invention creates the TS table.
FIG. 103 is a flowchart showing a process of adding a Root entry to the TS table when the auto discovery module in the network configuration automatic recognition method according to the present invention creates the TS table.
FIG. 104 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention adds a network relay device whose parent-child relationship and connection relationship are unknown when a TS table is created.
FIG. 105 is a flowchart showing a process of adding a network relay device in which only the parent-child relationship is unknown when the auto-discovery module in the network configuration automatic recognition method according to the present invention creates a TS table.
FIG. 106 is a flowchart showing a process of adding a network relay device whose parent-child relationship and connection relationship are obvious when the auto-discovery module in the network configuration automatic recognition method according to the present invention creates a TS table.
FIG. 107 is a flowchart showing a process in which the auto-discovery module determines the parent-child relationship when creating the TS table in the network configuration automatic recognition method according to the present invention.
108 is a flowchart showing a continuation of FIG. 107. FIG.
FIG. 109 is a flowchart showing a process of combining a plurality of models when the auto discovery module in the network configuration automatic recognition method according to the present invention creates a TS table.
FIG. 110 is a flowchart showing a process of combining entries in the TS table when the auto discovery module in the network configuration automatic recognition method according to the present invention creates the TS table.
FIG. 111 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention determines a network relay device whose connection relationship is unknown when a TS table is created.
FIG. 112 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention determines the parent-child relationship between the Root and the network relay device when creating the TS table.
FIG. 113 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention determines the connection port between the root and the network relay device when creating the TS table.
FIG. 114 is a flowchart showing processing in which the auto-discovery module in the network configuration automatic recognition method according to the present invention determines the connection between the network relay device and the terminal device when the TS table is created.
FIG. 115 is a flowchart showing a process in which the auto-discovery module in the network configuration automatic recognition method according to the present invention evaluates an interface MIB when creating a TS table.
FIG. 116 is a flowchart showing a process of displaying a network configuration drawing by the drawing display program in the network configuration automatic recognition method according to the present invention.
FIG. 117 is a flowchart showing a process of drawing on the screen by the drawing display program in the network configuration automatic recognition method according to the present invention during the network configuration drawing display process;
118 is a flowchart showing a continuation of FIG. 117. FIG.
FIG. 119 is a flowchart showing processing for predicting a non-intelligent hub when a drawing display program in a network configuration automatic recognition method according to the present invention draws a network configuration drawing;
FIG. 120 is a flowchart showing a process of displaying device information by a user event by a drawing display program in the network configuration automatic recognition method according to the present invention.
FIG. 121 is a flowchart showing processing of monitoring a connection destination change by a drawing display program in the network configuration automatic recognition method according to the present invention.
[Explanation of symbols]
DESCRIPTION OF SYMBOLS 1 ... Backbone network cable (Ethernet LAN), 2a, 2b ... Router, 3 ... Switching hub, 4 ... Bridge, 5 ... Intelligent hub, 6 ... Non-intelligent hub, 71 ... Administrator terminal, 72-78 ... Terminal apparatus 1102 Communication port 1103 Network configuration automatic recognition service program 1104 Drawing display program 1111 Operation status detection module 1112 MIB access module 1113 Auto discovery module 1121 OID table 1122 AT table 1123 TI table, 1124... PF table, 1125.

Claims (17)

A method of automatically recognizing a device configuration in a network system in which at least one intelligent network device that implements an SNMP agent and a management information base exists in a network node,
A first step of transmitting an ICMP echo request from an administrator terminal equipped with an SNMP manager to each network device in the network node and detecting an active network device based on the response, and an SNMP of each detected network device to the agent, IPMIB, bridge MIB, repeater MIB, the SNMP message for inquiring the existence of support printer MIB creates and sends each combination of the management information base storing information success and replies send and receive SNMP messages And a second step of detecting a device type representing a function in the network node of the network device existing in the network node.   A third step of acquiring a set of physical addresses of network devices connected to each port of the network device from a management information base of a network device having a bridge function as a device type; and a management information base of a network device having a routing function The fourth step of acquiring the correspondence information between the physical address and the IP address from the network, and the network device of the connection destination of each port of the network device having the bridge function on the IP level based on the acquired correspondence information between the physical address and the IP address. The network configuration automatic recognition method according to claim 1, further comprising a fifth step of recognizing.   The network device to which a response to the ICMP echo request is returned is in operation, and it is recognized that there is no network device to which no response is returned. Further, the correspondence information between the physical address acquired in the fourth step and the IP address is obtained. 6. The method according to claim 2, further comprising a sixth step of recognizing that the network device is inactive when there is correspondence information other than the network device that is referred to and is recognized as operating. To automatically recognize the network configuration.   Check whether the information of the network device that is not in operation at the connection destination of each port of the network device is stored in the management information base of the network device having the bridge function or repeater function. 4. The method for automatically recognizing a network configuration according to claim 3, further comprising a step of detecting a connection relationship of a non-operating network device based on the stored information.   Whether or not there are a plurality of network devices having a bridge function is detected based on the contents of the management information base of the network device acquired in the second step. If a plurality of network devices are detected, an arbitrary bridge function is provided. If the network device is a parent device, and further detecting whether or not there is another network device having a bridge function at the connection destination of the specific port of the parent device, The method according to claim 2, further comprising a step of searching for a device configuration of a connection destination of each port of the child device as a child device and recognizing a connection relationship between network devices having a bridge function in units of ports. Automatic network configuration recognition method.   A set of physical addresses of network devices existing at the connection destination of the port of the parent device connected to the child device, and a connection destination of ports other than the ports connected to the parent device from all ports of the child device 6. The automatic network configuration according to claim 5, further comprising a step of obtaining a difference between a set of physical addresses of network devices and recognizing a network device existing between the parent device and the child device. Recognition method.   When recognizing that there are a plurality of devices between the parent device and the child device, it detects whether all devices have a routing function, a bridge function, or a repeater function, and holds all of them. 7. The method for automatically recognizing a network configuration according to claim 6, further comprising the step of predicting that a non-intelligent network relay device is present if not.   The physical address held in the management information base of each of the parent device and the child device that have recognized the connection relationship is checked, and when the physical address of the child device is not held in the management information base of the parent device and the child device If the physical address of the parent device does not exist in the management information base, select any device that is included in the set of physical addresses of the devices that exist at the connection destinations of the specific ports of the parent device and the child device. 6. The network configuration automatic recognition according to claim 5, further comprising a step of recognizing the connection relationship between the parent device and the child device based on the connection port of the parent device or the child device for the selected device. Method.   A step of acquiring the value of the update frequency of the source physical address of the latest received frame at an arbitrary port of a network device having a repeater function, and recognizing the number of devices operating at the connection destination of the arbitrary port by this value If the value of the update frequency is other than “0” or “1”, the value of the source physical address of the latest received frame at the arbitrary port is acquired at predetermined time intervals, and the connection destination of the arbitrary port 3. The method for automatically recognizing a network configuration according to claim 2, wherein physical addresses of all network devices existing in the network are recognized.   The value of the update frequency of the source physical address of the latest received frame at an arbitrary port of the network device having the repeater function is acquired at predetermined time intervals, and the network device having the repeater function determines whether the value has changed or not The method for automatically recognizing a network configuration according to claim 2, further comprising a step of recognizing whether or not the device conforms to the specification.   For network devices that cannot recognize the connection relationship based on the management information base storage information of the network device having the bridge function and the network device having the repeater function, the network device having the bridge function and the network device having the repeater function by the administrator terminal If an arbitrary port is temporarily blocked and there is a response to the ICMP echo request packet before blocking, and there is no response after blocking, the device is recognized as existing at the connection destination of the port. The method for automatically recognizing a network configuration according to claim 2, further comprising the step of:   Transmission / reception frames in units of ports of the network device having the bridge function and the network device having the repeater function with respect to the network device having the bridge function and the network device having the repeater function that cannot recognize the connection relationship based on the management information base storage information And if there is a set of ports within a range of statistical values arbitrarily set for each port, the port set is recognized as a port having a connection relationship. The network configuration automatic recognition method according to claim 2, further comprising:   The management information base storage information of the network devices in operation is collected at a predetermined time interval, stored in the storage area of the administrator terminal, and compared whether there is a difference between the previous collection contents and the current collection contents. An automatic recognition of a network configuration according to any one of claims 3 to 12, further comprising a step of detecting start, stop, change of connection destination, change of IP address, and the like of an operating network device. Method.   Create a model table for the connection relationship between devices based on the information on the connection relationship between network devices, refer to the model table for each model of the connection relationship between devices, or combine the connection relationship models between multiple devices The network configuration automatic recognition method according to claim 3, further comprising a step of detecting a connection relationship between network devices.   The step of expanding the recognized network connection configuration into logical drawing data, creating drawing data in which the physical device configuration is arranged on a physical floor drawing, and displaying at least one drawing data on the display device screen The method for automatically recognizing a network configuration according to any one of claims 2 to 13, further comprising: A system for automatically recognizing a device configuration in a network system in which at least one intelligent network device having an SNMP agent and a management information base is present in a network node from an administrator terminal in which an SNMP manager is installed,
First means for detecting the network device in an operating state by the response of the ICMP echo request sent to the network device in the network node by the administrator terminal mounted with the SNMP manager, and each detected network device to SNMP agent, to the SNMP agent of the network devices detected, IPMIB, bridge MIB, repeater MIB, the SNMP message for inquiring whether a printer MIB support creates and sends each of the transmit and receive SNMP messages And a second means for detecting a device type representing a function in the network node of the network device existing in the network node by a combination of success / failure and the stored management information-based storage information returned. Automatic network configuration recognition system.   A third means for acquiring a set of physical addresses of network devices connected to each port of the network device from a management information base of a network device having a bridge function as a device type; and a management information base of a network device having a routing function 4th means for acquiring correspondence information between physical address and IP address from IP, and recognizing connection destination device of each port of network device having bridge function at IP level based on acquired correspondence information between physical address and IP address The network configuration automatic recognition system according to claim 16, further comprising: a fifth means configured to:

Images