JP2008042470A - Network fault detecting method and network fault detection program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a detection method and a detection program in which a delay situation of a network is judged, and a network fault caused by a difference of a communication status such as a difference in the amount of packets is detected, and/or a place of the fault is specified. <P>SOLUTION: Information of a connecting route to a desired computer connected to the network is acquired. Based on the acquired connecting route information, an IP address of network equipment connected on the route is stored. An Internet control protocol echo request is performed, using data greater than data in the case where the connecting route information is acquired, on the stored IP address in order from network equipment proximate on the route. A response to the echo request is acquired and when a response within an allowable range is obtained from network equipment to which echo is requested, the echo request is performed again using data greater than the data used for the echo request, and a response thereof is analyzed. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a network failure detection method and a network failure detection program capable of discovering a network failure even when communication itself is secured and a problem occurs in transmission of desired data.

  Conventionally, when a failure occurs in a network that communicates between devices connected on the network, a response from the target device is received via the network using a command necessary to identify the failure. The presence or absence is confirmed.

  Further, in a network connecting a plurality of clients and a plurality of servers, a response time and / or an arrival rate in a route from the branch line portion to the opposite branch line portion is measured. Then, the cause of deterioration of the response time / arrival rate is automatically obtained by comparing a plurality of pieces of route information, and operation information is collected from the network device located at the cause of deterioration. Based on the operation information, it is determined whether or not degradation has occurred due to insufficient device performance or line bandwidth, and the interface of the network device on the degradation path is blocked. In this way, detouring to a path where no deterioration is detected is performed (see, for example, Patent Document 1).

JP 2004-228828 A (FIGS. 5 and 6)

  However, since the communication status is confirmed with respect to the target device, a failure due to a difference in communication status including a difference in communication information, for example, a failure that occurs only when the number of data to be transmitted / received is large It may be difficult to grasp the failure status.

  Further, even when there are a plurality of network devices on the communication path, if the fault along the path is such that the communication is interrupted, the fault location can be determined by tracing the communication.

  However, in practice, when a failure occurs due to a difference in communication status, it is difficult to identify the failure location by simple tracing.

  In addition, in order to identify the actual failure location, it is necessary to log in to all network devices on the communication connection path and issue a continuity confirmation command to adjacent devices. For this reason, the more network devices exist, the more time-consuming work is required.

  Further, conventionally, since the continuity is confirmed with a predetermined packet size, the delay of the network cannot be determined sufficiently. In other words, it is only determined whether the network is alive or dead.

  The present invention has been made in view of the above problems, and provides a detection method and a detection program capable of determining a network delay state and detecting a network failure due to a communication state difference such as a difference in the number of packets. Objective. It is an object of the present invention to provide a network failure detection method and a detection program capable of specifying a failure location by simply executing a program from one of target computers regardless of the network form. To do.

  The present invention that achieves the above-described object provides a step of generating a continuity confirmation request with a first number of packets for a plurality of network devices connected to a network in the vicinity of the network device; There is provided a network failure detection method and the like including a step of receiving a response and a step of generating a continuity confirmation request with a number of packets larger than the first number of packets.

  According to the present invention, a network delay state can be determined, and a network failure due to a difference in communication state such as a difference in the number of packets can be detected. Furthermore, according to the present invention, it is possible to specify a fault location by simply executing a program from one of the target computers regardless of the network form. Furthermore, according to the present invention, when communication is completely interrupted by computer communication, it is possible to specify a fault location and a device causing a fault by executing a command for starting a program only once. It is also possible to do. The same applies to the case where a delay occurs due to a collision, a CRC error, or the like. Further, according to the present invention, it is possible to easily and quickly carry out a troublesome work that is very complicated and troublesome. Further, by changing the packet size used for specifying the failure, not only the network is shut off but also the location can be specified with respect to the delay. In addition, this program can be used by introducing the program of the present invention into a computer connected to a network without requiring a dedicated device for failure identification and analysis.

  Hereinafter, a network failure detection method and a network failure detection program of the present invention will be described with reference to the drawings as necessary. FIG. 1 is a schematic view for schematically explaining the present invention.

  In FIG. 1, 101 is a terminal A, 102 is a terminal B, and 111 to 114 are network devices A to D, respectively. A network device B 112 and a network device C 113 are connected to a WAN (wide area network) 122. An example is described in which the terminal A101 to the network device B112 are connected to the LAN (local area network) 121 on the terminal A101 side, and the terminal B102 to the network device C113 are connected to the LAN 123 on the terminal B102 side.

  In the example shown in FIG. 1, a signal (information) from the terminal A 101 passes through the network device A 111 and the network device B 112 in this order, and goes out from the LAN 121 to the WAN 122. Then, this signal (information) enters the LAN 123 from the WAN 122, passes through the network device C113 and the network device D114 in this order, and reaches the terminal B102. When there is no failure in communication, the signal (information) from the terminal A101 reaches the terminal B102 through the device A111... Device D114. The flow of communication at that time is indicated by (i) in the figure. The actual communication path is a portion of a solid line connecting each device or between the terminal and the device.

  Here, a case where a failure 131 has occurred in the communication path between the device C113 and the device D114 will be described. If this failure is a communication interruption, communication from the terminal A101 to the terminal B102 cannot be performed, so that the problem location can be immediately identified. However, if this failure is due to the number of signals being communicated, there is often no problem if the amount of information flowing in the communication path is not large. In such a case, a communication failure may occur depending on the type and amount of information being communicated. If this occurs at the failure location 131, the failure location cannot be recognized as a failure simply by sending out a Ping command for making an echo request that is used to confirm the normal communication state.

  The embodiment of the present invention recognizes such a failure that cannot be recognized by the conventional technology, and can specifically identify the failure location. For this reason, in this embodiment, when analyzing the state of the network (including inspection and investigation), Ping is issued to each known network device in the communication path to check whether communication is being performed. When this confirmation is performed from the terminal A side, the confirmation is performed in order from the side closer to the terminal A. In the present embodiment, the packet amount used when issuing Ping can be adjusted.

  Although details will be described below, in the present embodiment, the failure location 131 can be specified by making it possible to change the packet amount to a larger packet amount than usual. In other words, the Ping is issued to devices in order according to the response from the device, and it is confirmed whether there is a response. If a failure 131 as shown in the figure occurs between the device C113 and the device D114, a response is obtained from the device C113, but a response is not obtained from the device D114. As a result, the location of the failure can be identified. This failure can be specified by setting the amount of packets to be sent to be larger than usual, but by automatically increasing the amount of packets by the program, the trouble location caused by the communication status can be easily found. It becomes possible to specify. That is, the cause of the communication failure when the data amount (packet amount) is small and the communication failure when the data amount is large is often due to the occurrence of a CRC error or collision. As a result, the load is often applied to the communication device (communication port) and the communication is often timed out.

  According to the present embodiment, it is possible to detect and identify a failure that occurs when such a load is applied, so that it is easy to restore the communication state to a high-quality state.

  FIG. 2 is a flowchart for explaining an example of a processing flow for detecting a network failure in the embodiment of the present invention.

  First, obtain information such as the presence of a network failure, or periodically run a program to identify where a network failure has occurred and where the failure has occurred (Start step 200).

  When the failure detection program is started, as a first step, from the screen as shown in FIG. 4, the IP address of the search target computer (computer B), initial packet amount, maximum packet amount, packet increase rate, normal arrival of packets The rate is input (step 201). The initial setting screen shown in FIG. 4 is a screen that is displayed on the screen of a computer that has started up the failure detection program of the present invention. Here, this screen will be described.

  In the screen shown in FIG. 4, the number of initial packets, the maximum number of packets, the number of times, and the normal packet arrival rate can be set in the upper part. The initial number of packets can be selected with a radio button to use the normal 32 bytes or an arbitrary set value. When an arbitrary value is used, a desired value is input to the input box using an external input means such as a keyboard.

  As for the maximum number of packets, whether to use 20000 bytes set as an example or an arbitrary value, whether normal or set, can be selected with a radio button. The number of times can be initially determined whether to perform the maximum two times or to follow the detailed setting, and here, the normal button and the detailed setting can be determined by a radio button. The packet arrival rate at the normal time is normally set to 90% so that an arbitrary value can be input with a radio button.

  In the case shown in FIG. 4, the initial packet number is “set”, the maximum packet number is “normal”, the number of times is “detailed setting”, and the normal packet arrival rate is “set”. The detailed setting of the number of times can be set within the interruption frame of FIG. 4, and either the packet increase rate or the number of times can be selected. When the packet increase rate is selected, the packet increase rate can be automatically selected (1000 bytes in this case) or an arbitrary packet increase rate can be selected. When the packet increase rate is selected, the number of continuity confirmation requests, for example, the number of Internet protocol echo requests is determined by the packet increase rate, so the number cannot be input. When the number of times is selected, an input box for the number of times can be entered, and any number can be entered. The number of times in this case is determined in consideration of the initial number of packets and the maximum number of packets.

  After determining the necessary settings, if the “OK” button at the bottom of FIG. 4 is selected, the settings are registered, and the failure detection program is executed according to this condition. When canceling this setting, it is possible to overwrite or change the selection if each condition is corrected. If a cancel cell is selected, this setting screen ends. Note that the configuration and setting items of the setting screen can be changed as necessary.

  Next, the IP address of the currently logged-in computer (computer A) is input and set as argument 1. Further, the IP address of the search target computer (computer B) is set as argument 2 (step 202).

  Next, a route search command traceroute is issued to computer B, which is the target computer (step 203). Arguments are assigned to the IP addresses of the devices in the route from terminal A to terminal B obtained in step 203, respectively. In this example, it is found that device A, device B, device C, device D,... Are connected as devices connected to the network, and argument 11, argument 12, argument 13, argument are sequentially connected to each device. 14 ... are made to correspond.

  In this example, the argument z is assigned to the IP address of the terminal B (step 204).

  Next, the address of the terminal A is set as an argument 21 (step 205).

  Subsequently, the packet size to be transmitted is set (step 206). The packet size may be set to an initial value and a maximum value. Furthermore, the increase amount of the packet size when the Ping command issuance described below is repeatedly performed may be set together.

  When the packet size has been set, the argument 11 (here, the IP address of the network device A) is read into N (step 207), and Ping is issued to this N (step 208).

  If there is a response by Ping, the process branches to YES, and if there is no response, the process branches to NO (step 209).

  If there is a response, it is determined whether N is an argument z (step 210).

  That is, here, it is confirmed whether the destination of the IP address that issued Ping is the terminal B that is the final target terminal. If it is not the argument z, N is set to the argument 21 (step 211), N + 1 is set to N + 1, and the IP address is rewritten from the network device A to the network device B (step 212).

  Thereafter, in this flow, since it is determined that communication is normally performed with respect to the network device A, the Ping command is similarly issued to the network device B. Issue.

  When N matches the IP address of terminal B, it is confirmed that no communication failure occurs between terminal A and terminal B with the Ping size. If it is confirmed that there is no communication failure, it is next determined whether or not the packet size of the sent Ping is equal to or larger than a set value (step 213).

  If the packet size is not greater than the maximum value set in step 206, the packet size is added based on the information set in step 201 (step 214). That is, the packet size amount transmitted according to a predetermined ratio, a preset addition amount, an arbitrarily set ratio or addition amount is added.

  When the packet amount is added, the process returns to Step 207, and the argument 11, that is, the IP address of the network device A is stored in N, and the above flow is repeated again.

  If there is a Ping response even if the value of the amount of packets to be sent is larger than the maximum size of the set packet, it is determined YES in the determination of the amount of packets in step 213, and the analysis flow ends (step 217).

  In this case, no failure has occurred in communication with at least the amount of packets set on the network.

  If there is no response to the issuance of Ping, the process proceeds to a NO branch at step 209. At this time, the IP address N for which a response has been made is stored as an argument 22 (step 215).

  As a result, no communication failure has occurred up to the network device stored in the argument 21 and no communication failure has occurred in the network device stored in the argument 22 in the packet amount transmitted by Ping. I understand.

  Therefore, the fact that there is a failure between the argument 21 and the argument 22 is notified by display or stored as a result file (step 216).

  Further, the device information of the faulty device is collected and changed to a normal state setting (step 216-2).

  If the processing such as storage and display of the fault location is completed and the device settings are normalized, the analysis flow is completed (step 217).

  Even when it is determined that there is no failure, it is preferable to display and / or store the result, and the present invention is not limited to the detailed flow.

  To change the packet size, determine at least one of the minimum value as the initial value and the maximum value as the final value, and automatically or a predetermined ratio, amount, or division between the minimum and maximum values between them. The number may be set so that the number of packets can be increased according to the judgment.

  Of course, the packet size can be set in advance in the program so that it cannot be changed by a normal operation, so that the determination can be made regardless of the skill.

  Further, in the above description, a case is described in which an echo request is made to related devices in the same packet and the packet amount is increased by looking at the result. However, the packet amount may be gradually increased from a small packet to a large packet with respect to the first device, and if no problem is found, the next device may be shifted to. Such a method is effective in cases where there are failures at a plurality of locations. By doing so, it is possible to move to the next device after removing the obstacles in order, so that normalization can be surely performed.

  FIG. 3 is a block diagram showing a schematic configuration for explaining an example of a computer suitable for executing the system of the present invention and the program of the present invention.

  The computer 900 includes a CPU 901, a ROM 902, a RAM 903, and a keyboard controller (KBC) 905 of a keyboard (KB) 909 as an input device. In addition, a CRT controller (CRTC) 906 of a CRT display (CRT) 910 as a display unit and a disk controller (DKC) 907 of a hard disk (HD) 911 and a flexible disk (FD) 912 are provided. Further, a network interface controller (NIC) 908 for connection to the network 920 is connected to be communicable with each other via a system bus 904.

  The CPU 901 comprehensively controls each component connected to the system bus 904 by executing software stored in the ROM 902 or the HD 911 or software supplied from the FD 912. That is, the CPU 901 reads out a processing program according to a predetermined processing sequence from the ROM 902, HD 911, or FD 912 and executes it, thereby performing control for realizing the operation in the present embodiment.

  Although not shown, other devices such as an optical recording apparatus may be connected in addition to the hard disk and the flexible disk. The RAM 903 functions as a main memory or work area for the CPU 901. The KBC 905 controls an instruction input from the KB 909 or a pointing device (not shown). The CRTC 906 controls the display of the CRT 910. The DKC 907 controls access to the HD 911 and the FD 912 that store a boot program, various applications, an edit file, a user file, a network management program, a predetermined processing program in the present embodiment, and the like. The NIC 908 exchanges data bidirectionally with devices or systems on the network 920.

  The computer configuration necessary for carrying out the present invention is not limited to the computer configuration shown in FIG.

  The failure analysis was performed according to the flowchart shown in FIG. In this embodiment, the names and IP addresses of a plurality of network devices existing between the computer performing the operation and the target computer are stored in the memory of the computer in order from the one closest to the computer. The continuity confirmation command Ping is set so that the packet size is issued with a medium capacity (5000 bytes) to the network device closest to the computer. The packet arrival rate determined by the conduction check is stored in the memory of the computer. When the packet arrival rate obtained by the continuity check is equal to or higher than the normal packet arrival rate, set the packet size to a large capacity (10000 bytes) and issue the continuity check command Ping to the network device. Set. Also in this case, the obtained packet arrival rate is stored in the memory of the computer. At this time, the IP address, initial packet amount, maximum packet amount, packet increase rate, and normal packet arrival rate of the target computer are set using the screen shown in FIG.

  As a result, when the packet size was increased, the packet arrival rate was less than the normal packet arrival rate, and it was confirmed that a communication delay, that is, a failure occurred in that portion. In this embodiment, when the packet arrival rate is smaller than the normal packet arrival rate, a message “delay occurred in“ network device name ”” is displayed on the output device. Then, the device information of the device in which the failure has occurred is collected, changed to a normal setting, and the program is terminated.

  In this embodiment, the packet arrival rate at normal time is 90%, which is an average value of the packet arrival rate at the time when an Internet control protocol echo request such as a Ping command is made a plurality of times in a state where no communication failure occurs. Was the value. Of course, it is not always necessary to take an average value for the packet arrival rate at the normal time, and one obtained actual measurement value may be directly used as a set value. In addition, a desired numerical value may be appropriately input based on an actual measurement value or in view of a required service level. Further, the packet arrival rate at the normal time may be set to a predetermined value, for example, 90% as a specified value, and the value may be varied according to the request.

  In Example 1, the initial packet amount setting was 1000 bytes, the maximum packet amount setting was 20000 packets, and the packet increase rate was 5000 bytes. As a result, it was possible to detect that the packet amount is 11000 bytes and there is a failure at the same location as in the first embodiment.

  In Example 1, the initial packet amount was set to normal (32 bytes), and the analysis was performed in the same manner by increasing the packet amount automatically. Note that the increase in the packet amount in the automatic setting is set to increase by 1000 bytes per investigation.

  As a result, it was possible to detect a failure at the same location as in Example 1 in the amount of packets of 10032 bytes.

  In Example 1, the initial packet amount was 1000 bytes, the maximum packet amount was 15000 packet amounts, and the increase rate was set in 8 stages. Note that this setting automatically increases the number of packets to 2000 bytes at a time.

  When the embodiment of the present invention was executed with this setting, a failure was found at the same location as Example 1 in the sixth session. Therefore, in this case, a failure is detected with a packet amount of 11000 bytes.

  The embodiment of the present invention can be realized by, for example, a computer executing a program. Also, means for supplying a program to a computer, for example, a computer-readable recording medium such as a CD-ROM recording such a program, or a transmission medium such as the Internet for transmitting such a program is also applied as an embodiment of the present invention. Can do. The above program can also be applied as an embodiment of the present invention. The above program, recording medium, transmission medium, and program product are included in the scope of the present invention.

It is a schematic explanatory drawing for demonstrating this invention. It is a flowchart for demonstrating one suitable embodiment of this invention. It is the schematic for demonstrating a suitable example of the terminal which can be applied to this invention. It is explanatory drawing explaining an example of the screen for implementing the initial setting at the time of utilizing this invention.

Explanation of symbols

101 Terminal A
102 Terminal B
111 Network equipment A
112 Network equipment B
113 Network equipment C
114 Network equipment D
121 LAN (Local Area Network)
122 WAN (Wide Area Network)
123 LAN (Local Area Network)
131 Fault location 900 Computer 901 CPU
902 ROM
903 RAM
904 System bus 905 Keyboard controller (KBC)
906 CRT controller (CRTC)
907 Disk controller (DKC)
908 Network Interface Controller (NIC)
909 Keyboard (KB) as input device
910 CRT display (CRT)
911 Hard Disk (HD)
912 Flexible disk (FD)
920 network

Claims (12)

Generating a continuity confirmation request with a first number of packets for a plurality of network devices connected to the network;
Receiving a response to the continuity confirmation request;
Generating a continuity confirmation request with a larger number of packets than the first number of packets;
A network failure detection method comprising:   2. The network failure detection method according to claim 1, wherein the network device is identified by generating connection path information to a predetermined computer and obtaining a response to the information.   3. The continuity confirmation request is performed by storing an IP address of a network device connected on the path based on the acquired connection path information, and using the IP address. Network failure detection method.   Using at least one selected from the group consisting of the presence / absence of packet loss, response time, and presence / absence of response as a response to a continuity confirmation request made with a larger number of packets than the first number of packets as the continuity determination The network fault detection method according to claim 1, wherein the network fault is detected. On the computer,
A procedure for generating a continuity confirmation request with a first number of packets for a plurality of network devices connected to a network;
A procedure for receiving a response to the continuity confirmation request; subsequently, a procedure for generating a continuity confirmation request with a number of packets larger than the first packet number;
A network failure detection program characterized in that A procedure for generating connection route information to a predetermined computer;
A procedure to get a response to it,
A procedure for identifying the network device based on the information obtained by the procedure;
The network failure detection program according to claim 5, wherein: A procedure for storing, in a storage unit, an IP address of a network device connected on the path based on the acquired connection path information;
A procedure for reading the stored IP address and generating a continuity confirmation request to the network device;
The network failure detection program according to claim 6, further comprising:   Procedure for comparing response of continuity confirmation request made with larger number of packets than the first number of packets as at least one selected from the group consisting of presence / absence of packet loss, response time, and presence / absence of response as determination of continuity The network failure detection program according to any one of claims 5 to 7, further comprising:   Generate a setting screen having at least one input area for initial packet number, maximum packet number, and packet arrival rate, and a number input area for setting the rate of increase in the number of packets from the initial packet number to the maximum packet number A network failure detection method characterized by the above.   10. The network failure detection according to claim 9, wherein the number input area has an input area selected from a packet increase rate or the number of continuity confirmation requests executed between the initial packet number and the maximum packet number. Method. On the computer,
A procedure for executing a first command for obtaining connection path information to a computer connected to a network and determined in advance;
A procedure for storing, in a storage unit, an IP address of a network device connected on the path based on connection path information acquired by execution of the first command;
For reading out an IP address stored in the storage means from a network device adjacent on the route and requesting an Internet control protocol echo for the read IP address using data larger than that at the time of obtaining the connection route information A procedure for executing a second command;
A procedure for comparing at least one selected from the group consisting of the presence / absence of packet loss, response time, and presence / absence of response from the response information acquired by executing the second command with a reference range value;
As a result of the comparison, when the acquired response information is within an allowable range, the second command is executed again as data larger than the data used when the response information is obtained. When,
Displaying the result of the comparison;
Network failure detection program for running Making an Internet control protocol echo request to the stored IP addresses in order from the network devices that are close to each other on the route using data larger than that at the time of obtaining the connection route information;
When a response to the echo request is obtained and a response within the allowable range is obtained from the network device for which the echo request is requested, the echo request is performed again using data larger than the data used in the echo request, Analyzing the response;
A network failure detection method comprising:

Images