JP2002164890A - Diagnostic apparatus for network - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a diagnostic apparatus for a network which enables to estimate quickly a trouble factor based on traffic analysis. SOLUTION: This diagnostic apparatus includes a statistical information collection unit 101 which collects statistical information on traffic over a line comprising network for every application, a TCP segment header information collection unit 103 which extracts header information of TCP segment from traffic over the prescribed line, a flow extraction unit 105 which extracts selectively a diagnostic object flow satisfying prescribed conditions based on the statistical information and a network construction for every application unit, and a diagnostic unit 107 which diagnoses a performance trouble of an extracted diagnostic object flow based on calculational information and header information of the TCP segment.

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a network diagnostic device, and more particularly to a network diagnostic device capable of estimating a failure factor based on traffic analysis.

[0002]

2. Description of the Related Art In an IP-based network, in order to always provide users with high-quality communication, the communication performance such as the amount of traffic such as the number of IP bytes and the retransmission rate of each line or user is analyzed. At the same time, it is important to detect performance failure points such as low throughput and take improvement measures such as adding lines.

[0003] In the operation of a conventional network, the bandwidth utilization at the IP level is measured in order to determine the timing of future line addition and speedup. Bandwidth utilization is MR
It is calculated based on a traffic amount such as the number of IP bytes measured by a TG (Multi Router Traffic Grapher) or the like. The MRTG is installed at a location where it can communicate with the router,
MIB measured as information for each line in the router
(Management Information Base) Information is collected periodically and its time fluctuation is displayed in a graph. As the MIB information, only information that can be measured in IP packet units, such as the number of IP bytes and the number of TCP bytes, is targeted. Also,
In order to estimate the failure factor based on the report from the user, Sni
Detailed analysis of individual communication is performed using a protocol analyzer such as fffer [Network Associates, Inc.]. These tools are installed at positions where the target communication can be monitored, collect packets transmitted and received by both hosts, and analyze parameters according to the protocol of each packet.

[0004]

In the operation using the above-mentioned MRTG, only rough values such as the line usage rate at the IP level are used for analyzing the traffic volume and the communication performance. No traffic volume or quality could be seen. The above Sniffer
The cause investigation was mainly based on the report from the user who used it, but if the communication log was not taken, the problem may not always be reproduced even if the user tries the communication operation again. There was a point. Further, when a long-term communication log is taken, there is a problem that it is difficult to quickly detect a performance failure from an enormous log and to identify a cause of the performance failure.

An object of the present invention is to solve the above-mentioned problems of the prior art and to provide a network diagnostic apparatus capable of quickly estimating a failure factor based on traffic analysis.

[0006]

In order to achieve the above-mentioned object, the present invention provides a network diagnosing apparatus for diagnosing a performance failure of a network having a known configuration.
Statistical information collecting means for collecting, at least for each application, statistical information on traffic on a predetermined line constituting a network; TCP segment header information collecting means for collecting TCP segment header information from traffic on the line; A flow extracting unit for selectively extracting a diagnosis target flow satisfying a predetermined condition on a per application basis based on the statistical information and the network configuration; and a performance failure of the extracted diagnosis target flow in the statistical information and the TCP segment. Diagnostic means for diagnosing based on the header information.

[0007] According to the above-described features, since the traffic statistical information for each application is collected, it is possible to analyze the tendency of the traffic generated by each user and the communication performance. Further, by extracting a host and a communication time at which a communication performance is likely to be a problem, it is possible to specify a location of a performance failure. In addition, based on the TCP segment header, it is possible to analyze the actual flow control and congestion control of TCP, so that it is possible to analyze the TCP communication status at the time of a performance failure and identify the cause of the performance failure. Become.

[0008]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS The present invention will be described below in detail with reference to the drawings. FIG. 1 is a block diagram showing a connection example of a network diagnostic device 1 to which the present invention is applied to a star network, and FIG. 2 is a functional block diagram of the network diagnostic device 1.

In FIG. 1, LAN 1 has a plurality of routers R
It is connected to LANs 2, 3, and 4 via 1, R2, R3, and R4. In the present embodiment, LAN1 and LAN2,
The network diagnostic device 1 is connected to a line L6 between the routers R1 and R2 to monitor traffic between the routers R3 and R4.

In the network diagnostic apparatus 1, as shown in FIG. 2, the statistical information collecting unit 101 monitors packets flowing on the line L6 for a long time (for example, one week), and accumulates traffic statistical information in real time. I do. As statistical information, the number of IP bytes, the number of TCP connections, the TCP connection duration, the number of TCP retransmission bytes, the average throughput [= (the number of TCP data bytes−
TCP retransmission byte count) / average of TCP connection duration by time] etc. at regular intervals (eg, every 10 minutes)
Will be collected.

In this embodiment, a state transition table is internally managed in order to collect information for each TCP connection such as the duration and throughput of the TCP connection. In addition, a high-speed hash search is performed on the assumption that hundreds of thousands to several millions of TCP connections and statistical information of host pairs (pairs of incoming and outgoing IP addresses) are managed.

In the offline analysis, in addition to a filter function for extracting only one or both of the IP address and the information of the protocol / application type specific to the subnet ID, an address having a large statistical information such as the number of IP bytes and the number of retransmitted bytes is used. It has a sort function to sort in order. With these functions, it is possible to analyze overall traffic fluctuations and trends and to obtain information such as the time of occurrence of traffic considered as a performance failure and the host.

[0013] TCP segment header information collection unit 102
Monitors the traffic on the line L6 for a long time and extracts only the header portion of the TCP segment from the TCP traffic and accumulates it.

In the offline analysis, the TCP communication performed between both hosts is emulated by emulating TCP communication performed between one-to-one or one-to-many hosts.
Analyze the internal operation of the P module. In this embodiment,
By processing each TCP segment as an input / output event for both systems, an operation according to TCP specifications such as state / internal variables and flow control / congestion control is estimated for each TCP connection. . At this time, processing such as insertion of a delay time and exchange of events is automatically performed so that the event order in each host can be correctly estimated.

The network configuration information registration unit 103 includes:
The configuration information related to the network shown in FIG. 1 includes a subnet ID assigned to each LAN, a bandwidth (bit / second) for each line, and a route (line connection configuration) from a traffic monitoring point to each LAN, and an input interface. The information is registered in advance from the outside via 104.

The subnet ID is s1. s2.0.
Network ID, written in the form of 0/16
(S3.s4.0.0) and the number of mask bits (16)
(S1 to s4 are integers of 0 to 255). In this case, s3. s4. *. All IP addresses that are * (* may be anything) indicate that they are included in the corresponding subnet.

Based on the network configuration information registered in the network configuration information registration unit 103 and the statistical information collected by the statistical information collection unit 101, the flow extraction unit 105 performs continuous traffic by the same application or Characteristic traffic such as traffic with a large amount of data by the same application is extracted as a flow to be diagnosed.

The flow classifying unit 106 classifies the extracted flows to be diagnosed into the following five groups (1) based on at least one of the traffic amount, the bandwidth usage rate, the retransmission rate, and the throughput. To (5). (1) Band occupancy flow (2) Real-time flow (3) Throughput limited flow (4) LAN fault flow (5) Traffic instantaneous interruption flow Diagnosis unit 107 is a bandwidth occupation flow diagnosis unit 107a, a real-time flow diagnosis unit 107b, a throughput Restricted flow diagnosing unit 107c, fault flow diagnosing unit in LAN 107d
Each flow diagnosis unit diagnoses whether or not a performance failure has occurred in each of the flows classified into each of the groups.

The countermeasure effect calculating section 108 is provided with the diagnostic section 10
7, the ratio (B) of the throughput B after the countermeasure against the performance fault and the throughput A before the countermeasure against the performance fault is obtained.
/ A) is calculated as the effect of the measure against the performance failure. The calculation result is notified to the operator via the output interface 109.

Next, the operation of the present embodiment will be described in detail with reference to the flowcharts of FIGS.

In step S1 of FIG. 3, a timer (for example, one week) for measuring the traffic monitoring time is started. In step S2, the statistical information collecting unit 1
01 collects on-line time variation such as traffic volume, retransmission rate, average throughput, and the like for each host and each application as statistical information on traffic on the line L6.

Further, the TCP segment header information collecting unit 102 extracts only TCP traffic from the traffic on the line, cuts out the header portion of the TCP segment, and stores it. Collection of statistical information and TCP
The operation of storing the header portion of the segment is continued until a timeout of the timer is detected in step S3.

When a time-out is detected in step S3 and necessary data is prepared, in step S4,
The flow extraction unit 105 determines traffic fluctuations for each line and traffic for each host pair based on network configuration information registered in the network configuration information registration unit 103 in advance and statistical information collected by the statistical information collection unit 101. The amount is analyzed, and continuous traffic by the same application or traffic with a large amount of data by the same application is extracted as a diagnosis target flow.

In step S5, the flow classification unit 10
6, by analyzing time fluctuations such as the bandwidth usage rate and retransmission rate of each diagnosis target flow extracted in the above procedure, to classify each diagnosis target flow into the following groups (1) to (5),
Perform unique processing for each. FIG. 9 is a diagram schematically illustrating the characteristics of each group. Differences in hatching indicate different applications.

(1) Band occupancy flow The number of IP bytes per fixed time by the application is:
A flow in which the time that is approximately equal to the number of IP bytes that can be transferred in the bandwidth (that is, the bandwidth utilization rate approaches 100%) continues for a long time is classified as a bandwidth occupied flow.

(2) Real-time flow A flow of an application having a high real-time property such as HTTP generated at the same time as the bandwidth occupation flow is classified as a real-time flow.

(3) Flow Limiting Throughput A flow in which the total number of IP bytes of all applications does not occupy the bandwidth, and the bandwidth usage rate of the same application for a certain period of time is almost constant for a long time. It is classified as a throughput-limited flow.

(4) Intra-LAN Failure Flow A flow having a high retransmission rate, which occurs at a time when the bandwidth is not occupied, is classified as an intra-LAN failure flow.

(5) Traffic instantaneous interruption flow A flow in which there is almost no traffic for a short period during continuous data transfer is classified as a traffic instantaneous interruption flow.

FIG. 4 is a flowchart showing the processing (step S10) for each of the flows classified as the band occupied flows. In step S11, the band occupied flow diagnosis unit 107a determines the range of the time of occurrence of the band occupied flows. Is specified, and the number of host pairs (host pairs) having a large transfer data amount (the number of IP bytes) is determined. If the number of host pairs with a large transfer data amount is one, in step S12, it is diagnosed as a performance failure of bandwidth occupation (first performance failure) due to a large amount of communication by a single host pair.

On the other hand, if there are a plurality of host pairs having a large transfer data amount, in step S13, a performance failure (second performance failure) due to the increase in the number of users is diagnosed.

In step S14, the countermeasure effect calculation unit 108 calculates the effect obtained by performing the bandwidth expansion as a measure against the first and second performance failures. That is, when the band of the bottleneck line in the network is A (bit / second) and the band after expansion is B (bit / second), the effect of the band expansion processing is calculated as B / A.

However, if the bandwidth is occupied by one TCP connection, the reception window size W
(Byte) and RTT (Round Trip Tim)
e) Considering the throughput limitation (limited to W * 8 / T) by the flow control obtained from T (second) of W), W * 8
The effect in the case of / T <B is calculated as W * 8 / (T * A).

FIG. 5 is a flowchart showing the processing (step S20) for each flow classified as a real-time flow. In step S21, the throughput of the TCP connection with the largest transfer data amount is calculated. The throughput is calculated by (transfer data amount / TCP connection duration).

In step S22, the calculation result of the throughput is transmitted to the real-time flow diagnosis unit 107b by the bottleneck line on the path to the host.
(The line with the smallest bandwidth in the route). If the throughput is extremely smaller than the bandwidth of the bottleneck line, in step S23, the flow is diagnosed as a performance fault (third performance fault) affected by the bandwidth occupied flow.

In step S24, the RTT of the time during which the bottleneck line is not congested with respect to the third performance fault is set.
Is given by the countermeasure effect calculation unit 108. That is, the current throughput of the TCP connection with the largest data transfer amount is S (bi
t / sec), R of the time when the bottleneck line is not congested
TT is T (seconds), and the current reception window size is W (by
The effect when te) is calculated as W * 8 / (T * S).

FIG. 6 is a flowchart showing processing (step S30) for each flow classified as a throughput limited flow. In step S31, the amount of data that can be continuously transmitted without waiting for an acknowledgment (ACK) And the UnACKed data size indicating the amount of data that has not been acknowledged (ACK) is examined by the throughput restriction flow diagnostic unit 107c.

Here, if the UnACKed data size is always smaller than the window size, in step S32, it is diagnosed as a performance obstacle (fourth performance obstacle) of the throughput limitation by the application. On the contrary,
If the UnACKed data size and the window size are substantially the same, in step S33, it is diagnosed as a performance obstacle (fifth performance obstacle) of the throughput limitation based on the TCP flow control. If the window size and the UnACKed data size repeatedly increase and decrease, in step S34, a performance failure due to bandwidth occupation of a small bandwidth line not included in the network configuration information (sixth performance failure) Is diagnosed.

In step S35, the UnACKed data size U (b
yte) is equal to the window size W (byte), and the effect is calculated as W / U.

In step S36, the effect of expanding the window size from the current W1 to W2 with respect to the fifth performance fault is calculated as W2 / W1.

However, the effect of increasing the window size is limited, and the bandwidth of the bottleneck line is A (bi).
In the case of (t / sec), it can be said that there is an effect on window expansion up to A * T / 8 <W2 (byte) using RTT: T (sec) at the time of non-congestion. Therefore, A * T / 8 <W
In the case of 2, the effect is A * T / (8 * W1).

In step S37, the effect is calculated when no sudden drop has occurred for the sixth performance fault.
That is, at the time of the sixth performance failure, the window size repeatedly changes within a range from the minimum value (usually, MSS = 1460 bytes) to the value W1 at the time of the sudden drop. Therefore, assuming that this value is always equal to the reception window size W2, the effect is calculated as 2 * W2 / (W1 + 1460).

FIG. 7 is a flowchart showing a process (step S40) for each flow classified as a failure flow in the LAN. In step S41, the ACK segment for the DATA segment arrives after the retransmitted DATA segment. The frequency of occurrence of unnecessary phenomena (unnecessary retransmissions) is investigated. In step S42, the LA
The in-N fault flow diagnosis unit 107d compares the retransmission frequency with the reference frequency based on the result of the investigation, and if the retransmission frequency exceeds the reference frequency, in step S43, it is determined that there is a failure in the implementation of TCP on the transmission side. Diagnosed as a performance failure (seventh performance failure).

In step S44, the effect in the case where retransmission does not occur for the seventh performance failure is calculated. That is, assuming that the throughput at the time of the performance failure is S (bit / second), the throughput in the case where there is no unnecessary retransmission is determined by the flow control. Therefore, the effect is calculated as W * 8 / (T * S) using the RTT: T (second) at that time and the reception window size W.

FIG. 8 is a flowchart showing a process (step S50) for each flow classified as a traffic instantaneous interruption flow. In step S51, the TCP communication at the momentary interruption time is performed by the traffic instantaneous interruption flow diagnosis unit 107e. Investigated in If it is determined in step S52 that the persistent probe frequently occurs, in step S53, it is diagnosed as a performance failure (eighth performance failure) due to insufficient processing capability of the receiving host.

In step S54, the effect of taking a measure to expand the band for the eighth performance failure is calculated.
That is, the total transfer time is t1 (second), and the instantaneous interruption time is t2.
The effect when (seconds) is set is calculated as t1 / (t1-t2).

According to this embodiment, traffic statistical information is collected for each host and each application.
It is possible to analyze the tendency of traffic generated by individual users and the communication performance. Further, by extracting a host and a communication time at which communication performance is likely to be problematic, it is possible to specify a location of a performance failure. Furthermore, since the actual TCP communication can be analyzed in accordance with communication procedures such as flow control and congestion control, by analyzing the TCP communication status at the time of a performance failure, the performance failure is analyzed. Can be identified.

FIG. 10 is a block diagram of a second embodiment of the present invention. The same reference numerals as those described above denote the same or equivalent parts.

In the first embodiment described above, the integrated network diagnostic device 1 is used as shown in FIG. 1, but in the second embodiment, a general-purpose performance monitor 2 and a TCP analyzer 3 are used. By combining with the personal computer 4, the same function as that of the network diagnostic device 1 is realized.

The performance monitor 2 mainly includes the functions of the statistical information collection unit 101, the network configuration information registration unit 103, and the flow extraction unit 105 described with reference to FIG. The TCP analyzer 3 mainly has a function of the TCP segment header information collection unit 102. The personal computer 4 mainly functions as the flow classification unit 106 and the diagnosis unit 107.

As the performance monitor 2, for example, a “traffic monitoring device” (Japanese Unexamined Patent Application Publication No.
No. 1-252111) can be adopted. As the TCP analyzer 3, "Internet-compatible link monitoring method" (Japanese Patent Laid-Open No.
No. 8) can be employed.

[0052]

According to the present invention, the following effects are achieved. (1) Since traffic statistical information is collected for each host and each application, it is possible to analyze the tendency of traffic generated by each user and the communication performance. (2) By extracting the host and the communication time that are likely to have a problem in the communication performance, it is possible to specify the location of the performance failure. (3) Since the actual TCP communication can be analyzed in accordance with communication procedures such as flow control and congestion control, the performance of the TCP communication can be analyzed by analyzing the TCP communication status when a performance failure occurs. It is possible to identify the cause of the failure.

[Brief description of the drawings]

FIG. 1 is a block diagram showing an example of connection of a network diagnostic device to a star network to which the present invention has been applied.

FIG. 2 is a functional block diagram of the first embodiment of the network diagnostic device;

FIG. 3 is a flowchart showing an operation of the first embodiment.

FIG. 4 is a flowchart showing a method of diagnosing a bandwidth occupation flow.

FIG. 5 is a flowchart showing a method for diagnosing a real-time flow.

FIG. 6 is a flowchart illustrating a method of diagnosing a throughput restriction flow.

FIG. 7 is a flowchart illustrating a method of diagnosing a failure flow in a LAN.

FIG. 8 is a flowchart showing a method of diagnosing a traffic momentary interruption flow.

FIG. 9 is a diagram showing classification criteria of a diagnosis target flow.

FIG. 10 is a block diagram of a second embodiment.

[Explanation of symbols]

DESCRIPTION OF SYMBOLS 1 ... Network diagnostic apparatus, 2 ... Performance monitor, 3 ... TCP analyzer, 4 ... Personal computer, 101 ... Statistical information collection part, 102 ... TCP segment header information collection part, 103 ... Network configuration information registration part, 105 ... Flow extraction part , 106... Flow classification unit,
107: diagnosis unit, 108: countermeasure effect calculation unit

 ──────────────────────────────────────────────────続 き Continuing from the front page (72) Inventor Toshihiko Kato 2-1-15 Ohara, Kamifukuoka-shi, Saitama Inside Cadedy Research Institute Inc. (72) Inventor Koji Nakao 2-1-15 Ohara, Kamifukuoka-shi, Saitama 5K030 HA08 HB11 LA02 LC03 MB09 MB10 MC06 MC07 MC08 MC08 5K035 DD01 EE25

Claims (10)

[Claims] 1. A network diagnostic device for diagnosing a performance failure of a network having a known configuration, comprising: a statistical information collecting unit for collecting at least statistical information on traffic on a predetermined line configuring the network for each application; TCP segment header information collecting means for collecting TCP segment header information from the traffic on the line, and selectively extracting a diagnosis target flow satisfying a predetermined condition on a per-application basis based on the statistical information and the network configuration. An apparatus for diagnosing a network, comprising: flow extraction means; and diagnosis means for diagnosing a performance failure of the extracted flow to be diagnosed based on the statistical information and header information of a TCP segment. 2. A countermeasure effect that calculates a ratio (B / A) of the throughput B after the countermeasure against the performance fault and the throughput A before the countermeasure against the performance fault as an effect of the countermeasure against the performance fault based on the diagnosis result by the diagnosis means. The network diagnostic device according to claim 1, further comprising a calculating unit. 3. Classification means for classifying a flow extracted by the flow extraction means into one of a plurality of groups based on at least one of a traffic amount, a bandwidth usage rate, a retransmission rate, and a throughput. The network diagnosis apparatus according to claim 1, wherein the diagnosis unit diagnoses each diagnosis target flow for each of the classified groups. 4. The network diagnosis apparatus according to claim 1, wherein the flow extracting unit extracts continuous traffic by the same application as the flow. 5. The network diagnosis apparatus according to claim 1, wherein the flow extracting unit extracts traffic having a large data amount by the same application as the flow. 6. The classifying means classifies a flow to be diagnosed in which a high bandwidth usage rate continues as a bandwidth occupied flow, wherein the diagnostic means classifies a bandwidth occupied flow based on communication between one host pair as a first performance. The network diagnosis apparatus according to claim 3, wherein the network diagnosis apparatus diagnoses a failure and diagnoses a bandwidth occupation flow based on communication between a plurality of host pairs as a second performance failure different from the first performance failure. . 7. The classifying unit classifies a flow to be diagnosed of an application having a high real-time property generated at the same time as a band-occupied flow in which a high band usage rate continues, into a real-time flow. 4. The network diagnosis apparatus according to claim 3, wherein a real-time flow that is extremely small compared to the bandwidth of the bottleneck in the network is diagnosed as the third performance failure. 8. The diagnostic apparatus according to claim 1, wherein the total number of IP bytes of all applications does not occupy a band, and a state in which a band usage rate by a single application for a certain period of time is substantially constant continues for a long time. The target flow is classified into a throughput-limited flow, and the diagnostic means determines that the UnACKed data size indicating the amount of data not acknowledged (ACK) is the window size indicating the amount of data that can be continuously transmitted without waiting for an acknowledgement. A smaller throughput-limited flow is diagnosed as a fourth performance obstacle, and a throughput-limited flow having the same UnACKed data size and window size is diagnosed as a fifth performance obstacle.
4. The network diagnostic apparatus according to claim 3, wherein a throughput-restricted flow in which the Ked data size repeatedly increases and decreases is diagnosed as a sixth performance fault. 9. The classification means classifies a flow to be diagnosed having a high retransmission rate as a faulty flow in a LAN at a time when a bandwidth is not occupied, and the diagnosis means determines that an ACK segment for a data segment is larger than a retransmission data segment. 4. The network diagnosis apparatus according to claim 3, wherein a fault flow in the LAN, which frequently arrives later, is diagnosed as a seventh performance fault. 10. The classification means classifies a flow to be diagnosed in which there is a short period of time during which there is almost no traffic during a continuous data transfer into a traffic instantaneous interruption flow. 4. The network diagnostic device according to claim 3, wherein a traffic instantaneous interruption flow in which a persistent probe frequently occurs is diagnosed as a seventh performance failure.