Network fault positioning method and device and storage medium

Abstract

The invention provides a network fault positioning method and device and a storage medium, relates to the technical field of communication, and can solve the problem that a network detection method proposed at present is not suitable for a real network scene and is relatively poor in practicability. The method comprises the following steps: establishing a network topology corresponding to a target network, and recording configuration information of each node in the network topology in a non-fault state; generating a fault event, injecting the fault event into the network topology, and recording configuration information of each node in the network topology after the fault event occurs; and on the basis of the configuration information of each node in the non-fault state, verifying the configuration information of each node after the fault event occurs, so as to position a fault node in each node. According to the invention, the fault node in the network topology corresponding to the real network scene can be positioned, and the practicability of fault detection is greatly improved.

Description

Technical Field

[0001] The present application relates to the field of communication technology, and in particular to a network fault locating method, device and storage medium. Background Art

[0002] With the rapid development of cloud computing technology, open cloud platforms (open stack) have been widely used in enterprises and data centers. However, in the application scenarios of open stack, the network topology is relatively complex, involving multiple virtualization technologies, network protocols and service deployment methods, which makes the prediction and location of network failures extremely difficult.

[0003] In the currently proposed network detection scheme, the virtual machine console uses the network detection protocol to determine whether the network nodes are connected. However, this scheme is not applicable to real network scenarios and has poor practicality. Summary of the invention

[0004] The present application provides a network fault location method, device and storage medium, which solves the problem that the currently proposed network detection method is not suitable for real network scenarios and has poor practicality. It can locate faulty nodes in the network topology corresponding to the real network scenario, greatly improving the practicality of fault detection.

[0005] In order to achieve the above objectives, this application adopts the following technical solutions:

[0006] In a first aspect, the present application provides a network fault locating method, the method comprising: establishing a network topology corresponding to a target network, and recording configuration information of each node in the network topology when in a non-fault state; generating a fault event, and injecting the fault event into the network topology, and recording configuration information of each node in the network topology after the fault event occurs; based on the configuration information of each node in a non-fault state, verifying the configuration information of each node after the fault event occurs, so as to locate the faulty node among the nodes.

[0007] In combination with the first aspect above, in a possible implementation manner, the configuration information includes multiple types of configuration items; and the method further includes:

[0008] In combination with the above-mentioned first aspect, in a possible implementation method, the method also includes: for each of the nodes, based on multiple types of configuration items when the node is in a non-faulty state, verifying each configuration item of the node after the fault event occurs one by one, obtaining a verification result, and locating the faulty node in the network topology based on the verification result.

[0009] In combination with the first aspect above, in a possible implementation manner, the configuration item includes at least one of the following: a topological relationship configuration of a node, an operating state configuration of a node, and a system configuration of a node.

[0010] In combination with the above-mentioned first aspect, in a possible implementation method, the method also includes: verifying whether the topological relationship configuration of the node after the occurrence of the fault event is the same as the topological relationship configuration in the non-fault state, and verifying whether the operating status configuration after the occurrence of the fault event is the same as the operating status configuration in the non-fault state, and verifying whether the system configuration after the fault event is the same as the system configuration in the non-fault state.

[0011] If the topological relationship configuration is different, the operating status configuration is different and / or the system configuration is different, the node is marked as a faulty node, and at least one first node other than the faulty node in the network topology is screened out; for each first node, it is verified whether the network connectivity status of the first node after the fault event occurs is the same as the network connectivity status in a non-faulty state.

[0012] If the network connectivity status is not the same, the first node is marked as a faulty node, and at least one second node other than the faulty node in at least one first node is screened out; for each second node, it is verified whether the system configuration of the second node after the fault event occurs is the same as the system configuration when the node is in a non-faulty state; if the system configurations are not the same, the second node is marked as a faulty node.

[0013] In combination with the above-mentioned first aspect, in a possible implementation, the method also includes: in the case where the node is a faulty node, based on the configuration information of the node in a non-faulty state, correcting the configuration information of the node after the fault event occurs, so that the node is changed from a faulty state to a non-faulty state; recording the correction plan of the node; the correction plan includes the correction process of the configuration information when the node is changed from a faulty state to a non-faulty state.

[0014] In combination with the above-mentioned first aspect, in a possible implementation method, after each faulty node in the network topology has been corrected, the method also includes: repeatedly performing the first operation until the availability of each node in the network topology has been detected; summarizing the availability of each node in the network topology to obtain the detection result of the network topology; the first operation includes: for each node in the network topology, detecting whether the network connectivity status of the node is a connected state; if it is a connected state, marking the availability of the node as available; otherwise, marking the availability of the node as unavailable.

[0015] In combination with the above-mentioned first aspect, in a possible implementation method, the fault event includes at least one of the following: a network logic fault event, a physical fault event, and a protocol fault event; wherein the network logic fault event includes a simulated configuration error event and a router port shutdown event; the physical fault event includes a power outage event and a network disconnection event; the protocol fault event includes a router fault event and a firewall parameter setting error event.

[0016] In a second aspect, the present application provides a network fault locating device, which includes: a processing unit; a processing unit, used to establish a network topology corresponding to the target network, and record the configuration information of each node in the network topology when it is in a non-fault state; the processing unit is also used to generate a fault event, and inject the fault event into the network topology, and record the configuration information of each node in the network topology after the fault event occurs; the processing unit is also used to verify the configuration information of each node after the fault event occurs based on the configuration information of each node in a non-fault state, so as to locate the faulty node among the nodes.

[0017] In combination with the above-mentioned second aspect, in a possible implementation method, the configuration information includes multiple types of configuration items; the processing unit is specifically used to: for each node in each node, based on multiple types of configuration items when the node is in a non-faulty state, verify each configuration item of the node after the fault event occurs one by one, obtain a verification result, and locate the faulty node in the network topology based on the verification result.

[0018] In combination with the above second aspect, in a possible implementation manner, the configuration item includes at least one of the following: a topological relationship configuration of a node, an operating state configuration of a node, and a system configuration of a node.

[0019] In combination with the above-mentioned second aspect, in a possible implementation method, the processing unit is specifically used to: verify whether the topological relationship configuration of the node after the occurrence of the fault event is the same as the topological relationship configuration in the non-fault state, and verify whether the operating state configuration after the occurrence of the fault event is the same as the operating state configuration in the non-fault state, and verify whether the system configuration after the fault event is the same as the system configuration in the non-fault state; if the topological relationship configuration is different, the operating state configuration is different and / or the system configuration is different, the node is marked as a faulty node, and at least one first node other than the faulty node in the network topology is screened out; for each first node, verify whether the network connectivity state of the first node after the occurrence of the fault event is the same as the network connectivity state in the non-fault state; if the network connectivity states are different, the first node is marked as a faulty node, and at least one second node other than the faulty node in at least one first node is screened out; for each second node, verify whether the system configuration of the second node after the occurrence of the fault event is the same as the system configuration of the node in the non-fault state; if the system configurations are different, the second node is marked as a faulty node.

[0020] In combination with the above-mentioned second aspect, in a possible implementation method, the processing unit is also used to: in the case where the node is a faulty node, based on the configuration information of the node in a non-faulty state, correct the configuration information of the node after the fault event occurs, so that the node is changed from a faulty state to a non-faulty state; record the correction plan of the node; the correction plan includes the correction process of the configuration information when the node is changed from a faulty state to a non-faulty state.

[0021] In combination with the above-mentioned second aspect, in a possible implementation method, after each faulty node in the network topology has been corrected, the processing unit is specifically used to: repeatedly perform the first operation until the availability of each node in the network topology has been detected; summarize the availability of each node in the network topology to obtain the detection result of the network topology.

[0022] The first operation includes: for each node in the network topology, detecting whether the network connectivity state of the node is a connectivity state; if it is a connectivity state, marking the availability of the node as available; otherwise, marking the availability of the node as unavailable.

[0023] In combination with the above-mentioned second aspect, in a possible implementation method, the fault event includes at least one of the following: a network logic fault event, a physical fault event, and a protocol fault event; wherein the network logic fault event includes a simulated configuration error event and a router port shutdown event; the physical fault event includes a power outage event and a network disconnection event; the protocol fault event includes a router fault event and a firewall parameter setting error event.

[0024] In a third aspect, the present application provides a communication device, comprising: a processor and a communication interface; the communication interface and the processor are coupled, and the processor is used to run a computer program or instructions to implement a network fault location method as described in the first aspect and any possible implementation method of the first aspect.

[0025] In a fourth aspect, the present application provides a computer-readable storage medium, which stores instructions. When the instructions are executed on a terminal, the terminal executes the network fault location method described in the first aspect and any possible implementation of the first aspect.

[0026] In a fifth aspect, the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the network fault locating method as described in the first aspect and any possible implementation manner of the first aspect.

[0027] In a sixth aspect, the present application provides a chip, the chip comprising a processor and a communication interface, the communication interface and the processor are coupled, and the processor is used to run a computer program or instructions to implement the network fault location method described in the first aspect and any possible implementation method of the first aspect.

[0028] Specifically, the chip provided in the present application also includes a memory for storing computer programs or instructions.

[0029] It should be noted that the above computer instructions may be stored in whole or in part on a computer-readable storage medium, wherein the computer-readable storage medium may be packaged together with the processor of the device, or may be packaged separately from the processor of the device, which is not limited in this application.

[0030] In a seventh aspect, the present application provides a network fault location system, comprising: a network topology and a server, wherein the server is used to execute the network fault location method as described in the first aspect and any possible implementation manner of the first aspect.

[0031] The descriptions of the second to seventh aspects of the present application can refer to the detailed description of the first aspect; and the beneficial effects of the descriptions of the second to seventh aspects can refer to the beneficial effect analysis of the first aspect, which will not be repeated here.

[0032] In this application, the name of the above network fault location device does not limit the device or functional module itself. In actual implementation, these devices or functional modules may appear with other names. As long as the functions of each device or functional module are similar to those of this application, they fall within the scope of the claims of this application and their equivalent technologies.

[0033] These and other aspects of the present application will become more apparent from the following description.

[0034] The above scheme brings at least the following beneficial effects: Based on the above technical scheme, the network fault location method provided by the present application establishes a network topology corresponding to the target network, and records the configuration information of each node in the network topology in a non-fault state; generates a fault event, injects the fault event into the network topology, and records the configuration information of each node in the network topology after the fault event occurs. That is to say, the network fault in the present technical scheme occurs based on the network topology corresponding to the target network, and the network fault detection is also implemented based on the network topology corresponding to the target network. Then, by verifying the configuration information of each node in a non-fault state and the configuration information of each node after the fault event occurs, the present technical scheme can locate the faulty node in the network topology corresponding to the target network, thereby solving the problem that the virtual machine console in the current network detection scheme determines whether the network nodes are connected through the network detection protocol, but is not applicable to the real network scenario and has poor practicality, and greatly improves the practicality of network fault detection. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 It is a flow chart of a network detection method and system based on open stack;

[0036] Figure 2 A schematic diagram of the architecture of a network fault location system provided in an embodiment of the present application;

[0037] Figure 3 A schematic diagram of a network fault locating method provided in an embodiment of the present application;

[0038] Figure 4 A schematic diagram of the hardware structure of a communication device provided in an embodiment of the present application;

[0039] Figure 5 A flowchart of a network fault location method provided in an embodiment of the present application;

[0040] Figure 6 A flowchart of another network fault location method provided in an embodiment of the present application;

[0041] Figure 7 A flowchart of another network fault location method provided in an embodiment of the present application;

[0042] Figure 8 A flowchart of another network fault location method provided in an embodiment of the present application;

[0043] Fig. 9 A flowchart of another network fault location method provided in an embodiment of the present application;

[0044] Fig.10 A flowchart of another network fault location method provided in an embodiment of the present application;

[0045] Fig.11 A flowchart of another network fault location method provided in an embodiment of the present application;

[0046] Fig.12 A schematic diagram of the structure of a network fault locating device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0047] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of this application.

[0048] The term "and / or" in this article is merely a description of the association relationship of associated objects, indicating that three relationships may exist. For example, A and / or B can mean: A exists alone, A and B exist at the same time, and B exists alone.

[0049] The terms "first" and "second" and the like in the specification and drawings of this application are used to distinguish different objects, or to distinguish different processing of the same object, rather than to describe a specific order of objects.

[0050] In addition, the terms "including" and "having" and any variations thereof mentioned in the description of the present application are intended to cover non-exclusive inclusions. For example, a process, method, system, product or device comprising a series of steps or units is not limited to the listed steps or units, but may optionally include other steps or units that are not listed, or may optionally include other steps or units that are inherent to these processes, methods, products or devices.

[0051] It should be noted that, in the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0052] In the description of the present application, unless otherwise specified, “plurality” means two or more.

[0053] With the rapid development of cloud computing technology, Open Stack, as an open source cloud computing management platform, has been widely used in the fields of enterprises and data centers. However, in the application scenarios of Open Stack, the network topology is relatively complex, involving multiple virtualization technologies, network protocols and service deployment methods, which makes the prediction and location of network faults extremely difficult, which undoubtedly brings extremely arduous challenges to operation and maintenance personnel.

[0054] Operators play a key role in the construction and maintenance of the backbone network in the entire network architecture, and they play an indispensable cornerstone role in the sustained, stable and rapid development of technology. In view of this, a stable and reliable network has become a principled premise. Because once a network failure occurs, it will cause many serious consequences and bring huge risks and hidden dangers, which may have a wide and far-reaching impact on many industries and fields that rely on the network.

[0055] Traditional network fault detection methods rely on manual simulation detection, which is inefficient and prone to missing potential fault factors. With the complexity of the network and the huge increase in network development, the security and stability of the network have encountered unprecedented challenges. For example, in recent years, large-scale service interruptions have occurred in the network. Due to the long fault recovery time required for manual simulation detection and untimely processing, customer service has been greatly affected.

[0056] The network detection scheme currently proposed includes a network detection method and system based on open stack, such as Figure 1 As shown, the method includes:

[0057] 1. Create a service module project based on open stack, and create external and internal networks for the service module project.

[0058] 2. Create a virtual machine and configure it in the internal network.

[0059] 3. Create a router and add internal and external network interfaces to the router.

[0060] 4. Add the network detection protocol to the service module project.

[0061] 5. Assign a floating IP to the service module project and bind the floating IP to the virtual machine.

[0062] 6. Turn off the firewall in the virtual machine console.

[0063] 7. The virtual machine console uses the network detection protocol to determine whether the network is connected.

[0064] The system includes: a network creation module, a virtual machine creation module, a router creation module, a network detection protocol adding module, a floating IP allocation module, a firewall closing module and a network judgment module.

[0065] In the above network detection scheme, the virtual machine console determines whether the network nodes are connected through the network detection protocol. However, this scheme is not applicable to real network scenarios and has poor practicality.

[0066] In addition, there are many types of network failures at present. This technology cannot analyze and simulate the detection and location analysis of other types of network failures, nor can it obtain the corresponding correction solutions for the failures, and its reliability is poor.

[0067] In view of this, the network fault location method provided by the present application establishes a network topology corresponding to the target network, and records the configuration information of each node in the network topology in a non-fault state; generates a fault event, injects the fault event into the network topology, and records the configuration information of each node in the network topology after the fault event occurs. In other words, the network fault in the present technical solution occurs based on the network topology corresponding to the target network, and the network fault detection is also implemented based on the network topology corresponding to the target network. Then, by verifying the configuration information of each node in a non-fault state and the configuration information of each node after the fault event occurs, the present technical solution can locate the faulty node in the network topology corresponding to the target network, thereby solving the problem that the virtual machine console in the current network detection solution determines whether the network nodes are connected through the network detection protocol, but is not applicable to the real network scenario and has poor practicality, and greatly improves the practicality of network fault detection.

[0068] The implementation of the embodiments of the present application will be described in detail below in conjunction with the accompanying drawings.

[0069] Figure 2 The following is a schematic diagram of the architecture of a network fault location system provided in an embodiment of the present application. Figure 2 As shown, the network fault location system includes: a network topology 201 and a server 202 .

[0070] The network topology 201 and the server 202 are connected via a communication link. The communication link may be a wired communication link or a wireless communication link, which is not limited in the present application.

[0071] In some embodiments, the network topology 201 is generated based on the target network (e.g., a real network in a certain area). The network topology 201 includes multiple nodes. The nodes may be terminals, access network devices, core network devices, relay devices, etc., and this application does not impose any restrictions on this.

[0072] Optionally, each node in the network topology 201 may be developed and generated based on the open stack platform and may be supported by the open stack platform.

[0073] Optionally, the network topology 201 supports editing and modification, and the network topology 201 has a custom feature.

[0074] In some embodiments, Figure 3 As shown, the server 202 can be used to record and save the initial configuration information of each node in the network topology 201 when it is successfully created. Among them, each node is in a non-fault state when it is successfully created. The server 202 is also used to generate various types of fault events, and inject the fault events into the network topology 201, and record the configuration information of each node in the network topology 201 when it is in a non-fault state.

[0075] Further, such as Figure 3 As shown, the server 202 is also used to perform verification and analysis based on the initial configuration information of each node when it is successfully created and the configuration information when it is in a non-faulty state, so as to locate the faulty node in the network topology 201.

[0076] Further, such as Figure 3 As shown, the server 202 is also used to provide a correction solution for each node in a fault state, and repair the faulty node among the nodes, so that the node is converted from a faulty state to a non-faulty state.

[0077] Further, such as Figure 3 As shown, the server 202 is also used to verify the network topology after the node changes from a faulty state to a non-faulty state, and detect the availability of each node in the network topology, so as to facilitate targeted analysis by operation and maintenance personnel and improve fault operation and maintenance efficiency.

[0078] Optionally, the server 202 may be an open stack platform, which is mainly used to build and manage a cloud computing environment and provide cloud computing services, including management and allocation of computing, storage, network and other resources.

[0079] Optionally, the server 202 may be an independent physical server, or a server cluster or distributed file system composed of multiple physical servers, or at least one of cloud servers that provide basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, content distribution networks, and big data and artificial intelligence platforms. Of course, the above is only an exemplary introduction to the server 202. The server 202 may also be a relational database management system (e.g., MySQL, Oracle Database, or Microsoft SQL Server) and / or a database based on distributed file storage (e.g., MongoDB database, HBase database, or Cassandra database), and this application does not impose any restrictions on this.

[0080] When implemented by hardware, each module in the server 202 can be integrated into Figure 4 Specifically, Figure 4 As shown, the basic hardware structure of the communication device is introduced.

[0081] Figure 4 The hardware structure diagram of a communication device provided in an embodiment of the present application is shown in FIG. Figure 4 As shown, the communication device includes at least one processor 401, a communication line 402, and at least one communication interface 404, and may also include a memory 403. The processor 401, the memory 403 and the communication interface 404 may be connected via the communication line 402.

[0082] Processor 401 can be a central processing unit (CPU), an application specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of the present application, such as: one or more digital signal processors (DSP), or one or more field programmable gate arrays (FPGA).

[0083] The communication link 402 may include a pathway for transmitting information between the above-mentioned components.

[0084] The communication interface 404 is used to communicate with other devices or communication networks, and can use any transceiver-like device, such as Ethernet, radio access network (RAN), wireless local area network (WLAN), etc.

[0085] The memory 403 may be a read-only memory (ROM) or other types of static storage devices that can store static information and instructions, a random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, or an electrically erasable programmable read-only memory (EEPROM), a compact disc read-only memory (CD-ROM) or other optical disc storage, an optical disc storage (including compressed optical discs, laser discs, optical discs, digital versatile discs, Blu-ray discs, etc.), a magnetic disk storage medium or other magnetic storage device, or any other medium that can be used to include or store desired program code in the form of instructions or data structures and can be accessed by a computer, but is not limited to these.

[0086] In one possible design, the memory 403 can exist independently of the processor 401, that is, the memory 403 can be a memory outside the processor 401. In this case, the memory 403 can be connected to the processor 401 through the communication line 402, and is used to store execution instructions or application code, and the processor 401 controls the execution to implement the network fault location method provided in the following embodiment of the present application. In another possible design, the memory 403 can also be integrated with the processor 401, that is, the memory 403 can be the internal memory of the processor 401, for example, the memory 403 is a high-speed cache, which can be used to temporarily store some data and instruction information, etc.

[0087] As a possible implementation, the processor 401 may include one or more CPUs, for example Figure 4 As another possible implementation, the communication device may include multiple processors, such as Figure 4 As another possible implementation, the communication apparatus may further include an output device 405 and an input device 406.

[0088] It should be pointed out that the various embodiments of the present application can learn from or refer to each other. For example, the same or similar steps, method embodiments, system embodiments and device embodiments can all refer to each other without limitation.

[0089] Figure 5 A flowchart of a network fault location method provided in an embodiment of the present application, which can be applied to Figure 4 In the communication device shown. Figure 5 As shown, the method includes the following S501-S503.

[0090] S501: Establish a network topology corresponding to the target network, and record configuration information of each node in the network topology in a non-fault state.

[0091] Optionally, the configuration information includes multiple types of configuration items, wherein the configuration items include at least one of the following: topological relationship configuration of the node, running state configuration of the node, and system configuration of the node.

[0092] It should be noted that the topology configuration of a node is used to reflect other nodes and connection relationships connected to the node in the network topology. The running status configuration of a node is used to reflect whether the node is powered on or powered off. The system configuration of a node is used to reflect the configuration information inside the node.

[0093] In one possible implementation, a network topology corresponding to the target network is established based on the open stack platform, and the configuration information of the network topology is recorded and saved (for example, saved in a relational database) for subsequent analysis. For example, based on the information, the configuration information of the nodes in the network topology after the failure event occurs is verified to determine whether the node is a faulty node.

[0094] S502: Generate a fault event, inject the fault event into the network topology, and record configuration information of each node in the network topology after the fault event occurs.

[0095] Optionally, the fault event includes at least one of the following: a network logic fault event, a physical fault event, and a protocol fault event. Of course, the above is only an exemplary description of the fault event, and the fault event may also include a topology fault (for example, reconfiguration of nodes or adding new nodes (network devices) to the main structure of the network, thereby changing the network topology).

[0096] Among them, network logical failure events include simulated configuration error events and router port shutdown events; physical failure events include power outage events and network disconnection events; protocol failure events include router failure events and firewall parameter setting error events.

[0097] It is understandable that a variety of different types of fault events can ensure the authenticity and comprehensiveness of network fault testing and can truly reflect the problems that may be encountered in the actual network operation environment.

[0098] In one possible implementation, Figure 6 As shown, the implementation process of S502 includes:

[0099] 1. Read and save the configuration information of each node in a non-faulty state (for example, read the configuration information of each node in a non-faulty state from a database) so as to be used for data comparison in the subsequent verification process.

[0100] 2. Select the type of fault event and prepare to inject it into the network topology.

[0101] 3. Set the parameters of the fault event. The parameters of the fault event include but are not limited to at least one of the following: fault occurrence event, fault duration, and fault impact range. The fault impact range is used to reflect the range of nodes affected by the fault event in the network topology.

[0102] 4. Complete the generation of fault events and inject fault event simulation into the network topology.

[0103] 5. Record the configuration information of each node in the network topology after the failure event occurs. The configuration information of each node in the network topology after the failure event occurs includes: the topological relationship configuration of the node after the failure event occurs, the running status configuration of the node, and the system configuration of the node.

[0104] The specific description of the topological relationship configuration of the node, the running state configuration of the node and the system configuration of the node refers to the embodiment shown in S501 and will not be repeated here.

[0105] Among them, Figure 6 As shown, the generation process of a fault event includes the above steps 2 to 4.

[0106] S503: Based on the configuration information of each node in a non-faulty state, verify the configuration information of each node after the fault event occurs to locate the faulty node among the nodes.

[0107] In a possible implementation, corresponding to the configuration information including multiple types of configuration items, the implementation process of the above S503 may include: for each of the nodes, based on the multiple types of configuration items when the node is in a non-faulty state, verifying each configuration item of the node after the fault event occurs one by one, obtaining a verification result, and locating the faulty node in the network topology based on the verification result.

[0108] Specifically, in combination with multiple types of configuration items when the node is in a non-faulty state, the specific implementation process of the above S503 refers to the embodiments shown in S701-S706, and will not be repeated here.

[0109] In another possible implementation, a network fault detection tool (e.g., ping, traceroute, network packet capture) is used to quickly locate the faulty node in the network topology. At the same time, the configuration information of each node after the network topology fault event occurs is verified to assist in locating the faulty node in the network topology. Then, the faulty node is corrected and repaired, and a fault correction plan is generated (e.g., adjusting the network configuration, restarting, restoring backup, etc.).

[0110] Among them, the verification of the configuration information of each node after a network topology failure event includes at least one of the following: power-on verification, network start-stop verification, network intercommunication verification, and protocol entry and exit verification.

[0111] Based on the above technical scheme, the network fault location method provided by the present application establishes a network topology corresponding to the target network, and records the configuration information of each node in the network topology in a non-fault state; generates a fault event, injects the fault event into the network topology, and records the configuration information of each node in the network topology after the fault event occurs. In other words, the network fault in the present technical scheme occurs based on the network topology corresponding to the target network, and the network fault detection is also implemented based on the network topology corresponding to the target network. Then, by verifying the configuration information of each node in a non-fault state and the configuration information of each node after the fault event occurs, the present technical scheme can locate the faulty node in the network topology corresponding to the target network, thereby solving the problem that the virtual machine console in the current network detection scheme determines whether the network nodes are connected through the network detection protocol, but is not applicable to real network scenarios and has poor practicality, and greatly improves the practicality of network fault detection.

[0112] Furthermore, the present application simulates a variety of fault events to ensure the authenticity and comprehensiveness of network fault testing, and can truly reflect the problems that may be encountered in the actual network operation environment.

[0113] As a possible embodiment of the present application, Figure 5 ,like Figure 7 As shown, in the above S503, the configuration information of each node after the failure event occurs is verified to locate the faulty node, which can be specifically implemented through the following S701-S706.

[0114] S701. Verify whether the topological relationship configuration of the node after a fault event is the same as the topological relationship configuration in a non-fault state, verify whether the running status configuration after a fault event is the same as the running status configuration in a non-fault state, and verify whether the system configuration after a fault event is the same as the system configuration in a non-fault state.

[0115] It can be understood that S701 can be understood as verifying the configuration information of the node (including the node's topological relationship configuration, operating status configuration and system configuration) after a network topology failure event occurs to determine whether the node causes network abnormality due to abnormal configuration information.

[0116] S702: If the topology relationship configuration is different, the operation status configuration is different, and / or the system configuration is different, then the node is marked as a faulty node.

[0117] In a possible implementation manner, the implementation process of S702 may further include: if the two configuration information are inconsistent, marking the node as a faulty node.

[0118] It is understandable that the inconsistency between the two configuration information indicates that the node failure is a network abnormality caused by abnormal configuration information.

[0119] S703, filter out at least one first node other than the faulty node in the network topology; for each first node, verify whether the network connectivity state of the first node after the fault event occurs is the same as the network connectivity state in a non-faulty state.

[0120] The network connectivity state of a node in a non-fault state is the connectivity state. The network connectivity state is used to reflect the network connectivity of the node with the nodes connected to both sides.

[0121] That is to say, the essence of verifying whether the network connectivity state of the first node after the failure event is the same as the network connectivity state in a non-failure state is to verify whether the network connectivity state of the first node after the failure event is connected.

[0122] In one possible implementation, the implementation process of S703 may include: calling a network connectivity test tool (such as ping, traceroute, or network packet capture) to detect the network connectivity between the first node and the interconnected nodes on both sides to verify whether the network connectivity status of the first node is connected after a failure event occurs.

[0123] S704: If the network connectivity states are different, mark the first node as a faulty node.

[0124] In a possible implementation manner, the implementation process of S704 may include: when the network connectivity state of the first node after the failure event occurs is disconnected, marking the first node as a faulty node.

[0125] S705. Filter out at least one second node other than the faulty node in at least one first node; for each second node, verify whether the system configuration of the second node after the fault event occurs is the same as the system configuration of the node in a non-faulty state.

[0126] It should be noted that, since the system configuration of a node may be affected by other faulty nodes and may change, the faulty nodes may be further screened through the above S705 to ensure the availability of the nodes.

[0127] S706: If the system configurations are different, mark the second node as a faulty node.

[0128] Based on the above technical solution, the node configuration information, network connectivity status and system configuration were tested and verified respectively to accurately locate each faulty node, and different types of faulty nodes were classified to clarify the type of fault of each node to facilitate subsequent maintenance.

[0129] As a possible embodiment of the present application, Figure 5 ,like Figure 8 As shown, after S503, the network fault detection method further includes the following S801-S802.

[0130] S801: When a node is a faulty node, based on the configuration information of the node in a non-faulty state, correct the configuration information of the node after the fault event occurs, so that the node changes from the faulty state to the non-faulty state.

[0131] In a possible implementation, the implementation process of S801 includes: corresponding to different fault conditions of the faulty node, correcting the configuration information of the node after the fault event occurs through corresponding solutions, so that the node changes from a faulty state to a non-faulty state.

[0132] In the following, through Case 1 to Case 3, three different fault situations corresponding to the faulty node are introduced respectively, and the process of correcting the configuration information of the node after the fault event occurs is specifically introduced.

[0133] Case 1: When the network abnormality is caused by abnormal configuration information of the node, the configuration information of the node after the failure event is replaced with the configuration information of the node in a non-fault state, thereby correcting the configuration information of the node in a non-fault state.

[0134] Case 2: When the network abnormality is caused by abnormal network connectivity, log in to the node console to reconfigure the network of the faulty node to ensure the network connectivity of the node.

[0135] Case 3: When the network abnormality is caused by abnormal system configuration, the system configuration of the second node in a non-faulty state is imported to complete the correction.

[0136] S802: Record the node's correction plan.

[0137] The correction scheme includes a correction process of configuration information when a node changes from a fault state to a non-fault state.

[0138] In one example, corresponding to the above situation 1, the configuration information of the abnormal state (that is, the configuration information different from the configuration information in the non-fault state) is listed in the correction scheme; and the corrected configuration information is listed and explained. For example, configuration information A is corrected to configuration information B.

[0139] In another example, corresponding to the above situation 2, the nodes whose network configurations have been re-corrected and their node network configuration information are listed in the correction scheme.

[0140] In another example, corresponding to the above situation 3, the system configuration before correction and the system configuration after correction are listed in the correction scheme.

[0141] Based on the above technical solution, in the case that the node is a faulty node, based on the configuration information of the node in a non-faulty state, the configuration information of the node after the fault event occurs is corrected so that the node is transformed from a faulty state to a non-faulty state, and the correction plan of the node is recorded so that when a subsequent network topology failure occurs, the network topology can be maintained based on the correction plan.

[0142] As a possible embodiment of the present application, Fig. 9 As shown, the implementation scheme of locating, classifying, resolving faults and generating correction schemes in the network fault detection method includes the following steps 1 to 14.

[0143] 1. Read and save the configuration information of each node in a non-fault state and the configuration information of each node in the network topology after a fault event occurs.

[0144] 2. Verify whether the configuration information of the two is consistent.

[0145] 3. If the configuration information of the two is inconsistent, the node will be marked as a faulty node.

[0146] 4. Correct inconsistent configuration information (for example, correct the configuration information of a node after a failure event occurs to the configuration information when the node is in a non-failure state).

[0147] 5. Generate a correction plan.

[0148] 6. If the configuration information of the two is consistent, a network test is performed on the two end nodes of the interconnection network in at least one first node to determine the network connectivity status.

[0149] 7. Filter out a faulty node from at least one first node and mark the faulty node.

[0150] 8. Log in to the node console and reconfigure the network of the faulty node.

[0151] 9. Generate a correction plan corresponding to the node.

[0152] 10. Export the system configuration of the second node after the failure event occurs.

[0153] 11. Determine whether the system configuration of the second node after the failure event is the same as the system configuration when the node is in a non-failure state.

[0154] 12. If the system configuration of the second node is different, the node is determined to be a faulty node, and the system configuration of the second node in a non-faulty state is imported to complete the correction.

[0155] 13. Generate a correction plan.

[0156] 14. Summarize the correction solutions generated in step 5, step 9 and step 13 to obtain a total correction solution, so that when a network topology failure occurs subsequently, the network topology can be maintained based on the summary solution.

[0157] As a possible embodiment of the present application, Figure 8 ,like Fig.10 As shown, after S802, the network fault detection method further includes a step of detecting the availability of the network topology, which specifically includes the following S1001.

[0158] S1001. Repeat the first operation until the availability of each node in the network topology has been detected, summarize the availability of each node in the network topology, and obtain a detection result of the network topology.

[0159] In some embodiments, the first operation includes: for each node in the network topology, detecting whether the network connectivity status of the node is connected; if it is connected, marking the availability of the node as available; otherwise, marking the availability of the node as unavailable.

[0160] In one possible implementation, the implementation process of the first operation includes: calling a network connectivity test tool (such as ping, traceroute, or network packet capture) to send detection data to the node to detect the network connectivity of the node. If the network connectivity test tool receives the response information of the node, the availability of the node is determined to be available, and the availability of the node can be further determined based on the event and status code of the received response information. For example, if the time length of receiving the response information is greater than the preset time length, it is determined that the network performance of the node is poor and the availability is low. If the network connectivity test tool does not receive the response information of the node, the availability of the node is determined to be unavailable.

[0161] Based on the above technical solution, the configuration information of each node in the network topology is obtained, and the network connections between each node in the network topology are traversed. The first operation is repeatedly performed until the availability of each node in the network topology has been detected, and the availability of each node in the network topology is summarized to obtain the detection result of the network topology. The above technical solution can verify the availability of each node in the corrected network topology to determine whether the correction solution is effective.

[0162] As a possible embodiment of the present application, Fig.11 As shown, the specific implementation process of verifying each node in the corrected network topology can also be implemented through the following steps 1 to 8.

[0163] 1. Get the configuration information of each node in the network topology.

[0164] 2. Traverse the network connections between each node in the network topology.

[0165] 3. Call a network connectivity test tool (such as ping, traceroute, or network packet capture) to send test data to the node to detect the network connectivity of the node.

[0166] 4. If the network connectivity test tool receives the response information from the node, the availability of the node is marked as available.

[0167] When the network connectivity test tool receives the response information of the node, it indicates that the network connectivity of the node is normal, and the availability of the node can be further determined based on the event and status code of the received response information. For example, if the time length of receiving the response information is longer than the preset time length, it is determined that the network performance of the node is poor and the availability is low.

[0168] 5. If the network connectivity test tool does not receive a response message from the node, the availability of the node is determined to be unavailable.

[0169] 6. Continue traversing the next node in the network topology.

[0170] 7. Determine whether all nodes in the network topology have been traversed; if so, execute step 8; otherwise, execute step 2 to continue traversing the next node in the network topology.

[0171] 8. Summarize the availability of each node in the network topology and obtain the detection result of the network topology.

[0172] It is understandable that the technical solution uses a network connectivity test tool for testing, which can quickly identify the cause and type of the fault and automatically generate a solution, thereby shortening the time for troubleshooting and improving the accuracy and effectiveness of the solution.

[0173] The embodiment of the present application can divide the network fault location device into functional modules or functional units according to the above method example. For example, each functional module or functional unit can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of software functional modules or functional units. Among them, the division of modules or units in the embodiment of the present application is schematic, which is only a logical function division. There may be other division methods in actual implementation.

[0174] like Fig.12 , which is a schematic diagram of the structure of a network fault locating device 120 provided in an embodiment of the present application. The network fault locating device 120 includes: a processing unit 1201.

[0175] Processing unit 1201 is used to establish a network topology corresponding to the target network and record the configuration information of each node in the network topology when it is in a non-fault state; processing unit 1201 is also used to generate a fault event and inject the fault event into the network topology, and record the configuration information of each node in the network topology after the fault event occurs; processing unit 1201 is also used to verify the configuration information of each node after the fault event occurs based on the configuration information of each node in a non-fault state, so as to locate the faulty node among the nodes.

[0176] In one possible implementation, the configuration information includes multiple types of configuration items; the processing unit 1201 is specifically used to: for each node in each node, based on multiple types of configuration items when the node is in a non-faulty state, verify each configuration item of the node after the fault event occurs one by one, obtain a verification result, and locate the faulty node in the network topology based on the verification result.

[0177] In a possible implementation manner, the configuration item includes at least one of the following: a topological relationship configuration of a node, an operating state configuration of a node, and a system configuration of a node.

[0178] In a possible implementation, the processing unit 1201 is specifically used to: verify whether the topological relationship configuration of the node after a fault event occurs is the same as the topological relationship configuration in a non-fault state, and verify whether the operating state configuration after the fault event occurs is the same as the operating state configuration in a non-fault state, and verify whether the system configuration after the fault event occurs is the same as the system configuration in a non-fault state; if the topological relationship configuration is different, the operating state configuration is different and / or the system configuration is different, the node is marked as a faulty node, and at least one first node other than the faulty node in the network topology is screened out; for each first node, verify whether the network connectivity state of the first node after the fault event occurs is the same as the network connectivity state in a non-fault state; if the network connectivity states are different, the first node is marked as a faulty node, and at least one second node other than the faulty node in at least one first node is screened out; for each second node, verify whether the system configuration of the second node after the fault event occurs is the same as the system configuration of the node in a non-fault state; if the system configurations are different, the second node is marked as a faulty node.

[0179] In one possible implementation, the processing unit 1201 is also used to: in the case where the node is a faulty node, based on the configuration information of the node in a non-faulty state, correct the configuration information of the node after the fault event occurs, so that the node is changed from a faulty state to a non-faulty state; record the correction plan of the node; the correction plan includes the correction process of the configuration information when the node is changed from a faulty state to a non-faulty state.

[0180] In one possible implementation, after each faulty node in the network topology has been corrected, the processing unit 1201 is specifically used to: repeatedly perform the first operation until the availability of each node in the network topology has been detected; summarize the availability of each node in the network topology to obtain the detection result of the network topology.

[0181] The first operation includes: for each node in the network topology, detecting whether the network connectivity state of the node is a connectivity state; if it is a connectivity state, marking the availability of the node as available; otherwise, marking the availability of the node as unavailable.

[0182] In one possible implementation, the fault event includes at least one of the following: a network logic fault event, a physical fault event, and a protocol fault event; wherein the network logic fault event includes a simulated configuration error event and a router port shutdown event; the physical fault event includes a power outage event and a network disconnection event; and the protocol fault event includes a router fault event and a firewall parameter setting error event.

[0183] In a possible implementation, the network fault location device 120 may further include a storage unit 1202 ( Fig.12 The storage unit 1202 stores a program or instruction. When the processing unit 1201 executes the program or instruction, the network fault location device 120 can execute the network fault location method described in the above method embodiment.

[0184] Through the description of the above implementation methods, technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device is divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device and unit described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here.

[0185] An embodiment of the present application provides a computer program product including instructions. When the computer program product is run on a computer, the computer is enabled to execute the network fault locating method in the above method embodiment.

[0186] An embodiment of the present application also provides a computer-readable storage medium, in which instructions are stored. When the instructions are executed on a computer, the computer executes the network fault locating method in the method flow shown in the above method embodiment.

[0187] Among them, the computer readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer readable storage media (a non-exhaustive list) include: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a register, a hard disk, an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above, or any other form of computer readable storage medium known in the art. An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an application-specific integrated circuit (ASIC). In the embodiments of the present application, a computer-readable storage medium may be any tangible medium that contains or stores a program, which may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0188] Since the network fault locating device, computer-readable storage medium, and computer program product in the embodiments of the present application can be applied to the above method, the technical effects that can be obtained can also refer to the above method embodiments, and the embodiments of the present application will not be repeated here.

[0189] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some interfaces, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0190] It should be understood that the various forms of processes shown above can be used to reorder, add or delete steps. For example, the steps recorded in this disclosure can be executed in parallel, sequentially or in different orders, as long as the desired results of the technical solution of this disclosure can be achieved, and this document is not limited here.

[0191] The above specific implementations do not constitute a limitation on the protection scope of the present disclosure. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions can be made according to design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

[0192] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0193] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0194] The above are only specific implementations of the present application, but the protection scope of the present application is not limited thereto. Any changes or substitutions within the technical scope disclosed in the present application should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

Claims

1. A network fault location method, characterized in that: The method comprises: Establishing a network topology corresponding to the target network, and recording configuration information of each node in the network topology when it is in a non-faulty state; Generate a fault event, inject the fault event into the network topology, and record configuration information of each node in the network topology after the fault event occurs; Based on the configuration information of each node in a non-faulty state, the configuration information of each node after the fault event occurs is verified to locate the faulty node among the nodes.

2. The method according to claim 1, characterized in that: The configuration information includes multiple types of configuration items; and the verifying the configuration information of each node after the fault event occurs to locate the faulty node among the nodes includes: For each of the nodes, based on multiple types of configuration items when the node is in a non-faulty state, each configuration item of the node after the fault event occurs is verified one by one to obtain a verification result, and based on the verification result, the faulty node in the network topology is located.

3. The method according to claim 2, characterized in that The configuration item includes at least one of the following: a topological relationship configuration of the node, an operating state configuration of the node, and a system configuration of the node.

4. The method according to claim 3, characterized in that: The method of verifying each configuration item of the node after the fault event occurs based on multiple types of configuration items of the node in a non-fault state, obtaining a verification result, and locating the faulty node in the network topology based on the verification result includes: Verify whether the topological relationship configuration of the node after the fault event occurs is the same as the topological relationship configuration in a non-fault state, verify whether the running state configuration after the fault event occurs is the same as the running state configuration in a non-fault state, and verify whether the system configuration after the fault event occurs is the same as the system configuration in a non-fault state; If the topological relationship configuration is different, the operating state configuration is different, and / or the system configuration is different, the node is marked as the faulty node, and at least one first node other than the faulty node in the network topology is screened out; for each first node, verify whether the network connectivity state of the first node after the fault event occurs is the same as the network connectivity state in a non-faulty state; If the network connectivity states are not the same, the first node is marked as the faulty node, and at least one second node other than the faulty node in the at least one first node is screened out; for each second node, verify whether the system configuration of the second node after the fault event occurs is the same as the system configuration of the node in a non-faulty state; If the system configurations are different, the second node is marked as the faulty node.

5. The method according to claim 1, characterized in that: The method further comprises: In the case where the node is a faulty node, based on the configuration information of the node in a non-faulty state, correcting the configuration information of the node after the fault event occurs, so that the node changes from a faulty state to a non-faulty state; Recording the correction scheme of the node; the correction scheme includes the correction process of the configuration information when the node changes from a faulty state to a non-faulty state.

6. The method according to claim 5, characterized in that After corrective processing is performed on each faulty node in the network topology, the method further includes: Repeat the first operation until the availability of each node in the network topology has been detected, summarize the availability of each node in the network topology, and obtain a detection result of the network topology; The first operation includes: For each node in the network topology, detecting whether the network connectivity state of the node is a connectivity state; If it is in a connected state, the availability of the node is marked as available; otherwise, the availability of the node is marked as unavailable.

7. The method according to claim 1, characterized in that The fault event includes at least one of the following: a network logic fault event, a physical fault event, and a protocol fault event; Among them, the network logic failure events include simulated configuration error events and router port shutdown events; the physical failure events include power failure events and network disconnection events; the protocol failure events include router failure events and firewall parameter setting error events.

8. A network fault location device, characterized in that: The device comprises a processing unit; The processing unit is used to establish a network topology corresponding to the target network and record configuration information of each node in the network topology when it is in a non-faulty state; The processing unit is further used to generate a fault event, inject the fault event into the network topology, and record the configuration information of each node in the network topology after the fault event occurs; The processing unit is further configured to verify the configuration information of each node after the failure event occurs based on the configuration information of each node in a non-failure state, so as to locate the failed node among the nodes.

9. A communication device, characterized in that: include: A processor and a communication interface; the communication interface is coupled to the processor, and the processor is used to run a computer program or instruction to implement the network fault location method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores instructions. When a computer executes the instructions, the computer executes the network fault locating method according to any one of claims 1 to 7.

11. A computer program product, characterized in that The computer program product includes computer instructions, and when the computer instructions are executed on a computer, the computer is enabled to execute the network fault locating method according to any one of claims 1 to 7.

Images