JP2002094507A - Method for estimating fault in internet - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a fault estimating method in the Internet, which can estimate a cause of a communication fault and its location due to a defective software program, using a simple configuration. SOLUTION: A fault detection server provided to each of networks independently managed and operated is equipped with a fault declaration reception section 100 that accepts a fault declaration from a user terminal, an SNMP(Simple Network Management Protocol) execution section 101, a path revision history collection section 102, a retrial section 103 that retries communication whose fault is declared, and a fault cause estimate section 104 that estimates a cause of the fault. The retrial section 103 is provided with a low- order level retrial section 103 that sequentially confirms a fault state to each router on a communication path used for the communication and with a host level retrial section 103b that makes communication at a high-order level between an access source terminal and an access destination terminal by the TCP(Transmission Control Protocol) so as to confirm the fault state.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an Internet fault estimation method, and more particularly to an Internet fault estimation method capable of estimating not only a hardware fault but also a cause and a part of a software fault.

[0002]

2. Description of the Related Art With the spread of the Internet, there have been problems such as congestion of networks and servers due to traffic concentration, and communication failure due to system down. When such a failure occurs, it is necessary to immediately identify the location of the failure and its cause. For this reason, SNMP (Simple Network Management Pr
A failure detection system based on a network management method based on otocol) or a monitoring method for monitoring a line or the inside of a terminal has been proposed.

As shown in FIG. 6, the failures on the Internet include not only hardware failures such as line disconnection and router / server failures, but also congestion, program bugs, and operator operations. A software failure due to an error, a protocol procedure, or the like is considered.

[0004]

As described above, in order to realize effective failure detection and its cause estimation on the Internet, not only the conventional hardware failure but also the software failure detection is required. Must be possible. However, the conventional SNMP described above
The network management method based on the above is based on detecting a hardware failure, and it is difficult to detect a software failure.

In addition, the conventional monitoring method has a problem that it is not suitable for a widely used Internet environment as it is today, because a monitoring device must be installed at all locations where a failure is to be detected.

An object of the present invention is to solve the above-mentioned problems of the prior art and to combine monitoring of communication line and path information exchange with retry of a failed communication to cause a protocol procedure or an operation error. An object of the present invention is to provide a method for estimating an Internet fault that can detect various faults and estimate the cause thereof and does not require the introduction of a large number of facilities.

[0007]

In order to achieve the above-mentioned object, the present invention provides a fault detection server for each network which is independently managed and operated, and is provided with an access source terminal on a first network and a second server. A failure detection server on the first network for estimating a cause of a communication failure occurring between the access source terminal and the access destination terminal on the first network. Communication failure is reported from the access source terminal, and then, based on the report contents, a retry procedure for retrying the communication in which the failure occurred, and estimating the failure cause based on the failure information collected in the retry And a retry procedure, wherein in the retry procedure, an IP level is set for each network device arranged on the communication path in which the fault has occurred. A lower-level retry for confirming the failure status of each network device and its link, and an upper-level retry for acting as an access source terminal to perform TCP and higher-level communication with the access destination terminal and confirm the failure status. The fault estimating procedure is executed, and the cause of the fault is estimated based on the fault information collected by the lower-level and higher-level retries.

[0008] According to the above-mentioned feature, in the lower-level retry in the retry procedure, each router on the communication path used for the communication in which the failure has occurred has a fault / congestion of the router or its link. You can check the situation. In the upper-level retry, TCP and the upper-level end-to-end communication are reproduced between the user terminal and the communication partner, and the communication performance is confirmed, and the protocol procedure and network parameters of the communication partner are set. You can confirm the problem. Therefore, a software failure caused by congestion, a program bug, a protocol procedure, or the like can be detected.

[0009]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described below in detail with reference to the drawings. FIG. 1 is a diagram schematically showing a configuration of a network to which the fault estimation method of the present invention is applied, and FIGS. 2, 3, and 4 are diagrams showing a sequence of a communication protocol executed between network devices. It is.

In this embodiment, a failure detection server is provided for each network such as a LAN and an ISP (Internet Service Provider) that are independently managed and operated, and an access source terminal on the first network and a second terminal are connected to the second network. A failure that has occurred between the terminal and the access destination terminal on the network is detected.

In FIG. 1, in ISP 1, a user terminal T as an access source terminal is connected to ISP 2 via routers R1 and R2 as network devices. The status of each router R1, R2 and its link is monitored by the failure detection server S1. In ISP2,
A WWW server W as an access destination terminal is selectively connected to the ISP 1 via routers R3, R4, and R5 as network devices. Each router R3, R4, R
5 and the status of the link are monitored by the failure detection server S2.

Hereinafter, the failure estimation method according to the present embodiment will be described by taking as an example the deterioration of the response time and the transfer throughput that occur when the user terminal T belonging to ISP1 accesses the WWW server W belonging to ISP2.

In order to detect a software failure, it is necessary to detect an exceptional exchange in communication and analyze the cause. That is, in order to realize failure detection, it is necessary to interpret the behavior of the TCP / IP protocol. Therefore, in the present embodiment, in order to interpret the behavior of the TCP / IP protocol, a procedure [Procedure 3] for retrying communication in which a failure has occurred is newly adopted, and further, a hardware failure is detected. An existing procedure [Procedures 1 and 2] is combined with this, and a comprehensive determination is made from the failure information obtained in each of the procedures [Procedures 1 to 3] to estimate the location of the failure and its cause [Procedure 4]. I am trying to do it.

FIG. 5 is a block diagram showing a configuration of a main part of the fault detection server S1 of the present invention for executing the above-described procedures. The fault report receiving unit 100 for receiving a fault report from the user terminal T; SNMP for executing the procedure 1
An execution unit 101, a route change history collection unit 102 that executes the procedure 2, and a retry unit 103 that executes the procedure 3
And a failure cause estimating unit 104 that executes the procedure 4.

Further, the retry unit 103 includes, for each router on the communication path in which a failure has occurred, a lower-level retry unit 103a for sequentially ascertaining the failure status of each router and its link, TCP between terminals
And an upper-level retry unit 103b for performing communication at the upper level and confirming the failure status. Hereinafter, each procedure will be described.

Procedure 1: Hardware Failure Detection by SNMP Each of the failure detection servers S1 and S2 communicates with network devices such as routers and servers in the networks ISP1 and ISP2 under their own control by SNMP. Then, the status of each network device is periodically checked to determine whether a hardware failure such as a line disconnection or a router failure has occurred. In the example of FIG.
The failure detection server S2 of the router R3 by SNMP,
Based on the information obtained from R5, it is possible to detect that a failure has occurred in the link between the routers R3 and R5 [FIG. 2 (a)].

Procedure 2: Failure detection based on change history of route information Each of the failure detection servers S1 and S2 communicates with another router according to a routing protocol by functioning as a normal router, and relates to the change of route information. Get history information. Each time the failure detection servers S1 and S2 receive the route change history, they recalculate the route status of the entire network and check for frequent changes in route information, lack of route information to a specific area, and the like.

In the example of FIG. 1, when the failure detection server S2 executes the routing protocol, the router R5 changes the packet transfer to the router R3 to the route via the router R4, and the router R3 transfers the packet to the router R5. Is changed via the router R4 [FIG. 2 (b)].

Step 3: Failure detection by retrying communication The failure detection server S1, which has received a report of the content of the failure from the user terminal T, lowers the communication that the user tried to perform (I
P) Retry at level and higher (TCP or higher) level.

In the lower level retry, the router / link failure / congestion status is confirmed for each router on the communication path used in the communication. In the high-level retry, TCP and higher-level end-to-end communication with the user terminal or the communication partner are reproduced, and problems such as confirmation of communication performance, protocol procedures of the communication partner, and setting of network parameters are solved. Confirm. Hereinafter, the retry at each level will be described.

Procedure 3-1: Retry at lower level The failure detection server S1 of the network ISP1 to which the user terminal T belongs is connected to the router R with which the user terminal T first communicates.
In addition to investigating the congestion state and the failure state of No. 1 and searching for a next hop router (router R2 in this embodiment) for transferring a packet to a communication partner. If this process is repeated and the next hop router becomes a router belonging to another network, the failure detection server S1 sets the failure detection server of the next network to correspond to the address of the user terminal T, the address of the server, and the user terminal T. A request for retrying at the IP level together with information on the failure detection server to be performed.

The failure detection server (failure detection server S2 in this embodiment) requested to retry repeats the same processing. Further, such a retry is also performed in the direction from the WWW server W to the user terminal T. Hereinafter, the lower level retry method will be described with reference to the sequence diagram of FIG.

First, the user of the user terminal T receives the WWW
When recognizing that the response speed from the server W and the data transfer throughput have decreased, the failure detection server S of the ISP 1
For 1, report that a failure has occurred and its contents [Fig. 3 (c)]. The declaration contents include, for example, the type of application used in the communication, the URL of the communication partner, and the mail address.

Upon detecting the report, the failure detection server S1 inquires of the router R1 to which the user terminal T is connected whether there is a line failure or the like, and at the same time, WWW.
The router R2 as the next hop is searched based on the address of the server W. If there is no particular problem in the router R1, the same processing is performed on the next hop router R2 [FIG.

Since the router R3, which is the next hop of the router R2, belongs to the ISP2, the failure detection server T
The communication partner WWW is sent to the failure detection server S2 of SP2.
Request the failure detection work by retrying at the lower level together with the necessary information such as the address of the server W [FIG.
].

First, the failure detection server S2 starts the router R
3 is inquired. In the present embodiment, it is confirmed from the result of this inquiry that a failure has occurred in the link between the routers R3 and R5, and that the packet transfer route from the router R3 to the router R5 has been changed to a route via the router R4 [ FIG.

The failure detection server S2 also has a router R
4. Also ask R5. In the present embodiment, it is detected from the result of this inquiry that the link from the router R5 to the router R4 is congested due to an overflow of the output buffer in the router R5 [FIG.

The details of the above-described implementation of the retry at the IP level will be described below. In the retry at the IP level, the failure detection server S1 investigates the state of the router that has passed through the reported communication. Inspection of this state and search for the next hop router are performed in MIB (Management Information Base) defined by the standard.
Use the following information (1) and (2).

(1) IP routing table (IP Route T)
destination) (IP Route Dest), interface identifier (IP Route If Index), and next hop address (IP Route Next Hop).

(2) Interface table (if Table)
Interface speed (ifSpeed)), number of input / output bytes / packets (InOctets, OutOctets, InUcastPkts, Ou
tUcastPkts), number of input / output discarded packets (InDiscards, Ou
tDiscards), output queue length (OutQLen).

Of these, the number of input / output bytes / packets, the number of input / output discarded packets, the output queue length, etc., are periodically read out to record the temporal changes, and the network condition at the time of retry is accurately determined. Is determined. Further, a contract between the detection servers is made in advance with the failure detection server S2 of the adjacent network. For this reason, when the retry at the IP level crosses the management domain, it is assumed that the failure detection server requesting the retry can be determined according to the next domain (Autonomous System).

Procedure 3-2: Retry of upper level In the retry of the upper level, first, the failure detection server S1 corresponding to the user terminal T communicates with the WWW server W of the access destination terminal instead of the user terminal T. Then, it interprets the procedures of various protocols used for communication, examines the behavior of the protocols such as the status of data retransmission and activation of abnormal processing, and detects failures. In addition, in order to confirm server congestion, a retry is also performed from the failure detection server S2 closest to the WWW server W of the communication partner.

Further, with respect to the higher-level protocol, the user terminal T is detected in order to detect an inherent failure that occurs only when the user terminal T communicates with the WWW server W.
The server also communicates with the failure detection server S1, in which the failure detection server S1 replaces the WWW server W and checks the behavior of various protocols in the user terminal T. Here, a delay is inserted, or a sudden packet loss / delay occurs. Hereinafter, the upper level retry will be described with reference to the sequence diagram of FIG.

The failure detection server S1 of the ISP1 retries the communication with the WWW server W on behalf of the user terminal T, performs the behavior check of the protocol on the WWW server side and estimates the related parameter setting values, etc. The response time / throughput is measured [figure (h)]. As a result, in the present embodiment, a result is obtained in which the response speed is low even when the WWW server W is accessed from the failure detection server S1.

On the other hand, the failure detection server S1 performs a higher-level retry with the user terminal T on behalf of the WWW server W, and checks the behavior of the protocol on the user terminal T side and estimates related parameter setting values. To check the problem of the user terminal T and the problem of compatibility with the WWW server W regarding the parameter setting [FIG. In the present embodiment, it is assumed that a result indicating that there is no problem with the user terminal T is obtained.

Further, the failure detection server S1 also communicates with the failure detection server S2 adjacent to the WWW server W.
Request retry at the higher level together with the necessary information [figure (j)]. The failure detection server S2 performs communication on behalf of the user terminal. In the present embodiment, it is assumed that a result indicating that there is no problem in response speed is obtained.

Step 4: Comprehensive Judgment of Result in Failure Detection Server Based on the failure information obtained by the above-described procedures, the failure detection server S1 grasps the following points.

By executing the SNMP [Procedure 1] / routing protocol [Procedure 2], a failure occurred in the link between the routers R3 and R5, and the IP packet transfer between the routers R3 and R5 was changed to be via the router R4.

Due to the retry at the IP level [Procedure 3-1], the communication routes from the user terminal T to the WWW server W include the routers R4 and R5.
There is congestion on the link to.

Due to the retry at the higher level [Procedure 3-2], there is no problem in the protocol operation of the user terminal T or the WWW server W, and the failure detection server S2 of the ISP 2 sends the WW to the WW.
There is no problem with the response speed even when accessing the W server W,
When accessing the WWW server W from the failure detection server S1 of the ISP 1, there is a problem in response speed.

The failure detection server S1 comprehensively judges the above information, and determines that a failure has occurred on the link between the routers R3 and R5, which is a normal path between the user terminal T and the WWW server W, and the failure has been detected via the router R4. Has been set, but the response speed has decreased due to congestion occurring in the link from the router R5 to the router R4. "((K) in the same figure).

As described above, according to the present embodiment, the failure detection server, which has received a communication failure report from the user, retries the communication in which the failure has occurred at the lower level and the upper level. The status of each router and its link can be recognized based on information obtained from each router and other failure detection servers.

In the ordinary communication protocol, prior to access to the WWW server W, the user terminal T
Accesses the name server according to the DNS in order to obtain the IP address from the domain name of the WWW server W. When a failure occurs in communication with the name server, the retry procedure 3 can be applied as follows.

The user terminal T usually accesses a local name server to obtain an IP address. In addition, an authoritative server is assigned to each domain name. Therefore, in order to confirm the validity of the logical name, first, an attempt is made to obtain the address of the authoritative server corresponding to the domain name accessed by the user. If the server is unknown, the communication is retried at the IP level, and if the name server is operating correctly, it is determined that the given domain name was bad.

Next, the operation of the local name server is confirmed by comparing the IP address cached in the local name server with the IP address queried by the authoritative name server.

As described above, when the inquiry of the IP address by the DNS is completed, the user terminal starts communication according to each application. Taking the access to the WWW server by HTTP as an example, the retry procedure will be described below.

The failure detection server S corresponding to the user terminal T
1 and the failure detection server S2 of the management domain to which the WWW server W belongs. At this time, the detection of the failure detection server S2 on the server side is performed when sequentially following the failure detection server when retrying at the IP level, and at that time, a request for retry and necessary information (failure detection corresponding to the terminal) are made. Server address).

In the case of HTTP, attention is paid to TCP, and SYN
Investigate the status of packet acceptance / rejection, evaluation of TCP-level throughput, and the status of segment retransmission and the accompanying congestion avoidance procedure. At this time, the bandwidth of the route used for communication (checked by retrying at the IP level) and the like are used as reference information.

[0049]

According to the present invention, the following effects are achieved.

(1) The communication in which a failure has occurred is sent to the lower (IP)
Retry at the level and higher (TCP or higher) levels, respectively. In the lower level retry, the router / link failure / congestion status is checked for each router on the communication path used in the communication, and in the higher level retry, the user terminal or the communication partner is checked. It reproduces end-to-end communication between TCP and higher level, confirms communication performance, confirms problems such as protocol procedures and network parameter settings of the communication partner, so it can be used for congestion, program bugs, protocol procedures, etc. A software failure caused by the failure can be detected.

(2) A procedure for retrying a communication in which a failure has occurred to detect a software failure and a procedure for detecting a hardware failure such as a router or its link are combined and obtained by these procedures. Since the cause of the failure is estimated by comprehensively judging from the received information, both a software failure and a hardware failure can be detected.

[Brief description of the drawings]

FIG. 1 is a diagram schematically illustrating a configuration of a network to which a failure estimation method according to the present invention is applied.

FIG. 2 is a diagram (part 1) illustrating a communication sequence executed between each router and a server;

FIG. 3 is a diagram (part 2) illustrating a communication sequence executed between each router and a server.

FIG. 4 is a diagram (part 3) illustrating a communication sequence executed between each router and the server.

FIG. 5 is a functional block diagram of a failure detection server.

FIG. 6 is a diagram showing types of faults to be detected.

[Explanation of symbols]

R1, R2, R3, R4, R5 ... router, S1, S2 ...
Failure detection server, T: user terminal, W: WWW server

 ──────────────────────────────────────────────────続 き Continued on the front page F term (reference) 5B089 GA11 GB02 JA35 KA12 KC30 KC47 MC11 5K030 GA04 HA04 JA10 JT06 KA01 LB05 MB20 MC01 MD01

Claims (4)

[Claims] 1. A failure detection server is provided for each network that is independently managed and operated, and causes of a communication failure occurring between an access source terminal on a first network and an access destination terminal on a second network. In the Internet failure estimation method, the failure detection server on the first network reports a communication failure between the access source terminal and the access destination terminal from the access source terminal, and thereafter, the report content A retry procedure for retrying communication in which a fault has occurred, and a fault estimating procedure for estimating a fault cause based on fault information collected in the retry. Check the failure status of each network device and its link at the IP level for each network device placed on the communication path where the error occurred And lower-level retries that, access destination terminal waiting shake as an access source terminal and the TC
P and upper-level communication are performed, and an upper-level retry for confirming the fault status is performed. In the fault estimation procedure, a fault cause is estimated based on the fault information collected in the lower-level and higher-level retries. A method for estimating an Internet fault. 2. Each of the failure detection servers periodically executes SNMP with a network device in a network, and further executes an SNMP procedure for detecting a failure of the network device and its link. Retry procedure and SNMP
2. The Internet fault estimation method according to claim 1, wherein a fault cause is estimated based on the fault information collected in the procedure. 3. The failure detection server executes a routing protocol with each network device in the network, and further executes a route change history collection procedure for grasping a route change history in each network device. 2. The Internet fault estimation method according to claim 1, wherein a fault cause is estimated based on fault information collected in the retry procedure and the route change history collection procedure. 4. The failure detection server periodically executes SNMP with a network device in the network, and detects an SNMP procedure for detecting a failure of the network device and its link, and a routing protocol with each network device in the network. Executing a path change history collection procedure for grasping a path change history in each network device. In the fault estimation procedure, each fault information collected in the retry procedure, the SNMP procedure and the path change history collection procedure is executed. 2. The method for estimating a failure on the Internet according to claim 1, wherein the failure is estimated on the basis of: