A method, apparatus, and electronic device for detecting connectivity in a simulated network.

Abstract

This invention discloses a connectivity detection method, apparatus, and device for a simulated network. The method is applied to a simulation controller and includes: sending a first instruction when distributing a series of configuration data to the simulated network; the first instruction initiates a probe task along the path from the source node to the destination node in the simulated network; at a preset time during the probe packet distribution process, detecting whether all the configuration data has been distributed; if not, sending a second instruction to the simulated network, instructing the source node and destination node to continue performing one or more probe tasks after sending a batch of probe packets for the current probe task; counting the total number of probe packets received from the destination node and comparing it with the total number of probe packets sent by the source node to determine the connectivity detection result. This method simulates packet loss during configuration distribution, thereby ensuring that packet loss does not occur during production-state configuration distribution due to configuration coupling or intermediate process modifications.

Description

Technical Field

[0001] This invention relates to the field of computers, and in particular to a method, apparatus, and electronic device for detecting the connectivity of a simulated network. Background Technology

[0002] Statistics show that up to 40% of network incidents in data centers are caused by human configuration errors, and the accuracy of risk assessments for network changes by network management departments is only about 70%. For example, a company upgrades and expands its equipment, and the upgrade is shown as successful, but the next day, business operations fail. This is because the dynamic routing protocol used in network operations is very complex, and the equipment change caused routing problems. Since the impact on business applications has a time lag, looking at application traffic at a specific point in time may not be comprehensive. It is extremely difficult for users to conduct accurate risk assessments on both the network and application sides. Therefore, analysis and verification before business operations are actually implemented in the production environment become essential.

[0003] Simulation, as a pre-implementation verification technology, enables pre-implementation analysis of user services to verify their feasibility and impact, helping users quickly identify potential risks and minimize the possibility of damage to the production environment. Simulation technology uses comprehensive system models and resource acquisition to simulate and analyze actual environments and services, identifying potential risks in advance based on available information. In SDN (Software Defined Network) data center scenarios, it provides functions such as pre-implementation verification, simulation, resource consumption budgeting, and network connectivity monitoring for service deployment, helping users determine whether the current service orchestration can achieve the expected results and whether it will affect other existing services.

[0004] The simulated service deployment includes: simulated service deployment, simulated network construction, tenant service simulation, and configuration provisioning. Tenant service simulation refers to the ability of users to modify configurations for services such as vRouter, Network, Subnet, application policies, and EPG (End Point Group) in the simulated environment, and then distribute these modifications to the virtual devices in the simulated environment. Simulation evaluation is then performed, with capabilities encompassing capacity consumption prediction, connectivity simulation, and overall network impact assessment.

[0005] During connectivity simulation, a low-level packet sending mechanism is employed, leveraging OpenFlow's packet uploading functionality to detect connectivity between virtual ports and trace packet paths. While the connectivity detection results provide information before and after configuration changes, these results are relatively independent and do not include intermediate states. This leads to packet loss in service traffic during configuration changes, which cannot be simulated in the simulation. Furthermore, because packet loss during configuration data distribution cannot be monitored, it results in packet loss in the real-world environment when the configuration is distributed, impacting the performance of services deployed to production. Summary of the Invention

[0006] To address the technical problem of packet loss during the distribution of configuration data in the simulation state, which affects the performance of services in the production state, this application provides a method, apparatus, and device for detecting connectivity in a simulation network. Specifically, the following technical solution is disclosed:

[0007] In a first aspect, embodiments of the present invention disclose a connectivity detection method for a simulated network, which can be applied to a simulation controller, and the method includes:

[0008] When sending a series of configuration data to the simulation network, a first instruction is sent to the simulation network. The first instruction is used to start a probe task on the path from the source node to the destination node in the simulation network. The probe task includes the source node sending a batch of probe messages to the destination node, and the destination node encapsulating and sending the probe message to the simulation controller after receiving each probe message sent by the source node.

[0009] At a preset time during the probe message transmission process, it is detected whether all the series of configuration data has been transmitted.

[0010] If not, a second instruction is sent to the simulation network. The second instruction is used to instruct the source node and the destination node to continue to perform one or more probe tasks after sending a batch of probe messages for the current probe task, until all the series of configuration data has been distributed.

[0011] The simulation controller counts the total number of probe messages received from the destination node, compares the total number of probe messages with the total number of probe messages sent by the source node, and determines the connectivity detection results of the two virtual ports from the source node to the destination node based on the comparison results.

[0012] Optionally, in one possible implementation of the first aspect, before initiating a probe task on the path from the source node to the destination node in the simulation network, the method further includes: if the user makes at least a portion of the configuration modifications to the simulation controller, such that the configuration in the simulation network is also modified accordingly, then a rollback instruction is sent to the simulation network, the rollback instruction being used to instruct the simulation network to clear the at least a portion of the configuration modifications and roll back to the initial state of the simulation network.

[0013] Optionally, in another possible implementation of the first aspect, the method further includes: issuing a flow table to at least one node on at least one probe path of the simulated network, the flow table including message matching information and action information.

[0014] Wherein, the matching item information is used for at least one destination node to execute the action corresponding to the action item information after the received probe message matches the matching item information; the action item information is used to instruct the matching destination node to perform the action of encapsulating the probe message from the source node and sending it to the simulation controller.

[0015] Optionally, in another possible implementation of the first aspect, detecting whether all the series of configuration data has been distributed includes: receiving at least one response from the destination node of the simulated network based on the series of configuration data; counting the total number of the response responses; and determining that all the series of configuration data has been distributed if the total number of the response responses is the same as the total number of the series of configuration data distributed.

[0016] Optionally, in another possible implementation of the first aspect, comparing the total number of probe packets with the total number of probe packets sent by the source node, and determining the connectivity probe results of the two virtual ports from the source node to the destination node based on the comparison result, includes:

[0017] If the total number of probe packets is not the same as the total number of probe packets sent by the source node, it is determined that the connectivity probe result between the source node and the destination node has been lost, and the number of lost packets is determined to be the difference between the two totals.

[0018] Secondly, embodiments of the present invention also disclose another connectivity detection method for simulated networks, which is applied to simulated networks, and the method includes:

[0019] The system receives a series of configuration data and a first instruction sent by the simulation controller, and initiates a probe task. The probe task includes the source node in the simulation network sending a batch of probe messages to the destination node of the simulation network, and the destination node encapsulating and sending the probe message to the simulation controller after receiving each probe message sent by the source node.

[0020] During the process of receiving the series of configuration data, a second instruction sent by the simulation controller is received;

[0021] In response to the second instruction, the source node and the destination node are controlled to continue to execute one or more probe tasks after sending a batch of probe messages for the current probe task, until all the series of configuration data has been sent.

[0022] Optionally, in one possible implementation of the second aspect, before initiating the probe task, the method further includes: receiving a rollback command sent by the simulation controller; and in response to the rollback command, clearing configuration modifications made by the user to at least a portion of the simulation controller and rolling back to the initial state of the simulation network.

[0023] Optionally, in another possible implementation of the second aspect, the method further includes: receiving a flow table sent by the simulation controller, the flow table including message matching information and action information;

[0024] The destination node of the simulation network will receive probe messages from the source node, match them according to the matching item information, and if the match is successful, encapsulate the probe message according to the content of the action item information and send the encapsulated probe message to the simulation controller.

[0025] Optionally, in another possible implementation of the second aspect, the method further includes: each time the destination node of the simulation network receives a piece of configuration data sent by the simulation controller, it sends a response back to the simulation controller, the response indicating that the destination node has received the current configuration data sent by the simulation controller.

[0026] Thirdly, embodiments of the present invention also disclose a connectivity detection device for a simulated network, the device comprising:

[0027] The sending unit is used to send a series of configuration data to the simulation network, and when sending the series of configuration data, it also sends a first instruction to the simulation network. The first instruction is used to start a probe task on the path from the source node to the destination node in the simulation network. The probe task includes the source node sending a batch of probe messages to the destination node, and the destination node encapsulating and sending the probe message to the simulation controller after receiving each probe message sent by the source node.

[0028] The detection unit is used to detect at a preset time during the transmission of the probe message whether all the series of configuration data has been transmitted.

[0029] The sending unit is further configured to send a second instruction to the simulation network when the detection unit detects that not all of the data has been distributed. The second instruction is configured to instruct the source node and the destination node to continue to perform one or more detection tasks after sending a batch of detection messages for the current detection task, until all of the series of configuration data has been distributed.

[0030] The determining unit is used to count the total number of probe messages received from the destination node, compare the total number of probe messages with the total number of probe messages sent by the source node, and determine the connectivity detection results of the two virtual ports from the source node to the destination node based on the comparison result.

[0031] Fourthly, embodiments of the present invention also disclose a connectivity detection device for a simulated network, the device comprising:

[0032] The receiving unit is used to receive a series of configuration data and a first instruction sent by the simulation controller;

[0033] The startup unit is used to start a probe task when the first instruction is received. The probe task includes a source node in the simulation network sending a batch of probe messages to a destination node in the simulation network, and the destination node encapsulating and sending the probe message to the simulation controller after receiving each probe message sent by the source node.

[0034] The receiving unit is also used to receive a second instruction sent by the simulation controller when receiving the series of configuration data;

[0035] The control unit is configured to respond to the second instruction to control the source node and the destination node to continue executing one or more probe tasks after sending a batch of probe messages for the current probe task, until all the series of configuration data has been sent.

[0036] Fifthly, embodiments of the present invention also disclose an electronic device, including: a processor and a memory; wherein the memory and the processor are coupled, and the memory stores computer program instructions, which, when executed by the processor, implement the connectivity detection method of the simulated network as described in the first aspect or any embodiment of the first aspect, or the second aspect or any embodiment of the second aspect.

[0037] In addition, embodiments of the present invention also disclose a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the connectivity detection method of the simulated network as described in the first aspect or any embodiment of the first aspect, or the second aspect or any embodiment of the second aspect.

[0038] The method provided in this embodiment continuously performs connectivity detection of service traffic between various virtual ports during the configuration distribution process of the simulation controller, thereby providing a strong basis for the distribution of configuration from the simulation environment to the production state, and more closely reflecting the impact of configuration distribution on service traffic connectivity in real-world scenarios.

[0039] In addition, this method fully simulates packet loss during the configuration distribution process in the simulation state, thereby ensuring that packet loss will not occur in the real environment (production state) configuration distribution process due to configuration coupling or intermediate process modifications, thus solving the technical problem of packet loss and inability to simulate during configuration data distribution. Attached Figure Description

[0040] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0041] Figure 1 A framework diagram of a simulation system provided in an embodiment of the present invention;

[0042] Figure 2 A flowchart of a connectivity detection method provided in an embodiment of the present invention;

[0043] Figure 3 A flowchart of another connectivity detection method provided in an embodiment of the present invention;

[0044] Figure 4 A signaling flowchart for transmitting and receiving during a detection mission is provided as an embodiment of the present invention;

[0045] Figure 5A flowchart for detecting whether configuration data has been successfully distributed, provided as an embodiment of the present invention;

[0046] Figure 6 A flowchart of yet another connectivity detection method provided in an embodiment of the present invention;

[0047] Figure 7 A structural block diagram of a detection device provided in an embodiment of the present invention;

[0048] Figure 8 A structural block diagram of another detection device provided in an embodiment of the present invention;

[0049] Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0050] To enable those skilled in the art to better understand the technical solutions in the embodiments of this application, and to make the above-mentioned objectives, features and advantages of the embodiments of this application more apparent and understandable, the technical solutions in the embodiments of this application will be further described in detail below with reference to the accompanying drawings.

[0051] Before describing the technical solutions of the embodiments of this application, the application scenarios of the embodiments of this application will first be described with reference to the accompanying drawings.

[0052] The technical solution of this application can be applied to SDN (Software Defined Network), such as... Figure 1 As shown, this SDN network includes production and design states. The production state refers to the state where service orchestration and configuration are performed in "tenant management" before entering the simulation system; the service orchestration performed there will be distributed to real physical devices.

[0053] The so-called design state (or simulation state) refers to the state where logical network service orchestration and simulation verification are performed within the simulation system's "tenant service simulation." The orchestrated services are deployed to the design state database, not to the actual physical devices. Only after the user clicks "configure provisioning" will the data be submitted to the production state, and subsequently deployed to the actual physical devices in the production state.

[0054] In the simulation state, the simulation network can be a digital twin network (DTN) or a DTN management module (DTN Manager): used for the lifecycle management of simulation devices, including the creation and destruction of simulation devices.

[0055] exist Figure 1The system architecture shown includes a production state and a simulation state. The production state includes a controller and a production network. The production network includes multiple switches and other network devices. Each switch in the production network can also connect to virtual machines, for example, an end-to-end connection between virtual machine 1 and virtual machine 2.

[0056] The simulation architecture includes a simulation controller and a simulation network. The simulation controller can communicate with the production controller, for example, via a WLAN network. The simulation network can be simulated using a simulation device, such as a DTN node or DTN component. The simulation network can simulate various switches in the production network, as well as virtual machines 1 and 2 connected to the switches. Specifically, the simulation can be achieved through two virtual ports (vports).

[0057] The simulation controller can start and execute at least one process, such as process 1 and process 2. Process 1 can be the main program, used to start the simulation network and begin the probe task; process 2 can be an auxiliary program, such as used to instruct rollback commands or instruct DTN nodes to roll back. In addition, other processes may be included, which are not limited in this embodiment.

[0058] It should be understood that the aforementioned controller or simulation controller can be a network device, including but not limited to servers, server clusters, control centers, data centers, etc.

[0059] Simulation technology uses comprehensive system models and resource acquisition to simulate and analyze real-world environments and business operations, identifying potential risks in advance based on available information. Specific business deployments for simulation include: simulation service deployment, simulation network construction, tenant business simulation, and configuration provisioning.

[0060] The simulation service deployment involves deploying a digital twin DTN component to handle simulation-related services. The deployment host is the physical server that hosts virtual devices and builds the simulation network, forming the basis for physical isolation between the production and simulation environments. Separate host deployment and configuration are required for the entire simulation functionality.

[0061] Simulated Network Construction: The simulated network is built by using virtual switches to simulate the real network environment on a one-to-one basis. Within the simulated network environment, pre-deployment verification and simulation functions are implemented. The simulated network environment corresponding to the real network can be simulated by constructing a simulated network. The process of constructing a simulated network mainly includes creating virtual devices, initializing device configurations, and synchronizing relevant parameters from the real network to the simulation environment. Multiple Fabrics can be built.

[0062] Tenant service simulation: This refers to the ability of users to configure and modify services such as vrouter, network, subnet, application policies, and EPG in a simulated state, and then distribute the changes to the virtual devices in the simulated state. Simulation evaluation can then be performed, with capabilities encompassing capacity consumption prediction, connectivity simulation, and overall network impact assessment. This application's embodiments primarily discuss connectivity simulation.

[0063] Configuration Deployment: When the simulation evaluation results meet expectations, the design-state business needs to deploy the simulation configuration to the production-state equipment via REST (Representational State Transfer), so that the production-state equipment becomes the equipment for formal business deployment.

[0064] This application's embodiments primarily discuss connectivity detection in simulation. When performing simulation, a simulated network is first constructed, using virtual switches to simulate the real network environment (production state) and device configuration at a 1:1 scale. Then, tenant service simulation is performed.

[0065] Tenant service simulation mainly includes two steps: Step 1, design-state orchestration; Step 2, simulation evaluation, which includes connectivity detection.

[0066] Specifically, design-state orchestration refers to the ability of users to perform design-state orchestration in a simulation environment (the initial configuration in design state is consistent with the configuration in the real environment). Users can add, delete, and modify virtual routers, virtual link-layer networks, subnets, virtual router links, virtual ports, application policies, EPGs, etc. The related services in design-state orchestration will not affect the real environment (production state); they will only be added, deleted, or modified on the simulated devices in the simulation state.

[0067] Simulation evaluation (including connectivity detection) refers to the pre-verification of tenant service changes after the above-described design-state orchestration. Simulation evaluation capabilities are reflected in three aspects: capacity consumption prediction, connectivity simulation, and network-wide impact assessment. Services can only be deployed to production mode when the evaluation results meet user expectations. Connectivity simulation specifically refers to assessing the impact of service changes on virtual port connectivity, including results before and after the service change.

[0068] Furthermore, connectivity simulation employs a low-level packet sending mechanism and leverages OpenFlow's message uploading function to achieve connectivity detection and message path tracing between virtual ports (vports).

[0069] Internally, the simulation environment mimics virtual machines in a real-world environment. For example, a namespace is created in a Linux system to replace a temporary virtual machine (or virtual machine). Within this temporary virtual machine, TCP (Transmission Control Protocol) or UDP (User Datagram Protocol) packets are initiated. As the packets pass through all devices from the source to the destination node, messages are sent to the simulation controller via OpenFlow to determine the traversed devices and connectivity. Predefined fields in the received packets at the destination node are used to confirm whether intermediate nodes have lost packets and whether the probing task has ended.

[0070] The overall network impact assessment takes a holistic business perspective, quickly evaluating the impact of design-state service changes on the connectivity of Overlay network links. It compares and outputs the virtual port connectivity results before the simulation (before the configuration change) with the virtual port connectivity results after the simulation (after the configuration change), making it easy for users to quickly view the impact of configuration changes on traffic.

[0071] During the network-wide impact assessment, connectivity detection results only provide the results before and after the configuration change. The results are relatively independent and do not include intermediate states. However, in real-world scenarios, changes to the configuration on the simulation controller during normal operation often involve deletion and addition of device configurations (flow tables, service configurations, routes, etc.), configuration coupling, and route iteration. This can lead to packet loss in service traffic during the configuration change process, but traffic returns to normal after all configurations are completed. Such packet loss during intermediate processes caused by configuration changes cannot be simulated in the simulation.

[0072] Furthermore, packet loss caused by such configuration changes may not be acceptable in a live environment. For example, at a customer's site, packet loss during the configuration update process manifests as a brief interruption in traffic. This could result in a few seconds of page lag when a user is watching online TV, thus impacting the user experience. This is something that cannot be simulated during the simulation process.

[0073] For example, if the number of packets to be sent is configured by the program before connectivity testing (e.g., 3 or 5), it will be impossible to automatically adjust the number of packets and the duration of packet transmission according to the scenario. For instance, it may take a certain amount of time for the simulation controller to send configuration to the simulation device, while the virtual machine in the namespace may send probe packets earlier than the time the configuration data is sent. In this case, the time of sending probe packets and the time of sending configuration data by the simulation controller are misaligned, which means that the duration of the probe packets sent by the simulation device does not fully cover the entire configuration data transmission process. Consequently, packet loss during the configuration data transmission process cannot be detected, and the scenario cannot be simulated. Therefore, when the configuration is distributed in the real environment, it may lead to packet loss in the real environment.

[0074] To address the issue of packet loss occurring during the simulation configuration process but failing to be monitored, this application provides a connectivity detection method for simulated networks.

[0075] See Figure 2 This is a flowchart illustrating a connectivity detection method provided in an embodiment of this application. The method is applied to... Figure 1 The scenario architecture shown, for example, is applied to a simulation controller, and the simulation process specifically includes:

[0076] First, begin a full network assessment, i.e., initiate connectivity detection; optionally, if configuration modifications were made before the simulation controller executes the packet sending task, the simulation network configuration must be rolled back to its initial state before configuration.

[0077] Then, the simulation network is controlled to perform a packet sending task. For example, before the new configuration is issued in the simulation environment, the namespace virtual machine starts to perform a probe task, sending probe packets from the source node to the destination node of the simulation network. At the same time, the destination node encapsulates the received probe packets and feeds them back to the simulation controller. If the data in some fields carried in the probe packet matches the predetermined negotiation content, the simulation controller considers that it has received a probe packet. The simulation controller gradually accumulates the number of probe packets received.

[0078] The simulation controller then begins sending configuration data to the simulation network. During this process, the simulation controller periodically checks whether the configuration data has been sent completely. If not, it continues to instruct the source node of the simulation network to send probe messages until all configuration data has been sent. If the data has been sent completely, it instructs the simulation network to perform one more (+1) probe task, and then stops the probe task.

[0079] The simulation controller counts the total number of probe packets and the total number of probe packets sent by the source node based on the number of probe packets sent by the destination node in the simulation network, and compares whether packet loss occurred during the probe process and the number of lost packets.

[0080] Finally, the simulation controller distributes the configuration to the production state. The impact of this distribution process on business traffic is completely controllable because the simulation controller has realistically simulated the entire process of configuration distribution and packet sending, thereby enabling it to monitor whether packet loss occurs during the simulation process and the number of lost packets.

[0081] The method provided in this embodiment will be described in detail below.

[0082] In the simulation environment, the customer adds, deletes, or modifies some configurations through the simulation controller page. It is necessary to detect the impact of the configuration changes on the original service traffic, device capacity consumption, etc. At this time, it is necessary to conduct a network-wide impact assessment or conduct a separate connectivity simulation probe. This embodiment mainly describes the connectivity probe process.

[0083] See Figure 3 This embodiment provides a connectivity simulation detection method applied to a simulation controller. The method includes:

[0084] Step 101: When sending a series of configuration data to the simulation network, a first instruction is sent to the simulation network. The first instruction is used to start a probe task on the path from the source node to the destination node in the simulation network.

[0085] The probing task includes the source node sending a batch of probe messages to the destination node, and the destination node encapsulating and sending each probe message received from the source node to the simulation controller. Specifically, the source node and the destination node are two simulation nodes in the simulation network, corresponding to switches connected to two virtual machines in the real environment, such as two switches connected to virtual machines 1 and 2. The transmission path between these two simulation nodes passes through one or more intermediate nodes, and the probe messages sent by the source node may reach the destination node after passing through at least one intermediate node, or they may be lost and fail to reach the destination node. If the destination node receives a probe message from the previous hop device, it matches the content of the probe message. If a match is found, the destination node encapsulates the probe message header and sends it to the simulation controller. Specifically, there is an OpenFlow communication connection between the destination node and the simulation controller, so the destination node can report the encapsulated probe messages to the simulation controller via OpenFlow.

[0086] In addition, if the destination node fails to match the content of the received probe message, it will not encapsulate and report the probe message.

[0087] In the process of the simulation controller sending the first instruction to the simulation network, one implementation is that the simulation controller sends the first instruction by calling the main process, such as starting the simulation network through a namespace and executing a probe task. For the simulation network, a probe task can be the source node sending N probe messages (or probe packets) to the destination node. Optionally, N = 2000, and the packet sending frequency is 10 packets / second. Therefore, completing a probe task takes 200 seconds. It should be understood that in actual implementation, the total number of packets sent and the packet sending frequency of a probe task can be customized or configured by the user. This embodiment does not impose any restrictions on this.

[0088] In addition, in this embodiment, the probe path from the source node to the destination node can be determined through negotiation, including the communication protocol and agreed-upon fields.

[0089] In step 101, after the simulation network initiates the probing task, the simulation controller begins to send a series of configuration data to the simulation network. This configuration data can be orchestrated data, and the simulation controller sends this orchestrated data to the simulation network one line at a time. The order and logic of sending the configuration data are the same as the order in which the simulation controller issues configurations to the production environment, the purpose of which is to ensure that the simulation network can realistically simulate the configuration issuance process of the production environment.

[0090] Furthermore, the series of configuration data can be determined according to specific business configurations, including VPN, network, etc.

[0091] In addition, during the process of distributing a series of configuration data, the simulation controller continues to receive encapsulated probe messages reported by the destination node of the simulation network. At the same time, the source node of the simulation network is also constantly sending probe messages to the destination node, thereby ensuring that the simulation controller is constantly probing and listening for probe messages during the configuration data distribution process.

[0092] Step 102: At a preset time during the detection message distribution process, detect whether all the series of configuration data has been distributed.

[0093] This process involves the main program / process in the simulation controller querying the target node of the simulation network to obtain the detection results. The preset time interval can be customized by the simulation controller, for example, by periodically detecting or initiating a query at a specific preset time.

[0094] Specifically, one detection process is as follows: the main program / process in the simulation controller checks whether NETCONF (Network Configuration Protocol) is still sending configuration data, summarizing the process of sending a series of configuration data, and whether all sent commands have received responses from the destination nodes of the simulated network. The simulation controller can wait for a certain period to confirm whether there is still configuration data that has not been completely sent. If there is still configuration data that has not been completely sent, step 103 is executed; if not, that is, all configuration data has been completely sent, step 104 is executed.

[0095] NETCONF provides a protocol for communication between the controller and network devices. The controller uses NETCONF to distribute, modify, and delete configurations for remote devices. Network devices provide standardized APIs (Application Programming Interfaces), which the controller can use to manage network devices via NETCONF.

[0096] In addition, before determining whether all the configuration data has been distributed, it is also checked whether the simulation controller distributes the configuration data one by one in sequence. If so, the step of determining whether the distribution of the configuration data has been completed continues; if not, the distribution of configuration data is stopped, indicating that there is a problem with the current distribution of configuration data, and the process returns to step 101.

[0097] Step 103: Send a second instruction to the simulation network. The second instruction is used to instruct the source node and the destination node to continue to perform one or more probe tasks after sending a batch of probe messages for the current probe task, until all the series of configuration data has been distributed.

[0098] For example, the simulation controller's timed detection period for configuration distribution is 198 seconds (adjustable in actual implementation), which is less than the 200-second duration of a single detection task. In this example, the configuration distribution duration is tentatively set to be less than the time of a single packet sending task in the Namespace, and both start timing simultaneously. When the timed task detects that the simulation controller has not completely distributed a series of configuration data, a detection task is added to the packet sending task. For example, by calling another process (such as process 2) to send the second instruction to the source node and destination node of the simulation network, it is instructed that when the timed task detects that the simulation controller has completed the distribution of a series of configuration data, another detection task should be executed (that is, the packet sending task of N detection packets is added to the packet sending queue), so that during the distribution of a series of configuration data, the source node always sends detection packets to the destination node, performing a listening detection task.

[0099] Once the timed task detects that the simulation controller has finished sending all configuration data, it adds a probe task to the packet sending task and then terminates the timed probe task. After the probe task ends, the source node of the simulation network continues to send queued probe packets to the destination node until all queued packets have been sent, at which point packet sending stops.

[0100] Step 104: Count the total number of probe messages received by the simulation controller from the destination node, and compare the total number of probe messages with the total number of probe messages sent by the source node.

[0101] Step 105: Determine the connectivity detection results of the two virtual ports from the source node to the destination node based on the comparison results.

[0102] Specifically, this includes: if the total number of probe packets sent by the destination node is not the same as the total number of probe packets sent by the source node, then determining that a packet loss has occurred in the connectivity probe results between the source node and the destination node, and determining that the number of packet losses is the difference between these two totals.

[0103] Furthermore, the simulation controller counts the total number of probe packets sent from the source node to the destination node. Based on the number of packet sending commands it issues, the simulation controller determines the total number of probe packets sent by the Namespace virtual machine. This total number equals the number of probe packets sent in a single task multiplied by the number of packet sending commands. Taking the example of N = 2000 packets sent in a single probe task, with two packet sending commands, the simulation controller determines the total number of probe packets sent from the source node to the destination node to be: 2000 * 2 = 4000 (packets).

[0104] The simulation controller counts the total number of probe packets returned by the destination node. The controller uses a flow table pre-issued to the destination node, which includes packet content matching and action information. This allows the destination node in the simulated network to perform matching and corresponding actions upon receiving a probe packet from the source node, including encapsulating the probe packet and sending it to the simulation controller. The simulation controller determines whether the packet is a connectivity probe packet based on agreed-upon fields in the sent probe packet; if so, it increments the connectivity probe packet count by 1.

[0105] In addition, each probe packet sent can also carry the total number of probe packets in a probe mission (for example, the number of packets N in a probe mission in this example is 2000). The Seq field count in the probe packet sent to the simulation server is incremented by 1 each time. The simulation server uses this count to determine whether the current probe packet is a new packet, and the simulation controller uses it to confirm whether all probe packets in each probe mission have been received. If the number of probe packets counted in a single packet sending mission is less than 2000, it is determined that packet loss has occurred from the source node to the destination node in the connectivity probe mission; if it is equal to 2000, it is determined that no packet loss has occurred.

[0106] Specifically, the simulation server can be set to a timeout period (e.g., 3 seconds). If the number of probe packets counted within 3 seconds is less than 2000, then packet loss is determined to have occurred.

[0107] Furthermore, the difference between the total number of probe messages sent by the source node and the total number of probe messages sent by the destination node, as counted by the simulation server, is the number of lost packets.

[0108] Connectivity detection results: If packet loss is detected, the user can promptly analyze and troubleshoot the cause. If no packet loss is detected, the user can distribute the simulation configuration data from the simulation state to the production state, and then configure it to take effect in the production state and distribute it to the production state devices. Since the simulated connectivity detection in the simulation state is almost identical to the configuration distribution sequence and logic in the production state, it ensures that there will be no packet loss during the configuration distribution process in the production state.

[0109] The method provided in this embodiment continuously performs connectivity detection of service traffic between various vports during the configuration distribution process of the simulation controller, thereby providing a strong basis for the distribution of configuration from the simulation environment to the production state, and more closely reflecting the impact of configuration distribution on service traffic connectivity in real-world scenarios.

[0110] In addition, this method fully simulates packet loss during the configuration distribution process in the simulation state, thereby ensuring that packet loss will not occur in the real environment (production state) configuration distribution process due to configuration coupling or intermediate process modifications, thus solving the technical problem of packet loss and inability to simulate during configuration data distribution.

[0111] Optionally, prior to step 101 above, the method further includes:

[0112] If a user modifies at least a portion of the configuration of the simulation controller, causing a corresponding modification to at least a portion of the configuration in the simulation network, a rollback command is sent to the simulation network. The rollback command instructs the simulation network to clear the modifications to the at least a portion of the configuration and roll back to the initial state of the simulation network.

[0113] This step is part of the configuration rollback process. The user has made some configuration modifications (or orchestrations) to the simulation controller. The configuration modifications to the simulation controller will correspond to the configuration modifications of the simulation devices. In order to continuously detect packet loss in the service traffic during the entire configuration distribution process, it is necessary to roll back the corresponding configuration in the simulation network.

[0114] The rollback command can be sent after the simulation controller performs a full network impact assessment or connectivity probe. The simulation controller initiates the rollback process of the simulation device, rolling back all services orchestrated by the user in the simulation state to their initial state, that is, returning to the state when the simulation network was first built. This state is consistent with the production state configuration. It should be noted that the simulation controller configuration rollback will simultaneously add, delete, or modify the configuration on the simulation device, causing the simulation device configuration to also roll back to the initial state when the simulation network was first built.

[0115] Optionally, in one possible implementation of this embodiment, in step 101 above, when the simulation controller initiates a probe task on the path from the source node to the destination node in the simulation network, such as... Figure 4As shown, the method also includes:

[0116] Step 401: The simulation controller sends a flow table to the simulation network. The flow table includes message matching information and action information.

[0117] Specifically, the simulation controller sends a flow table to at least one node on at least one probe path (the path that requires connectivity detection) of the simulation network, and correspondingly, all simulation nodes within the scope of the simulation controller receive the flow table.

[0118] Wherein, the matching item information is used for at least one destination node to execute the action corresponding to the action item information after the received probe message matches the matching item information; the action item information is used to instruct the matching destination node to perform the action of encapsulating the probe message from the source node and sending it to the simulation controller.

[0119] Step 402: The target node in the simulation network is matched according to the matching item information.

[0120] The matching information includes the IP address matching of the destination node and the matching of a preset identifier (DSCP value). In the connectivity probe packet delivery task, each probe packet sent by the source node to the destination node carries information such as the IP address of the source node, the IP address of the destination node, and the preset DSCP (Differentiated Services CodePoint) value.

[0121] The preset DSCP value is located in the Service Class of Service (TOS) identifier byte of the IP header of each probe packet. It uses 6 used bits and 2 unused bits to distinguish priorities through encoded values. For example, the preset DSCP uses 6 bits and the DSCP value ranges from 0 to 63. Optionally, in this embodiment, the preset DSCP value is assumed to be 30.

[0122] After receiving a probe packet from the source node, the destination node parses and determines whether the destination IP address indicated in the probe packet is the IP address of the current destination node, and checks whether the DSCP value carried in the packet is 30. For example, by parsing the UUID (Universally Unique Identifier) ​​of the source node and the destination node obtained from the probe packet, it determines whether the IP address of the destination node is the same. If the IP addresses of the matching destination nodes are the same and the DSCP value is also 30, then the match is successful, and step 403 is executed.

[0123] Step 403: If the match is successful, the probe message is encapsulated according to the content of the action item information, and the encapsulated probe message is sent to the simulation controller.

[0124] The action item information instructs the destination node to encapsulate the currently received probe message with a message header and send the encapsulated probe message to the simulation controller via OpenFlow.

[0125] Step 404: The simulation controller receives the encapsulated probe message reported by the matched destination node and increments the count of probe messages by 1.

[0126] After receiving the probe packet, the simulation controller determines that the current packet is based on a probe packet response based on the DSCP value carried in the probe packet. To distinguish it from ordinary packets, the simulation controller uses certain agreed-upon fields in the probe packet's data, such as certain special fields and the Seq field, including the UUID of the source node's vport and the UUID of the destination node's vport, to determine which two nodes' vports are being probed. Based on the agreed-upon fields in the probe packet, the controller can also determine which packet in the current probe task (out of 2000 packets) it is, and the total number of packets sent (2000). The simulation controller increments its counter by 1 for each encapsulated probe packet received from the destination node, preparing for subsequent connectivity probe packet loss assessment and calculation.

[0127] Optional, such as Figure 5 As shown, step 102 above specifically includes:

[0128] Step 102-1: Receive at least one response from the target node of the simulation network based on the series of configuration data.

[0129] Step 102-2: Count the total number of responses.

[0130] Step 102-3: Determine whether the total number of the response responses is the same as the total number of the series of configuration data sent.

[0131] Step 102-4: If they are the same, then it is determined that all the configuration data in the series has been distributed. Otherwise, it is determined that the configuration data in the series has not been distributed.

[0132] Specifically, whenever the simulation controller sends configuration data to the simulation network, the destination node in the simulation network will send back a response, such as "OK," and the two devices will interact with each other. If the simulation network is busy, the destination node may delay sending back a response for a few seconds. In this case, the simulation controller can wait for a period of time and then count the total number of all responses.

[0133] After a certain waiting period, the simulation controller determines whether the total number of "OK" responses is the same as the total number of configuration data sent. If they are the same, it determines that all configuration data has been sent to the simulation network; otherwise, it determines that not all configuration data has been sent to the simulation network.

[0134] Furthermore, in another embodiment, this application also provides a connectivity simulation detection method, which can be applied to the aforementioned simulated network, the simulated network being simulated by a simulation device, such as... Figure 6 As shown, the method includes:

[0135] Step 201: Receive a series of configuration data and a first instruction sent by the simulation controller, and start the probe mission.

[0136] The first instruction is used to initiate a probe task on the path from the source node to the destination node in the simulation network. The probe task includes the source node in the simulation network sending a batch of probe messages to the destination node, and the destination node encapsulating and sending the probe message to the simulation controller after receiving each probe message sent by the source node.

[0137] Specifically, this step corresponds to step 101 in the aforementioned embodiment, as detailed in the description of step 101. Additionally, it includes sending a response, such as an "OK" response, to the simulation controller each time the destination node receives a configuration data transmission from the simulation controller. This response indicates that the destination node has received the current configuration data sent by the simulation controller.

[0138] Step 202: During the process of receiving the series of configuration data, a second instruction sent by the simulation controller is received.

[0139] The second instruction is used to instruct the source node and the destination node to continue to perform one or more probe tasks after sending a batch of probe messages for the current probe task, until all the series of configuration data has been sent.

[0140] Step 203: In response to the second instruction, control the source node and the destination node to continue to execute one or more probe tasks after sending a batch of probe messages for the current probe task, until all the series of configuration data has been sent.

[0141] The steps in this embodiment correspond to steps 102 to 103 in the previous embodiment. For the specific process, please refer to the description in the previous embodiment. This embodiment will not elaborate on this process in detail.

[0142] Additionally, in step 101, the method further includes: the simulation network receiving a rollback command sent by the simulation controller; in response to the rollback command, clearing at least some configuration modifications made by the user to the simulation controller, and rolling back to the initial state of the simulation network, so that the probe task is started before any configuration data is issued.

[0143] Optionally, corresponding to the aforementioned, as shown above. Figure 4 The method flow shown includes:

[0144] The source and destination nodes in the simulation network receive flow tables sent by the simulation controller. The flow tables include packet matching information and action information, such as DSCP values ​​and destination IP addresses. The destination node of the simulation network receives probe packets from the source node, matches them according to the matching information, and if a match is successful, encapsulates the probe packets according to the action information and sends the encapsulated probe packets to the simulation controller.

[0145] In this embodiment, during the transmission of probe messages between the source node and the destination node, the destination node matches the content of the received probe messages with matching item information, encapsulates the matching probe messages, sends them to the simulation controller, and executes the corresponding action items. This allows the simulation controller to obtain relevant information about connectivity detection, such as the number of probe messages being detected, the path being detected, and the virtual ports (vports) of the source and destination nodes on that path, through the reported probe messages. Thus, connectivity results can be determined by statistically analyzing the content and quantity of these probe messages.

[0146] This invention also discloses a connectivity detection device for a simulated network, which is used to achieve the aforementioned... Figures 2 to 5 The detection method described above, such as Figure 7 As shown, the device includes a transmitting unit 701, a detection unit 702, and a determining unit 703. In addition, the device may also include other units / modules such as a transmitting unit and a storage unit. This embodiment does not limit this.

[0147] The sending unit 701 is used to send a series of configuration data to the simulation network, and when sending the series of configuration data, it also sends a first instruction to the simulation network. The first instruction is used to start a probe task on the path from the source node to the destination node in the simulation network. The probe task includes the source node sending a batch of probe messages to the destination node, and the destination node encapsulating and sending the probe message to the simulation controller after receiving each probe message sent by the source node.

[0148] The detection unit 702 is used to detect at a preset time during the detection message transmission process whether all the series of configuration data has been transmitted.

[0149] The sending unit 701 is further configured to send a second instruction to the simulation network when the detection unit detects that not all of the data has been distributed. The second instruction is configured to instruct the source node and the destination node to continue to perform one or more detection tasks after sending a batch of detection messages for the current detection task, until all of the series of configuration data has been distributed.

[0150] The determining unit 703 is used to count the total number of probe messages received from the destination node, compare the total number of probe messages with the total number of probe messages sent by the source node, and determine the connectivity detection results of the two virtual ports from the source node to the destination node based on the comparison result.

[0151] In addition, the aforementioned sending unit 701, detection unit 702, and determination unit 703 are also used to perform other parts or all of the functions of the aforementioned simulation controller.

[0152] In yet another embodiment, this application also provides a different connectivity simulation detection device, which is used to perform the aforementioned... Figure 6 The method steps shown are, specifically, as follows: Figure 8 As shown, the device includes a receiving unit 801, a starting unit 802, and a control unit 803. In addition, the device may also include other functional modules, such as a sending unit and a storage unit.

[0153] The receiving unit 801 is used to receive a series of configuration data and a first instruction sent by the simulation controller.

[0154] The startup unit 802 is used to start a probe task when the receiving unit 801 receives the first instruction. The probe task includes the source node in the simulation network sending a batch of probe messages to the destination node in the simulation network, and the destination node in the simulation network encapsulating and sending the probe message to the simulation controller after receiving each probe message sent by the source node.

[0155] The receiving unit 801 is also used to receive a second instruction sent by the simulation controller when receiving the series of configuration data.

[0156] Control unit 803 is configured to respond to the second instruction to control the source node and the destination node to continue to execute one or more probe tasks after sending a batch of probe messages for the current probe task, until all the series of configuration data has been sent.

[0157] In addition, the aforementioned receiving unit 801, starting unit 802, and control unit 803 are also used to perform other parts or all of the functions of the source node and destination node of the aforementioned simulation network.

[0158] The detection device provided in this embodiment continuously performs connectivity detection tasks for service traffic between various virtual ports during the configuration distribution process of the simulation controller, thereby providing a strong basis for the distribution of configuration from the simulation environment to the production state, and more closely reflecting the impact of configuration distribution on service traffic connectivity in real scenarios.

[0159] In addition, the simulation mode fully simulates the packet loss of business traffic during the configuration distribution process, thus ensuring that packet loss will not occur in the real environment (production mode) during configuration distribution due to configuration coupling or intermediate process modifications, thereby solving the technical problem of packet loss and inability to simulate during configuration data distribution.

[0160] In addition, embodiments of the present invention also provide an electronic device, such as... Figure 9 As shown, the electronic device may include a processor 110 and a memory 120, wherein the processor 110 and the memory 120 may be connected via a bus or other means. Figure 9 For example, the connection is via a bus. Furthermore, the electronic device also includes at least one interface 130, which can be a communication interface or other interface; this embodiment does not impose any limitations on this.

[0161] The electronic device can be the simulation controller in the above embodiments, or it can be a simulation device in a simulation network, or it can be other devices in the production state, such as switches, controllers, etc.

[0162] The processor 110 can be a central processing unit (CPU). The processor 110 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0163] The memory 120, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the connectivity detection method in the embodiments of the present invention. The processor 110 executes various functional applications and data processing of the processor by running the non-transitory software programs, instructions, and modules stored in the memory 120, thereby implementing the connectivity detection method of the simulated network in the above method embodiments.

[0164] The memory 120 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor 110, etc. Furthermore, the memory 120 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 120 may optionally include memory remotely located relative to the processor 110, and these remote memories may be connected to the processor 110 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0165] In addition, at least one interface 130 is used for communication between the electronic device and external devices, such as communication with a server. Optionally, at least one interface 130 can also be used to connect peripheral input / output devices, such as a keyboard or display screen.

[0166] The one or more modules are stored in the memory 120, and when executed by the processor 110, they perform actions such as... Figures 1 to 3 The connectivity detection method in the illustrated embodiment.

[0167] Furthermore, this application embodiment also provides a connectivity simulation detection system, which includes a simulation controller and a simulation network. The simulation network can be implemented using at least one simulation device, and the connectivity results from the source node to the destination node can be simulated in the simulation network. The simulation controller and simulation network in this system are used to implement the connectivity detection method in the aforementioned embodiments, thereby solving the technical problem of packet loss and inability to simulate during configuration data distribution. This ensures that packet loss does not occur during the distribution of configuration in the real environment (production state) due to configuration coupling or intermediate process modifications, thereby improving the service performance of the simulated configuration in the production state.

[0168] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0169] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A connectivity detection method for a simulated network, characterized in that, Applied to a simulation controller, the method includes: When sending a series of configuration data to the simulation network, a first instruction is sent to the simulation network. The first instruction is used to start a probe task on the path from the source node to the destination node in the simulation network. The probe task includes the source node sending a batch of probe messages to the destination node, and the destination node encapsulating the probe message after receiving each probe message sent by the source node and sending the encapsulated probe message to the simulation controller. At a preset time during the probe message transmission process, it is detected whether all the series of configuration data has been transmitted. If not, a second instruction is sent to the simulation network. The second instruction is used to instruct the source node and the destination node to continue to perform one or more probe tasks after sending a batch of probe messages for the current probe task, until all the series of configuration data has been distributed. The simulation controller counts the total number of probe messages sent by the destination node, compares the total number of probe messages with the total number of probe messages sent by the source node, and determines the connectivity detection results of the two virtual ports from the source node to the destination node based on the comparison results.

2. The method according to claim 1, characterized in that, Before initiating a probe task on the path from the source node to the destination node in the simulation network, the following steps are also included: If a user modifies at least a portion of the configuration of the simulation controller, causing a corresponding modification to at least a portion of the configuration in the simulation network, a rollback command is sent to the simulation network. The rollback command instructs the simulation network to clear the modifications to the at least a portion of the configuration and roll back to the initial state of the simulation network.

3. The method according to claim 1, characterized in that, The method further includes: A flow table is sent to at least one node on at least one probe path of the simulated network, the flow table including message matching information and action information; Wherein, the matching item information is used for at least one destination node to execute the action corresponding to the action item information after the received probe message matches the matching item information; the action item information is used to instruct the matching destination node to perform the action of encapsulating the probe message from the source node and sending the encapsulated probe message to the simulation controller.

4. The method according to claim 1, characterized in that, The detection of whether all the configuration data has been distributed includes: Receive at least one response from the target node of the simulated network based on the series of configuration data; Count the total number of responses. If the total number of response replies is the same as the total number of configuration data items issued, then it is determined that all configuration data items have been issued.

5. The method according to any one of claims 1-4, characterized in that, The process of comparing the total number of probe packets with the total number of probe packets sent by the source node, and determining the connectivity probe results of the two virtual ports from the source node to the destination node based on the comparison result, includes: If the total number of probe packets is not the same as the total number of probe packets sent by the source node, then the connectivity probe result between the source node and the destination node is determined to be packet loss, and the number of packet losses is determined to be the difference between the two totals.

6. A connectivity detection method for a simulated network, characterized in that, Applied to simulated networks, the method includes: The system receives a series of configuration data and a first instruction sent by the simulation controller, and starts a probe task. The first instruction is used to start a probe task on the path from the source node to the destination node in the simulation network. The probe task includes the source node in the simulation network sending a batch of probe messages to the destination node of the simulation network, and the destination node encapsulating the probe message after receiving each probe message sent by the source node, and sending the encapsulated probe message to the simulation controller. During the process of receiving the series of configuration data, a second instruction sent by the simulation controller is received; wherein, at a preset time during the probe message distribution process, the simulation controller detects whether all the series of configuration data has been distributed; if not, the simulation controller sends a second instruction to the simulation network. In response to the second instruction, the source node and the destination node are controlled to continue executing one or more probe tasks after sending a batch of probe messages for the current probe task, until all the series of configuration data is distributed. This allows the simulation controller to count the total number of probe messages received from the destination node, compare the total number of probe messages with the total number of probe messages sent by the source node, and determine the connectivity probe results of the two virtual ports from the source node to the destination node based on the comparison results.

7. The method according to claim 6, characterized in that, Prior to initiating the probe mission, the following is also included: Receive the rollback command sent by the simulation controller; In response to the rollback command, the simulation network is rolled back to its initial state, clearing any configuration modifications made by the user to the simulation controller, at least some of which were previously made.

8. The method according to claim 6 or 7, characterized in that, The method further includes: Receive the flow table sent by the simulation controller, the flow table including message matching information and action information; The destination node of the simulation network will receive probe messages from the source node, match them according to the matching item information, and if the match is successful, encapsulate the probe message according to the content of the action item information and send the encapsulated probe message to the simulation controller.

9. The method according to claim 6 or 7, characterized in that, The method further includes: Each time the destination node of the simulation network receives a configuration data message from the simulation controller, it sends a response message back to the simulation controller. The response message indicates that the destination node has received the current configuration data sent by the simulation controller.

10. A connectivity detection device for a simulated network, characterized in that, The device, applied to a simulation controller, includes: The sending unit is used to send a series of configuration data to the simulation network, and when sending the series of configuration data, it also sends a first instruction to the simulation network. The first instruction is used to start a probe task on the path from the source node to the destination node in the simulation network. The probe task includes the source node sending a batch of probe messages to the destination node, and the destination node encapsulating the probe message after receiving each probe message sent by the source node, and sending the encapsulated probe message to the simulation controller. The detection unit is used to detect at a preset time during the transmission of the probe message whether all the series of configuration data has been transmitted. The sending unit is further configured to send a second instruction to the simulation network when the detection unit detects that not all of the data has been distributed. The second instruction is configured to instruct the source node and the destination node to continue to perform one or more detection tasks after sending a batch of detection messages for the current detection task, until all of the series of configuration data has been distributed. The determining unit is used to count the total number of probe messages received from the destination node, compare the total number of probe messages with the total number of probe messages sent by the source node, and determine the connectivity detection results of the two virtual ports from the source node to the destination node based on the comparison results.

11. A connectivity detection device for a simulated network, characterized in that, The device, used for simulating networks, includes: The receiving unit is used to receive a series of configuration data and a first instruction sent by the simulation controller; The startup unit is used to start a probe task when the first instruction is received. The first instruction is used to start a probe task on the path from the source node to the destination node in the simulation network. The probe task includes the source node in the simulation network sending a batch of probe messages to the destination node of the simulation network, and the destination node encapsulating the probe message after receiving each probe message sent by the source node and sending the encapsulated probe message to the simulation controller. The receiving unit is further configured to receive a second instruction sent by the simulation controller when receiving the series of configuration data; wherein, at a preset time during the probe message distribution process, the simulation controller detects whether all the series of configuration data has been distributed; if not, the simulation controller sends a second instruction to the simulation network. The control unit, in response to the second instruction, controls the source node and the destination node to continue executing one or more probe tasks after sending a batch of probe messages for the current probe task, until all the configuration data is distributed, so that the simulation controller counts the total number of probe messages received from the destination node, compares the total number of probe messages with the total number of probe messages sent by the source node, and determines the connectivity probe result of the two virtual ports from the source node to the destination node based on the comparison result.

12. An electronic device, characterized in that, It includes a processor and a memory, wherein the memory is coupled to the processor; The memory stores computer-readable program instructions that, when executed by the processor, implement the connectivity detection method for the simulated network as described in any one of claims 1 to 5, or 6 to 9.

13. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the connectivity detection method for the simulated network as described in any one of claims 1 to 5, or 6 to 9.

Images