Communication monitoring device, communication monitoring method, and communication monitoring program

Abstract

A communication monitoring device (10) according to the present invention comprises: a monitoring probe (11) that detects, from a duplicate packet, abnormality information of a device to be monitored; and a controller (21) that determines a priority based on the abnormality information. The monitoring probe comprises a fault monitoring unit (17) and a hash operation unit (18). The fault monitoring unit reflects a difference between normal packet data acquired in advance from the duplicate packet and known or predicted abnormal packet data in the normal packet data. The hash operation unit calculates a first hash value from the packet data in which the difference is reflected. When the first hash value is registered in the fault monitoring unit and the duplicate packet is inputted to the monitoring probe, the hash operation unit calculates a second hash value of data extracted from the duplicate packet, and when the second hash value matches the first hash value, the fault monitoring unit transmits the abnormality information to the controller.　Thus, the present invention can provide a communication monitoring device capable of reducing calculation resources required for monitoring the fault of a communication network.

Description

Communication monitoring device, communication monitoring method, and communication monitoring program

[0001] The present invention relates to a communication monitoring device, a communication monitoring method, and a communication monitoring program for monitoring a communication network.

[0002] Advances in cloud technology have led to growing demand for data centers of telecommunications service providers to form hybrid infrastructures linked with public clouds, and to provide safe, secure, and easy-to-use services to other telecommunications service providers, such as content distribution.

[0003] However, building an infrastructure that spans multiple communication networks poses challenges, such as increased testing time and more complex operations before launching the service. Furthermore, with conventional technology, it is difficult to identify the scope of impact caused by changes to device or service settings, or to isolate the cause of a failure that spans multiple communication networks. Therefore, a technology that enables rapid identification of the cause of a failure is needed.

[0004] FIG. 12 shows a conventional communication monitoring device 51 that monitors data flowing through a communication network. Hereinafter, a "flow" refers to a collection of packets flowing through a communication network that share the same rules, combining source and destination MAC addresses, IP addresses, ports, etc. In the monitoring system described in Non-Patent Document 1, a header analysis unit 52 first inputs mirrored packets from the monitored communication network and analyzes the packet headers. Next, a flow identification unit 53 compares the input packets with the flow rules registered in the rule table of the flow identification unit 53 to identify the flow. Next, a statistical information visualization unit 54 tallys up the number of packets / bytes for each flow that matches the rule and visualizes the communication status as statistical information. Furthermore, a capture function unit 55 converts packets of a flow specified by an administrator into a capture file.

[0005] Ikeda et al., "Virtualized Traffic Monitoring System with Built-in Hardware Accelerator (1) - System Architecture for Visualizing Traffic," Institute of Electronics, Information and Communication Engineers General Conference, March 2020.

[0006] In conventional backbone communication networks, as shown in Fig. 12, a measure is widely taken to duplicate monitored devices and software to maintain communication services even if a failure occurs in the active system 4. For example, if a failure occurs in the active system 4, the communication monitoring device detects the occurrence of some kind of problem, such as a communication interruption or a change in communication volume, and activates automatic switching to the standby system 5 to restore normal communication.

[0007] However, in recent large-scale communication failures, abnormal operation within the monitored device or software can prevent normal switching from the active system 4 to the standby system 5. Even if a normal state is detected, the monitored device or software may actually be in an abnormal state, preventing normal switching. In this way, increased computing resources are required for the monitored device or software itself to correctly identify the abnormal operation as an abnormal state, autonomously eliminate the cause of the failure, and perform normal switching. Furthermore, administrators must isolate and address the problem leading to the cause of the abnormal state, which can take a long time to restore normal operation, exacerbating the damage.

[0008] In order to solve the above-mentioned problems, a communication monitoring device according to the present invention is a communication monitoring device that monitors a monitored device that sends and receives packets, and includes a monitoring probe that detects abnormality information about the monitored device from a duplicate packet of the packet, and a controller that determines a priority based on the abnormality information, the monitoring probe including a fault monitoring unit and a hash calculation unit, the fault monitoring unit previously obtaining a difference between normal packet data obtained from the duplicate packet and known or predicted abnormal packet data, and reflecting the difference in the normal packet data, the hash calculation unit calculating a first hash value from the packet data reflecting the difference, the first hash value being registered in the fault monitoring unit, and when the duplicate packet is input to the monitoring probe, the hash calculation unit calculates a second hash value for data extracted from the duplicate packet, and when the second hash value matches the first hash value, the fault monitoring unit transmits the abnormality information to the controller.

[0009] a step of the fault monitoring unit calculating a difference between normal packet data acquired from the duplicated packet and known or predicted abnormal packet data, and reflecting the difference in the normal packet data; a step of the hash calculation unit calculating a first hash value from the packet data in which the difference is reflected; a step of the fault monitoring unit registering the first hash value; a step of the hash calculation unit calculating a second hash value for data extracted from the duplicated packet when the duplicated packet is input to the monitoring probe; a step of the fault monitoring unit comparing the second hash value with the first hash value; and a step of the fault monitoring unit transmitting the abnormality information to the controller when the second hash value matches the first hash value.

[0010] a step of the fault monitoring unit calculating a first hash value from the packet data in which the difference is reflected; a step of the fault monitoring unit registering the first hash value; a step of the hash calculation unit calculating a second hash value for data extracted from the duplicated packet when the duplicated packet is input to the monitoring probe; a step of the fault monitoring unit comparing the second hash value with the first hash value; and a step of the fault monitoring unit transmitting the abnormality information to the controller when the second hash value matches the first hash value.

[0011] According to the present invention, it is possible to provide a communication monitoring device, a communication monitoring method, and a communication monitoring program that can reduce the computational resources required to monitor faults in a communication network including communication devices, and also to detect abnormalities in devices or settings that may cause faults in the communication network at an early stage.

[0012] FIG. 1 is a schematic diagram showing an example of the configuration of a communication network including a communication monitoring device according to a first embodiment of the present invention. FIG. 2 is a block diagram showing the configuration of the communication monitoring device according to the first embodiment of the present invention. FIG. 3 is a schematic diagram for explaining the operation of the communication monitoring device according to the first embodiment of the present invention. FIG. 4 is a flowchart for explaining a communication monitoring method according to the first embodiment of the present invention. FIG. 5 is a flowchart for explaining the communication monitoring method according to the first embodiment of the present invention. FIG. 6 is a flowchart for explaining the communication monitoring method according to the first embodiment of the present invention. FIG. 7A is a schematic diagram for explaining the operation of the communication monitoring device according to the first embodiment of the present invention. FIG. 7B is a schematic diagram for explaining the operation of the communication monitoring device according to the first embodiment of the present invention. FIG. 7C is a schematic diagram for explaining the operation of the communication monitoring device according to the first embodiment of the present invention. FIG. 8 is a flowchart for explaining the communication monitoring method according to the first embodiment of the present invention. FIG. 9 is a schematic diagram for explaining the operation of the communication monitoring device according to the first embodiment of the present invention. FIG. 10A is a schematic diagram for explaining the operation of the communication monitoring device according to a second embodiment of the present invention. FIG. 10B is a schematic diagram for explaining the operation of the communication monitoring device according to the second embodiment of the present invention. Fig. 10C is a schematic diagram for explaining the operation of a communication monitoring device according to a second embodiment of the present invention. Fig. 10D is a schematic diagram for explaining the operation of a communication monitoring device according to a second embodiment of the present invention. Fig. 10E is a schematic diagram for explaining the operation of a communication monitoring device according to a second embodiment of the present invention. Fig. 11 is a diagram showing an example of the configuration of a computer according to an embodiment of the present invention. Fig. 12 is a schematic diagram showing an example of the configuration of a communication network having a conventional communication monitoring device.

[0013] First Embodiment A communication monitoring device and method according to a first embodiment of the present invention will be described with reference to FIGS.

[0014] 1 shows the configuration of a communication network using a communication monitoring device 10 according to this embodiment. The communication network is made up of the communication monitoring device 10 and a monitored communication network 1 monitored by the communication monitoring device 10. The monitored communication network 1 is made up of N (N=1 to N) monitored sub-communication networks 2_1 to 2_N, and each monitored sub-communication network is provided with a monitored communication device 3_1 to 3_N.

[0015] Hereinafter, a person who monitors the monitored communication network 1 using the communication monitoring device 10 will be referred to as an "administrator," and a person who uses the monitored communication network 1 will be referred to as a "user."

[0016] The communication monitoring device 10 includes monitoring probes 11_1 to 11_N and a controller 21.

[0017] The monitoring probes 11_1 to 11_N are connected to the monitored communication devices 3_1 to 3_N, respectively, and monitor mirrored packets (hereinafter also referred to as "duplicate packets") from the monitored sub-communication networks 2_1 to 2_N in the monitored communication network 1.

[0018] The controller 21 collects information indicating the possibility of an abnormality in the monitored device 3 detected by the monitoring probe 11 (hereinafter referred to as "abnormality information") and notifies the administrator of the abnormality information.

[0019] The monitoring probe 11 and the controller 21 can be configured as software that runs on a general-purpose server, but some of the functions may be configured as reconfigurable logic hardware such as an FPGA (Field Programmable Gate Array).

[0020] 2 shows an outline of the configuration of the monitoring probe 11 and the controller 21. The monitoring probes 11_1 to 11_N have the same configuration, but the sources of the mirroring packets input to the monitoring probes 11_1 to 11_N (monitored sub-communication networks 2_1 to 2_N) are different.

[0021] The monitoring probe 11 includes a packet analysis unit 12 , a flow identification unit 13 , a statistical information collection unit 14 , a capture function unit 15 , and a fault recovery memory 16 .

[0022] The packet analysis unit 12 analyzes (extracts) the header or payload.

[0023] The flow identification unit 13 includes a fault monitoring unit 17, a hash calculation unit 18, and a rule matching unit 19 having a rule table.

[0024] The flow identification unit 13 calculates a hash value for the input packet using the hash calculation unit 18, compares the input packet with the flow rules registered in the rule table held by the rule matching unit 19, identifies the flow, and outputs the information to the statistical information compilation unit 14.

[0025] In addition, in the flow identification unit 13, the fault monitoring unit 17 detects abnormality information and transmits it to the controller 21. Details will be described later.

[0026] The statistical information collection unit 14 acquires statistical information for each target flow of packets that have been determined by the flow identification unit 13 to be a target flow of collection. The statistical information collection unit 14 outputs the statistical information to the notification and visualization interface unit 23. The statistical information includes communication volume such as the number of packets and the number of bytes.

[0027] The capture function unit 15 converts packets that match the preset conditions for the flow to be captured into a capture file, and outputs the generated capture file to the fault monitor unit 17.

[0028] The fault recovery memory 16 includes a fault information management unit 161 and a fault information storage unit 162 .

[0029] The fault information management unit 161 reads, writes, and stores information about known or predicted faults (hereinafter referred to as "fault information") in the fault information storage unit 162, and classifies and manages the fault information. The fault information includes known or predicted abnormal packet data. The fault information in the fault information management unit 161 may be set collectively via the notification and visualization interface unit 23 of the controller 21. The fault information management unit 161 also outputs the abnormal packet data to the fault monitoring unit 17.

[0030] Thus, unlike conventional configurations, the monitoring probe 11 is provided with a fault monitoring unit 17 inside the flow identification unit 13, and a fault countermeasure memory 16 having a fault information management unit 161 as a functional unit that works in conjunction with the fault monitoring unit 17.

[0031] The controller 21 includes a priority determination unit 22 and a functional unit related to notification and visualization. The functional unit related to notification and visualization includes a notification and visualization interface unit 23, a notification and visualization storage unit 24, and a notification and visualization unit 26. Details are described below.

[0032] The priority determination unit 22 in the controller 21 determines the confirmation priority (hereinafter also referred to as "priority") according to a predefined triage table based on the abnormality information from the multiple monitoring probes 11 and the abnormality information of the monitored device 3. Depending on the determination result, fault isolation information and clue information are output to the notification and visualization interface unit 23. Here, the "priority" indicates the degree of abnormality of the monitored device 3.

[0033] "Isolation information" is information for isolating (classifying) the cause of a failure. For example, it is information that suggests the cause of the failure, such as a location on the network, a part of the monitored device, a flow, or the settings of the monitoring equipment. For example, it is information that is isolated (classified) by priority (described below).

[0034] The "clue information" is information that serves as a clue for monitoring a failure in the monitored device 3. For example, it is packet data that is captured and saved by the capture function unit as data that may be abnormal (described later).

[0035] The notification and visualization interface unit 23 constitutes an interface for an administrator that controls each functional unit of the monitoring probes 11_1 to 11_N. The notification and visualization interface unit 23 receives fault isolation information and clue information, including priority, from the priority determination unit 22, and transmits information to the notification and visualization unit 26 based on this. To prevent information necessary for the administrator from being buried, filtering is performed, such as displaying or notifying only important information according to priority, and information necessary for notification and visualization is stored in the notification and visualization storage unit 24. Furthermore, isolation information and clue information can be set collectively for each of the monitoring probes 11_1 to 11_N as fault information in the fault information management unit 161 of the fault countermeasure memory 16, and the set fault information can be referenced collectively.

[0036] Furthermore, the notification / visualization interface unit 23 outputs information necessary for notification / visualization to the notification / visualization unit 26 via the CPU / memory 25 .

[0037] The notification / visualization interface unit 23 can typically be configured as a command line interface, but may also be configured as a GUI (Graphical User Interface) via a screen viewed by an administrator, or as an API (Application Programming Interface) called by an external program.

[0038] The notification and visualization unit 26 displays and notifies the information input from the notification and visualization interface unit 23 .

[0039] <Configuration of the fault monitoring unit> The detailed configuration of the fault monitoring unit 17 will be described with reference to Fig. 3. In the figure, dotted arrows indicate the flow of data when the fault monitoring unit is set up. In the figure, solid arrows indicate the flow of data when the fault monitoring unit detects an abnormality.

[0040] The fault monitor 17 includes a false negative elimination unit 171 , a control IF unit 172 , and an extraction unit 173 .

[0041] The extraction unit 173 extracts and defines abnormal communication pattern data that may cause a fault, based on the difference between abnormal packet data acquired from fault information stored in the fault information management unit 161 via the control IF unit 172 and normal packet data acquired from the capture function unit 15 of the monitoring probe 11. The extraction unit 173 reflects the extracted difference in the normal packet data.

[0042] The false negative elimination unit 171 registers the hash value calculated by the hash calculation unit 18 for the packet data reflecting the difference extracted by the extraction unit 173 .

[0043] When the false negative elimination unit 171 receives a mirrored monitored packet, it checks the received packet against a registered pattern and determines the possibility of a fault, based on the registered data (hash value) of the false negative elimination unit 171. If the result of the determination is that the packet matches an abnormal pattern, it sends abnormality information to the priority determination unit 22 of the controller 21 via the control IF unit 172.

[0044] <Communication Monitoring Method> A communication monitoring method according to this embodiment will be described with reference to FIGS.

[0045] In the communication monitoring device 10, multiple monitoring probes 11_1 to 11_N are placed in each monitored sub-communication network. Typically, one monitoring probe 11 is placed in each duplicated monitored device 3, or one monitoring probe 11 is placed in each duplicated base, and monitors mirrored packet data via a test access point. The monitoring position of the monitoring probe 11 does not matter whether it is inside or outside the monitored device 3, and the communication direction does not matter whether it is outward or inward.

[0046] FIG. 4 is a flowchart for explaining an outline of the communication monitoring method according to this embodiment.

[0047] First, the fault monitoring unit 17 is set (step S10).

[0048] Next, the fault monitoring unit 17 detects abnormality information (step S20).

[0049] Next, the priority determination unit 22 determines the priority (step S30).

[0050] Next, the notification and visualization IF unit notifies the notification and visualization I unit of the fault isolation information and clue information according to the priority (step S40).

[0051] Finally, the notification and visualization unit 26 displays and notifies the fault isolation information and / or clue information (step S50).

[0052] Each of the above processing steps will be described in detail below.

[0053] <Setting of the fault monitor unit (step S10)> The setting of the fault monitor unit 17 is repeated the same number of times as the number of pieces of fault information required. Details of the setting of the fault monitor unit 17 will be explained below with reference to Figures 3 and 5. Figure 5 shows a flowchart of the operation of the fault monitor unit 17.

[0054] First, the false negative elimination unit is initialized (step S11).

[0055] Next, the flow identification unit 13 acquires normal packet data in the monitored communication network based on the preset capture target from the capture function unit 15. Also, the flow identification unit 13 acquires abnormal packet data stored as fault information from the fault information management unit 161 of the fault countermeasure memory 16 via the control IF unit 172.

[0056] Subsequently, in the fault monitoring unit 17, the extraction unit 173 compares the normal packet data with the abnormal packet data, automatically extracts the difference data, and reflects the extracted difference data in the normal packet data (step S12).

[0057] Next, the hash calculation unit 18 calculates a hash value (first hash value) from the packet data reflecting the differential data extracted by the extraction unit 173. A multi-stage hash calculation is performed based on the extracted differential data and a predetermined seed value (step S13).

[0058] The hash calculation unit 18 performs multiple hash calculations on the differential data (see, for example, BH Bloom, "Space / Time Trade-Offs in Hash Coding with Allowable Errors," Commun. ACM, vol. 13, No. 7, pp. 422-426, 1970.) The hash values ​​obtained by the calculations are stored (registered) in a setting area (false negative elimination unit) 171 that is separate from the rule table in the flow identification unit 13 (step S14), as follows:

[0059] Next, if the registered abnormal pattern is not to be deleted, the hash value calculated as the abnormal pattern (first hash value) is registered in the false negative elimination unit 171 (steps S15 and S17).

[0060] When a registered abnormal pattern is deleted, after the deletion, the hash value (first hash value) calculated as the abnormal pattern is registered in the false negative elimination unit 171 (steps S15 to S17).

[0061] Here, as a method for configuring the false negative elimination of the fault monitoring unit 17, for example, the array of the false negative elimination unit 171 may be configured as an n-bit counter (L. Fan, et al., "Summary cache: A scalable wide-area Web cache sharing protocol," In Proceedings of SIGCOMM '98, 1998).

[0062] When the fault monitoring unit 17 has been configured as described above, it is ready to start fault monitoring.

[0063] <Detection of Abnormality Information (Step S20)> Next, the fault monitoring unit 17 detects abnormality information. Details of the method for detecting abnormality information will be described below with reference to Figures 3 and 6. Figure 6 shows a flowchart of the method for detecting abnormality information.

[0064] The following process is repeated the same number of times as the number of mirroring packets received from the monitored communication network.

[0065] First, mirroring packets are received (step S21). One of the mirroring packets is input to the packet analysis unit 12, and the other mirroring packet is input to the capture function unit 15, where it is acquired as a normal packet.

[0066] Next, the header analysis unit 121 of the packet analysis unit 12 analyzes the header of one of the mirroring packets and extracts data broken down into tuples (step S22).

[0067] Next, when analyzing the payload, the payload analysis unit 122 of the packet analysis unit 12 analyzes the payload and extracts data (steps S23 and S24). For example, this may be configured using a known DPI (Deep Packet Inspection) means.

[0068] Next, the packet data is input to the hash calculation unit 18 of the flow identification unit 13. The hash calculation unit 18 performs multiple stages of hash calculations based on the analyzed packet data and a predetermined seed value, and outputs a hash value to the false negative elimination unit 171 of the fault monitoring unit 17 (step S25).

[0069] The false negative elimination unit 171 of the fault monitoring unit 17 checks whether the calculated hash value (second hash value) for the header and / or payload corresponds to the hash value (first hash value) of the abnormal pattern registration data of the configured false negative elimination unit 171 (step S26).

[0070] If the patterns (hash values) match, the false negative elimination unit 171 instructs the capture function unit 15 to acquire packet data corresponding to the pattern as clue information (steps S27 and S28).

[0071] Furthermore, the false negative elimination unit 171 of the fault monitoring unit 17 transmits the abnormality information and clue information to the priority determination unit 22 of the controller 21 via the control IF unit 172 (step S29).

[0072] If the patterns do not match in step S27, the process returns to step S21, and the steps from receiving the mirroring packet (step S21) to checking the hash value (step S26) are repeated for the next data.

[0073] In this way, the fault monitor 17 detects abnormality information and transmits it to the priority determination unit 22 of the controller 21 .

[0074] In this embodiment, the abnormality information may be, for example, a hash value that matches in the comparison, i.e., a hash value of the abnormality pattern registration data. Alternatively, the abnormality information may be the abnormality pattern registration data that matches in the comparison. Alternatively, the abnormality information may be abnormal packet data that is linked to the abnormality pattern registration data that matches in the comparison.

[0075] <Determining Priority (Step S30)> Next, the priority determination unit 22 determines the priority based on the received abnormality information. 7A to 7C show an overview of the operation of the priority determination unit 22.

[0076] As a configuration for duplicating devices and software in a backbone communication network, for example, there are cases where duplicated monitored devices (Act and Sby in the figure) are used within the communication network of the same base as shown in Fig. 7A, and cases where monitored devices (A-Act and B-Act in the figure) are distributed across the communication networks of two bases A and B as shown in Fig. 7B. An example of a configuration in which monitoring probes 11 are placed in each device in a 1:1 ratio will be described below.

[0077] The priority determination unit 22 classifies the abnormality information using, for example, a triage table 221 shown in FIG. 7C, and assigns priorities to the fault isolation.

[0078] In prioritizing fault isolation, since it is difficult to quickly identify the cause of a fault using only the communication monitoring device 10 installed outside the monitored device, abnormality information emitted from the monitored device is used. The abnormality information from the monitored device is information obtained using known techniques such as checking the operating status using Ping (Packet Internet Groper), obtaining resource information using SNMP (Simple Network Management Protocol), detecting abnormalities using SNMP traps, and preventive maintenance techniques for monitored device failures using machine learning.

[0079] Furthermore, in order to prevent the monitored device from behaving as if it were normal even though it is in an abnormal state, making it difficult to identify the cause, abnormality information issued from the monitoring probe 11 is used.

[0080] In this way, by combining the abnormality information acquired from both the monitored device and the monitoring probe 11, the point of failure can be isolated according to priority while preventing the administrator from missing or overlooking any checks.

[0081] 8 is a flowchart showing the priority determination method in the priority determination unit 22. The priority determination unit 22 repeats the determination of the priority every time it receives abnormality information from the fault monitor unit 17. Details will be explained below.

[0082] First, if there is no abnormality notification from either the monitoring probe 11 or the monitored device, it is highly likely that communication is normal, so it is determined to be a true negative (TN) and no fault is suspected (steps S320 to S322). In this case, the isolation information "communication normal" or "no fault is suspected" is notified to the notification and visualization interface unit 23 (step S360).

[0083] In the triage table 221, the ratio of patterns corresponding to this judgment result to the total number of patterns (hereinafter referred to as the "judgment pattern ratio") is 1 / 16 (C11 in Figure 7C), and since this state should be maintained for a long period under normal conditions, notification may be omitted at the discretion of the administrator (dashed line in Figure 8).

[0084] Next, if there is no abnormality notification from the monitoring probe 11 but there is an abnormality notification from the monitored device 3, it is determined to be a false negative (FN) (steps S330, S331). The determination pattern ratio is 3 / 16 (C12 in FIG. 7C).

[0085] When a false negative (FN) is determined, the false negative removal unit 171 of the monitoring probe 11 will in principle not erroneously determine that there is no abnormality, so there is a possibility that the administrator has improperly (incorrectly) set the abnormality pattern (step S332).

[0086] Alternatively, the monitored device may have issued a false alarm or a simple alarm that does not reach the level of a fault (step S332). In this case, the administrator can easily check the status of the monitored device and take measures (settings) to prevent the simple alarm from being issued.

[0087] In the case of a false negative (FN), the notification and visualization interface unit 23 is notified of the isolation information, such as "improper monitoring probe settings" or "suspected false report from monitored device" (step S360). In this case, notification to the notification and visualization interface unit 23 (described later) may be omitted (dashed line in FIG. 8).

[0088] Next, if there is an abnormality notification from the monitoring probe 11 but no abnormality notification from the monitored device, it is determined to be a false positive (FP) (steps S340, S341). The determination pattern ratio in the triage table 221 is 3 / 16 (C13 in FIG. 7C).

[0089] When a false positive (FP) is determined, it is theoretically possible for the false negative elimination unit 171 of the monitoring probe 11 to erroneously determine that an abnormality exists. Therefore, the erroneous determination is judged based on whether the number of registered abnormality patterns exceeds the threshold value for the probability of false positives occurring (step S342). Erroneous determinations can be suppressed by increasing the number of hash calculation stages. It is also possible to set it so that no false positives caused by the monitoring probe 11 occur (probability of occurrence: zero). It is desirable to impose a limit on the allowable range.

[0090] Alternatively, if the monitored device is operating as if it were in a normal state despite being in an abnormal state (internal abnormal operation), this may develop into a serious problem (step S342).

[0091] In the case of a false positive (FP), the notification and visualization interface unit 23 is notified of the isolation information, such as "misjudgment of monitoring probe" or "suspected abnormality in monitored device" (step S360). In this case, the priority (high, medium, low, etc.) may be determined depending on the situation. Alternatively, the result may be determined as a false alarm.

[0092] Next, if an abnormality notification is received from both the monitoring probe 11 and the monitored device 3, it is highly likely that some kind of problem has occurred in the monitored device 3, and so it is determined to be a true positive (TP) (steps S350 and S351). However, since the determination pattern ratio is 9 / 16 (C14 in FIG. 7C ), and there are many applicable patterns, separating them is cumbersome, so the priority is further classified according to the degree of agreement between the determinations of the monitoring probe 11 and the monitored device 3.

[0093] If the abnormality notification relationships between the duplicated monitored devices A-Act (or Act) and B-Act (or Sby) and the monitoring probes A and B corresponding to each monitored device all match, the device is determined to have a higher priority TP (H) (steps S352 and S353). The determination pattern ratio for true positives (TP) in the triage table is 3 / 9. In this case, the notification / visualization interface unit 23 is notified of the isolation information "suspected abnormality in monitored device (priority: high)" (step S360).

[0094] If any of the abnormality notification relationships between the monitored device and the monitoring probe match (partial match), the device is determined to have a medium priority TP (M) (steps S354 and S355). The determination pattern ratio for true positives (TP) in the triage table is 4 / 9. In this case, the notification / visualization interface unit 23 is notified of the isolation information "monitored device suspected of abnormality (medium priority)" (step S360).

[0095] If the abnormality notification relationship between the monitored device and the monitoring probe does not match (mismatch), the device is determined to be of lower priority TP (L) (steps S356 and S357). The determination pattern ratio for true positives (TP) in the triage table is 2 / 9. In this case, the notification / visualization interface unit 23 is notified of "suspected abnormality in monitored device (priority: low)" as isolation information (step S360).

[0096] For true positives (TP), the ratio of judgment patterns for the top, middle, and bottom priorities is TP(H):TP(M):TP(L) = 3:4:2, and the classification information is notified to the notification / visualization interface unit 23 from the top priority (step S360).

[0097] In this way, the isolation information is notified to the notification and visualization interface unit 23 according to the priority (step S360). The isolation information includes information indicating whether or not a failure has occurred.

[0098] In addition to the isolation information, the capture function unit 15 outputs clue information required for investigating the cause at the instruction of the fault monitoring unit 17 (step S360). As clue information, the source / IP address, MAC address, IP address, port, and other information required by the administrator for the investigation can be extracted from the corresponding packet data and output.

[0099] <Operations of the Notification and Visualization Interface Unit 23 and the Notification and Visualization Unit 26 (Steps S30, S40)> The operations of the notification and visualization interface unit 23 and the notification and visualization unit 26 of the controller 21 will be described with reference to FIG.

[0100] The notification and visualization interface unit 23 notifies the notification and visualization unit 26 of the fault isolation information and clue information according to the priority via the CPU / memory 25. The notification and visualization unit 26 displays and notifies the notified fault isolation information and / or clue information.

[0101] Furthermore, the notification and visualization interface unit 23 acquires statistical information from the statistical information collection unit 14 .

[0102] The notification and visualization interface unit 23 also constitutes an interface for an administrator that controls each functional unit of the monitoring probe 11. The notification and visualization interface unit 23 allows fault information to be set collectively in the fault countermeasure memory 16 of each of the monitoring probes 11_1 to 11_N, and allows the set fault information to be referred to collectively.

[0103] Known or predicted fault information is read, written and stored as data in the fault countermeasure memory 16, and the fault information data is classified and managed.

[0104] The fault information data may have labels containing items necessary for the administrator, such as an ID, a date, information indicating whether the fault is known or predicted, and the cause.

[0105] Furthermore, fault information may be grouped and managed by generation in a desired management unit, such as in units of systems, system versions, or monitored sub-networks.

[0106] Furthermore, a packet capture file collected when a failure actually occurs may be linked to the failure information data as abnormal packet data and stored in a storage device.

[0107] The fault information management unit 161 of the fault countermeasure memory 16 outputs the abnormal packet data stored as fault information to the control IF unit 172 of the fault monitor unit 17. <Effect>

[0108] In a conventional communication monitoring device, the flow identification unit of the monitoring probe identifies the flow for an input packet, and uses a hash value only for identifying the flow.

[0109] On the other hand, in the communication monitoring device according to this embodiment, the flow identification unit is provided with a fault monitoring unit, which uses hash values ​​to detect abnormalities in the monitored device. In this way, hash values ​​are used not only to identify flows but also to detect abnormalities in the monitored device.

[0110] In this way, the communication monitoring device according to this embodiment makes use of the configuration of a conventional communication monitoring device, and does not require a large-scale configuration, but can detect abnormalities in the monitored device simply by adding a fault monitoring unit. This makes it possible to monitor faults in the monitored device with limited computational resources.

[0111] According to this embodiment, fault information is accumulated as data, faults can be monitored with limited computational resources, and the recurrence of faults can be prevented.

[0112] In addition, the system determines the confirmation priority by combining the monitored device and the monitoring probe and provides clues, allowing administrators to quickly isolate the cause of the failure, including internal abnormalities in the device.

[0113] In this way, by detecting abnormalities in equipment or settings that may cause failures early and accumulating information on past abnormalities as failure data, it is possible to provide a communications monitoring device that reduces the dependency on individuals for failure management and prevents recurrence.

[0114] Second Embodiment A communication monitoring device and method according to a second embodiment of the present invention will be described.

[0115] The operation of the priority determination unit in the communication monitoring device according to this embodiment will be described with reference to Figures 10A to 10E. The operation other than that of the priority determination unit is the same as in the first embodiment. Figures 10A to 10C show an overview of the operation of the priority determination unit according to this embodiment.

[0116] Software built on platforms such as public clouds may use configurations that take into account triplexing or more redundancy. For example, as shown in Figure 10A, triplexed monitored devices (Act, Sby1, and Sby2 in the figure) may be used within the communication network of the same site, or as shown in Figure 10B, monitored devices distributed across the communication networks of three sites A and B (A-Act, B-Act, and C-Act in the figure) may be used.

[0117] The flowchart for determining priority is the same as in the first embodiment, but as the number of monitoring probes and monitored devices increases, the size of the triage table 221_2 expands, as shown in Figure 10C. Figures 10D and 10E show details of the triage table 221_2. In this embodiment, the triage table determination pattern ratio is TN:FN:FP:TP = 1:7:7:49 (C21 to C24 in Figure 10C), and the determination pattern ratios for the high, medium, and low priorities are TP(H):TP(M):TP(L) = 7:30:12.

[0118] In determining the priority, a confirmation policy may be adopted in which the seven patterns of TP (H) that are a perfect match among the true positive TP determinations are given top priority, and attention is paid to internal abnormalities in the monitored device in the seven patterns of false positive (FP) determinations.

[0119] Each time one monitoring probe or monitored device is added, the triage table expands in square proportion. Even in a complex hybrid infrastructure spanning multiple communication networks in cooperation with a public cloud, a duplex or triplex configuration of monitored devices and software can be considered the basic configuration when focusing on a certain section. Therefore, the priority determination unit 22 may be managed by the controller 21 by dividing the system into sections. Alternatively, the monitoring system may be configured within a range that does not disrupt fault isolation.

[0120] According to this embodiment, in a communication network having multiplexed monitored devices, fault information is accumulated as data, faults can be monitored with limited computational resources, and the recurrence of faults can be prevented.

[0121] In addition, the system determines the confirmation priority by combining the monitored device and the monitoring probe and provides clues, allowing administrators to quickly isolate the cause of the failure, including internal abnormalities in the device.

[0122] 11 shows an example of the configuration of a computer 40 in a communication monitoring device according to an embodiment of the present invention. The communication monitoring device can be realized by a computer including a CPU (Central Processing Unit) 43, a storage device (storage section) 42, and an interface device 41, along with a program that controls these hardware resources. Here, the interface device 41 includes a control IF section 172 and a notification / visualization interface section 23. The CPU 43 executes the processing according to the embodiment of the present invention in accordance with the communication monitoring program stored in the storage device 42. In this manner, the communication monitoring program causes the communication monitoring device to function.

[0123] In the communication monitoring device according to the embodiment of the present invention, a computer may be provided inside the device, or at least part of the computer's functions may be realized using an external computer. The storage unit may also be an external storage medium 45, and the communication monitoring program stored in the storage medium 45 may be read and executed. Examples of the storage medium 45 include various magnetic recording media, magneto-optical recording media, CD-ROMs, CD-Rs, and various memories. The communication monitoring program may also be supplied to the computer via a communication line such as the Internet.

[0124] In the embodiments of the present invention, examples of the structure of each component in the configuration of the communication monitoring device, communication monitoring method, and communication monitoring program are shown, but the present invention is not limited to these. Any configuration that can demonstrate the functions and effects of the communication monitoring device, communication monitoring method, and communication monitoring program may be used.

[0125] It should be noted that the present invention is not limited to the above-described embodiments, and it is clear that many modifications and combinations can be made by a person having ordinary knowledge in the art within the technical concept of the present invention.

[0126] A part or all of the above-described embodiment or an example thereof can be described as, but is not limited to, the following supplementary notes.

[0127] (Supplementary Note 1) A communications monitoring device that monitors a monitored device that sends and receives packets, comprising: a monitoring probe that detects abnormality information related to the monitored device from a duplicate packet of the packet; and a controller that determines a priority based on the abnormality information, wherein the monitoring probe comprises a fault monitoring unit and a hash calculation unit, wherein the fault monitoring unit previously obtains a difference between normal packet data obtained from the duplicate packet and known or predicted abnormal packet data, and reflects the difference in the normal packet data, and the hash calculation unit calculates a first hash value from the packet data reflecting the difference, the first hash value is registered in the fault monitoring unit, and when the duplicate packet is input to the monitoring probe, the hash calculation unit calculates a second hash value for data extracted from the duplicate packet, and when the second hash value matches the first hash value, the fault monitoring unit transmits the abnormality information to the controller.

[0128] (Appendix 2) A communication monitoring device as described in Appendix 1, wherein the controller determines the priority based on the abnormality information input from the fault monitoring unit and other abnormality information issued from the monitored device.

[0129] (Supplementary Note 3) A communication monitoring method for monitoring a monitored device using a communication monitoring device comprising: a monitoring probe that detects abnormality information related to a monitored device from a duplicate packet of a packet sent or received by the monitored device; and a controller that determines a priority based on the abnormality information, wherein the monitoring probe comprises a fault monitoring unit and a hash calculation unit, the method comprising: a step in which the fault monitoring unit obtains in advance a difference between normal packet data obtained from the duplicate packet and known or predicted abnormal packet data, and reflects the difference in the normal packet data; a step in which the hash calculation unit calculates a first hash value from the packet data in which the difference is reflected; a step in which the fault monitoring unit registers the first hash value; a step in which, when the duplicate packet is input to the monitoring probe, the hash calculation unit calculates a second hash value for data extracted from the duplicate packet; a step in which the fault monitoring unit compares the second hash value with the first hash value; and a step in which the fault monitoring unit transmits the abnormality information to the controller when the second hash value matches the first hash value.

[0130] a step of the fault monitoring unit calculating a first hash value from the packet data in which the difference is reflected; a step of the fault monitoring unit registering the first hash value; a step of the hash calculation unit calculating a second hash value for data extracted from the duplicated packet when the duplicated packet is input to the monitoring probe; a step of the fault monitoring unit comparing the second hash value with the first hash value; and a step of the fault monitoring unit transmitting the abnormality information to the controller when the second hash value matches the first hash value.

[0131] (Appendix 5) A communication monitoring device as described in Appendix 2, wherein the monitoring probe further comprises a fault information management unit, which stores fault information, and the fault information includes the known or predicted abnormal packet data and at least one of isolation information and clue information determined according to the priority.

[0132] (Appendix 6) A communication monitoring device as described in Appendix 2, wherein the controller judges the priority to be true negative when the abnormality information indicates no abnormality and the other abnormality information indicates no abnormality, and determines that the isolation information indicates that the monitored device is not suspected of having a fault.

[0133] (Appendix 7) A communication monitoring device as described in Appendix 2, wherein the controller judges the priority to be a true positive when the abnormality information indicates an abnormality and the other abnormality information indicates an abnormality, and determines that the isolation information indicates that the monitored device is suspected of having a fault.

[0134] (Appendix 8) A communication monitoring device as described in Appendix 7, comprising multiplexed monitored devices and monitoring probes connected to each of the multiplexed monitored devices, and determining that the priority of a suspected fault in the monitored devices is high when the other abnormality information from the multiplexed monitored devices and the abnormality information from the monitoring probes connected to each of the multiplexed monitored devices all match.

[0135] (Appendix 9) A communication monitoring device as described in Appendix 7, comprising multiplexed monitored devices and monitoring probes connected to each of the multiplexed monitored devices, and determining that the priority of a suspected fault in the monitored device is low when the other abnormality information from the multiplexed monitored devices and the abnormality information from the monitoring probes connected to each of the multiplexed monitored devices do not all match.

[0136] The present invention relates to a communication monitoring device and can be applied to a technology for monitoring industrially applicable communication networks including communication devices.

[0137] 10 Communication monitoring device 11 Monitoring probe 21 Controller 17 Fault monitoring unit 18 Hash calculation unit

Claims

1. A communications monitoring device that monitors a monitored device that sends and receives packets, comprising: a monitoring probe that detects abnormality information related to the monitored device from a duplicate packet of the packet; and a controller that determines a priority based on the abnormality information, wherein the monitoring probe comprises: a fault monitoring unit; and a hash calculation unit, wherein the fault monitoring unit obtains in advance a difference between normal packet data obtained from the duplicate packet and known or predicted abnormal packet data, and reflects the difference in the normal packet data, the hash calculation unit calculates a first hash value from the packet data reflecting the difference, the first hash value is registered in the fault monitoring unit, and when the duplicate packet is input to the monitoring probe, the hash calculation unit calculates a second hash value for data extracted from the duplicate packet, and when the second hash value matches the first hash value, the fault monitoring unit sends the abnormality information to the controller.

2. A communication monitoring device according to claim 1, wherein said controller determines said priority based on said abnormality information input from said fault monitoring unit and other abnormality information issued from said monitored device.

3. A communications monitoring method for monitoring a monitored device using a communications monitoring device comprising a monitoring probe that detects abnormality information related to a monitored device from duplicate packets of packets sent and received by the monitored device, and a controller that determines priority based on the abnormality information, the monitoring probe comprising a fault monitoring unit and a hash calculation unit, the method comprising the steps of: the fault monitoring unit obtaining in advance a difference between normal packet data obtained from the duplicate packets and known or predicted abnormal packet data, and reflecting the difference in the normal packet data; the hash calculation unit calculating a first hash value from the packet data reflecting the difference; the fault monitoring unit registering the first hash value; when the duplicate packet is input to the monitoring probe, the hash calculation unit calculating a second hash value for data extracted from the duplicate packet; the fault monitoring unit comparing the second hash value with the first hash value; and when the second hash value matches the first hash value, the fault monitoring unit transmitting the abnormality information to the controller.

4. A communications monitoring program for causing a communications monitoring device to function, comprising: a monitoring probe that detects abnormality information related to a monitored device from duplicate packets of packets sent and received by the monitored device; and a controller that determines priority based on the abnormality information, wherein the monitoring probe comprises a fault monitoring unit and a hash calculation unit, the program causing the communications monitoring device to execute processing comprising: a step in which the fault monitoring unit obtains in advance the difference between normal packet data obtained from the duplicate packets and known or predicted abnormal packet data, and reflects the difference in the normal packet data; a step in which the hash calculation unit calculates a first hash value from the packet data reflecting the difference; a step in which the fault monitoring unit registers the first hash value; a step in which, when the duplicate packet is input to the monitoring probe, the hash calculation unit calculates a second hash value for data extracted from the duplicate packet; a step in which the fault monitoring unit compares the second hash value with the first hash value; and a step in which the fault monitoring unit transmits the abnormality information to the controller when the second hash value matches the first hash value.

Images