A method and device for network equipment simulation implementation in micro-service network management

Abstract

The application discloses a network equipment simulation implementation method and device in a micro-service network management, wherein the method comprises the following steps: arranging a request response knowledge base of a managed equipment model, loading a configuration file into the request response knowledge base memory when a protocol-driven simulation service starts; adding equipment and establishing a mapping relationship between the equipment IP address and the equipment model and saving to Redis when the protocol-driven simulation service is used; when a northbound Restful API request reaches the protocol-driven simulation service, querying the corresponding equipment model in Redis according to the equipment IP address in the request URL, then querying the corresponding request response information in the memory according to the equipment model, finding the specific request response content according to the parameters in the request response information, and returning to the northbound. The method and device simulate the equipment by modifying the protocol-driven service, and feeding back the response information of different equipment to the upper collecting component by the configuration or the knowledge base, thereby playing the role of simulating the equipment.

Description

Technical Field

[0001] This invention relates to the field of network management technology, and in particular to a method and apparatus for simulating network devices in microservice-based network management. Background Technology

[0002] Network management systems (NMS) are widely used in network operations and maintenance departments of telecom operators and large and medium-sized enterprises to manage the FCAPS (Functions, Capabilities, and Solutions) of various heterogeneous devices in the network. During the development of NMS, vendors need to verify the NMS's ability to control various devices and test whether various NMS functions are working properly. However, NMS vendors do not always have access to all the real hardware devices. This is where network device simulators come in, such as the well-known GNS3, ENSP, and EVE-NG. These network device simulators load the device images of the corresponding NMS vendor, enabling them to realistically simulate device behavior, forward packets, learn routes, and respond to NMS interactions.

[0003] One of the core competencies of network management vendors is their ability to manage devices from multiple vendors. When managing devices from multiple vendors, they face the challenge of managing numerous devices from various vendors, and the number of device models from each vendor is constantly increasing. Network management vendors do not have the capacity to purchase all the devices they need to manage and put them in their own laboratories for testing. Using traditional simulators is also impractical, as most new devices do not have corresponding simulation images. Network management vendors even prohibit the release of the latest simulation images due to market competition.

[0004] In this situation, network management vendors typically obtain device management methods through various means, such as the OID of a private MIB (Management Information Base) or the echo content of a command line, output it as a design document, develop it within the company, and then test it on the operator's live network. This approach results in low development quality, problems need to be repeatedly modified and repeatedly deployed for verification, and the task development cycle is long.

[0005] In microservice-based network management, modules with different functions are typically abstracted into independent microservices, which interact with each other through RPC, message queues, and other methods. At the very bottom layer of the entire microservice-based network management system... Figure 1 In the protocol layer, there is usually a protocol driver service that uses common network management protocols such as SNMP, Telnet, SSH, and Netconf to interact with devices in the network element layer. Summary of the Invention

[0006] To address the challenges of managing devices from multiple vendors and models in a network management system, where private MIBs and command lines vary significantly and network management vendors are unable to build comprehensive testing environments, as well as the issues of regression verification during network management feature development, testing, and maintenance, this invention provides a method and apparatus for simulating network devices in a microservice-based network management system. This approach solves the aforementioned problems in a lightweight and low-cost manner, eliminating the need to purchase physical equipment or simulators in a laboratory while enabling long-term, repeated use to simulate real physical devices.

[0007] To achieve the above objectives, the present invention adopts the following technical solution:

[0008] In one embodiment of the present invention, a method for simulating network devices in a microservice-based network management system is proposed, the method comprising:

[0009] Organize the request and response knowledge base for managed device models, and load the configuration file into the request and response knowledge base memory when the protocol-driven simulation service starts;

[0010] When using the protocol-driven simulation service, add devices and establish a mapping relationship between device IP addresses and device models, saving it to Redis;

[0011] When a northbound RESTful API request reaches the protocol-driven simulation service, the corresponding device model is retrieved from Redis based on the device IP address in the northbound RESTful API request URL. Then, the corresponding request and response information is retrieved from the request and response knowledge base memory based on the device model. Finally, the specific request and response content is found based on the parameters in the request and response information and returned to the northbound RESTful API, thereby realizing the simulation of the device at the protocol layer.

[0012] Furthermore, the request-response knowledge base is organized in a hierarchical directory format, with configuration files organized in the manner of manufacturer => device category. Each configuration file contains the specific request protocol, request parameters, and request-response content. Within the configuration files of the same device category, the specific device model is matched using regular expressions.

[0013] Furthermore, the configuration file also includes the request latency.

[0014] In one embodiment of the present invention, a network device simulation implementation device for microservice-based network management is also proposed. This device includes: a protocol-driven simulation service module, which includes:

[0015] The knowledge base organization module is used to organize the request and response knowledge base of managed device models. When the protocol-driven simulation service starts, the configuration file is loaded into the request and response knowledge base memory.

[0016] The mapping relationship establishment module is used to add devices and establish a mapping relationship between device IP address and device model when the protocol-driven simulation service is used, and save it to Redis;

[0017] The request-response simulation module is used to retrieve the corresponding device model from Redis based on the device IP address in the northbound Restful API request URL when a northbound Restful API request arrives at the protocol-driven simulation service. Then, based on the device model, it retrieves the corresponding request-response information from the request-response knowledge base in memory. Finally, it finds the specific request-response content based on the parameters in the request-response information and returns it to the northbound Restful API, thereby simulating the device at the protocol layer.

[0018] Furthermore, the request-response knowledge base is organized in a hierarchical directory format, with configuration files organized in the manner of manufacturer => device category. Each configuration file contains the specific request protocol, request parameters, and request-response content. Within the configuration files of the same device category, the specific device model is matched using regular expressions.

[0019] Furthermore, the configuration file also includes the request latency.

[0020] In one embodiment of the present invention, a computer device is also proposed, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the aforementioned method for simulating network devices in microservice-based network management.

[0021] In one embodiment of the present invention, a computer-readable storage medium is also provided, which stores a computer program that executes a method for simulating network devices in a microservice-based network management system.

[0022] Beneficial effects:

[0023] 1. This invention fundamentally solves the problem of not being able to test and verify device characteristics due to the lack of real physical equipment or dedicated simulators.

[0024] 2. The solution of the present invention is simple and easy to implement, has high simulation accuracy of equipment management capability, and has zero impact on upper-level business.

[0025] 3. This invention greatly reduces the cost for network management vendors to purchase testing equipment or simulator images.

[0026] 4. This invention facilitates the construction of a device information knowledge base for network management vendors, gradually accumulating knowledge, raising the entry threshold for network management, and creating a competitive advantage. Attached Figure Description

[0027] Figure 1This is a layered architecture diagram of a microservice-based network management system;

[0028] Figure 2 This is a comparison diagram of the device simulation achieved by the present invention and traditional simulators;

[0029] Figure 3 This is a schematic diagram illustrating the engineering implementation of the protocol-driven simulation service of this invention.

[0030] Figure 4 This is a schematic diagram illustrating the process of receiving northbound Restful API requests and constructing simulated request responses according to the present invention.

[0031] Figure 5 This is a schematic diagram of the network device simulation implementation device for microservice-based network management according to the present invention;

[0032] Figure 6 This is a schematic diagram of the computer device structure of the present invention. Detailed Implementation

[0033] The principles and spirit of the present invention will now be described with reference to several exemplary embodiments. It should be understood that these embodiments are provided merely to enable those skilled in the art to better understand and implement the present invention, and are not intended to limit the scope of the present invention in any way. Rather, these embodiments are provided to make this disclosure more thorough and complete, and to fully convey the scope of this disclosure to those skilled in the art.

[0034] Those skilled in the art will recognize that embodiments of the present invention can be implemented as a system, apparatus, device, method, or computer program product. Therefore, this disclosure can be specifically implemented in the following forms: entirely hardware, entirely software (including firmware, resident software, microcode, etc.), or a combination of hardware and software.

[0035] According to an embodiment of the present invention, a method for simulating network devices in microservice-based network management is proposed, such as... Figure 2 As shown, the biggest difference between this invention and traditional simulators is that it does not perform simulation at the network element layer, but rather modifies the protocol driver service at the protocol layer. By enabling the protocol driver component to have device simulation capabilities, it truthfully feeds back the request and response content of different devices to the upper-layer acquisition component through configuration or knowledge base, thereby simulating the device and achieving the purpose of device simulation.

[0036] The principles and spirit of the present invention will be explained in detail below with reference to several representative embodiments.

[0037] The main design feature of this invention is: protocol-driven simulation service.

[0038] First, the protocol-driven simulation service is essentially indistinguishable from the real protocol-driven service on its northbound interface. This means that the upper-layer acquisition service is unaware of whether it is interfacing with the actual protocol-driven service or the protocol-driven simulation service. This also requires that the protocol-driven service itself be business logic-agnostic; its sole responsibility is to handle operations related to protocol interaction, and it should be able to reproduce the device's actual responses in a relatively raw manner. The northbound interface provided by the protocol-driven service primarily uses a RESTful API, which the upper-layer acquisition service calls to invoke the protocol-driven service.

[0039] Taking an SSH request as an example to illustrate the interface between the protocol-driven service and the upper-layer data collection service: Request URL: http: / / 127.0.0.1:23001 / v1 / agent / ssh / 192.168.10.100. The request URL contains the protocol type SSH and the device IP: 192.168.10.100. The information in the request URL clearly indicates which protocol is used to interact with which device.

[0040] In addition to the information mentioned above, interacting with devices via protocols also requires detailed protocol parameters and the content that needs to be exchanged with the device. Examples are as follows:

[0041]

[0042]

[0043] The request body above contains the username and password for the SSH request, as well as the command to be executed, "displayusers".

[0044] The following is an example of the content returned by the protocol-driven service:

[0045]

[0046] The returned JSON body includes the request error code and description, as well as the executed command and result. The upper-layer data acquisition service processes the result after receiving the response from the protocol-driven service and performs other business processing.

[0047] The protocol-driven simulation service uses the above principles to receive northbound RESTful API requests and construct simulation request responses to achieve device simulation at the protocol layer.

[0048] The following describes how, at the implementation level, this invention enables the engineering implementation of protocol-driven simulation services. For example... Figure 3 As shown, the main steps are as follows:

[0049] 1. Knowledge base for requesting integrated pipeline equipment models

[0050] The protocol-driven service primarily supports protocols such as SNMP (Simple Network Management Protocol), SSH, Telnet, and NetConf. The network management system needs to support hundreds of device models from manufacturers such as Huawei, ZTE, H3C, Cisco, and Alcatel-Lucent, as well as hundreds of indicators and activation commands for each device.

[0051] The request-response knowledge base is organized in a hierarchical directory structure, with configuration files organized by manufacturer => (hierarchical) device category (e.g., Huawei is the manufacturer, ME60 / NE40E, etc. are device categories). Each specific configuration file contains detailed request and response message structures. Since different models within the same device category may differ, regular expressions are used within the configuration files of the same device category to further match specific models. If no specific match is found, the general configuration is used.

[0052] Example configuration files are as follows:

[0053]

[0054]

[0055]

[0056]

[0057]

[0058] In the configuration file, `devices` is a regular expression used to match specific device models; each object in `request` represents a request-response pair, which includes the request protocol, parameters, and the content of the request-response pair; `delay` is used to simulate request latency, and is particularly suitable for load testing of large batches of requests.

[0059] The configuration file is loaded into the request-response knowledge base memory when the protocol-driven simulation service starts, and the configured request-response content is returned to the northbound Restful API when a northbound Restful API request arrives at the protocol-driven simulation service.

[0060] 2. Add devices and establish the mapping between IP addresses and device models.

[0061] When using the protocol-driven simulation service, it's necessary to "network" similarly to other simulators. This networking essentially involves establishing a mapping between device IP addresses and the configuration file from step 1. This mapping is stored in a Redis cache, where the key is the device IP address and the value is the device model. For example... Figure 4As shown, when a northbound RESTful API request arrives, the system retrieves the corresponding device model from Redis based on the device IP address in the request URL. Then, it retrieves the corresponding request and response information from the request and response knowledge base memory based on the device model. Finally, it finds the specific request and response content based on the parameters in the request and response information and returns it to the northbound RESTful API.

[0062] 3. Make normal business requests

[0063] After receiving the response from the protocol-driven simulation service, the upper-layer acquisition service processes the result and makes normal business requests.

[0064] It should be noted that although the operation of the method of the present invention has been described in a specific order in the above embodiments and figures, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0065] To provide a clearer explanation of the above-described method for simulating network devices in microservice-based network management, a specific embodiment will be used for illustration below. However, it is worth noting that this embodiment is only for better illustrating the present invention and does not constitute an improper limitation of the present invention.

[0066] Example:

[0067] When performing performance stress tests on the product, in order to simulate the performance indicators of managing tens of thousands of devices on site, 10 simulator service instances were run on the same physical server, while the network management service and middleware were deployed on multiple other servers according to specifications.

[0068] In Redis, a mapping between IP addresses and device models for 10,000 devices is pre-established using a script. The device models mainly use mainstream devices that are commonly used in the current network.

[0069] Then, the data collection task is started by importing data from 10,000 devices into the network management database using a script (to improve efficiency, the network management page is bypassed and data is directly inserted into the database).

[0070] Protocol-driven simulation services can accurately simulate device request-response and request latency, thereby accurately verifying potential problems of upper-layer acquisition services when managing large-scale devices. This helps products identify performance bottlenecks in a timely manner and improves product quality.

[0071] Based on the same inventive concept, this invention also proposes a network device simulation implementation apparatus for microservice-based network management. The implementation of this apparatus can refer to the implementation of the methods described above, and repeated details will not be repeated. The term "module" as used below can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0072] Figure 5 This is a schematic diagram of the network device simulation implementation device for microservice-based network management according to the present invention. Figure 5 As shown, the device includes: a protocol-driven simulation service module, which includes:

[0073] The knowledge base organization module 101 is used to organize the request and response knowledge base for managed device models. The request and response knowledge base is organized in a hierarchical directory format, and the configuration files are organized in the manner of manufacturer => device category. Each configuration file contains the specific request protocol, request parameters, request and response content, and request latency. In the configuration files of the same device category, the specific device model is matched using regular expressions. When the protocol-driven simulation service starts, the configuration files are loaded into the request and response knowledge base memory.

[0074] The mapping relationship establishment module 102 is used to add devices and establish a mapping relationship between device IP address and device model when the protocol-driven simulation service is used, and save it to Redis;

[0075] The request-response simulation module 103 is used to retrieve the corresponding device model in Redis based on the device IP address in the northbound Restful API request URL when the northbound Restful API request arrives at the protocol-driven simulation service. Then, it retrieves the corresponding request-response information in the request-response knowledge base memory based on the device model, finds the specific request-response content based on the parameters in the request-response information, and returns it to the northbound Restful API, thereby realizing the simulation of the device at the protocol layer.

[0076] It should be noted that although several modules for simulating network devices in microservice-based network management are mentioned in the detailed description above, this division is merely exemplary and not mandatory. In fact, according to embodiments of the present invention, the features and functions of two or more modules described above can be embodied in a single module. Conversely, the features and functions of a single module described above can be further divided and embodied by multiple modules.

[0077] Based on the aforementioned inventive concept, such as Figure 6As shown, the present invention also proposes a computer device 200, including a memory 210, a processor 220, and a computer program 230 stored in the memory 210 and executable on the processor 220. When the processor 220 executes the computer program 230, it implements the aforementioned network device simulation implementation method for microservice network management.

[0078] Based on the aforementioned inventive concept, the present invention also proposes a computer-readable storage medium storing a computer program that executes the aforementioned method for simulating network devices in microservice-based network management.

[0079] The network device simulation method and apparatus proposed in this invention for microservice-based network management fundamentally solves the problem of lacking real physical devices or dedicated simulators, thus making it impossible to test and verify device characteristics. The solution is simple and easy to implement, with high simulation accuracy of device manageability and zero impact on upper-layer services. It greatly reduces the cost for network management vendors to purchase testing equipment or simulator images. It facilitates the construction of a device information knowledge base for network management vendors, gradually accumulating knowledge, raising the entry threshold for network management, and forming a competitive advantage.

[0080] While the spirit and principles of the invention have been described with reference to several specific embodiments, it should be understood that the invention is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for ease of description. The invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

[0081] Regarding the limitation of the scope of protection of this invention, those skilled in the art should understand that various modifications or variations that can be made by those skilled in the art without creative effort based on the technical solution of this invention are still within the scope of protection of this invention.

Claims

1. A method for simulating network devices in microservice-based network management, characterized in that, The method includes: Organize the request and response knowledge base for managed device models, and load the configuration file into the request and response knowledge base memory when the protocol-driven simulation service starts; When using the protocol-driven simulation service, add devices and establish a mapping relationship between device IP addresses and device models, saving it to Redis; When a northbound RESTful API request reaches the protocol-driven simulation service, the corresponding device model is retrieved from Redis based on the device IP address in the northbound RESTful API request URL. Then, the corresponding request and response information is retrieved from the request and response knowledge base memory based on the device model. Finally, the specific request and response content is found based on the parameters in the request and response information and returned to the northbound RESTful API, thereby realizing the simulation of the device at the protocol layer.

2. The method for simulating network devices in microservice-based network management according to claim 1, characterized in that, The request-response knowledge base is organized in a hierarchical directory format, with configuration files organized in the manner of manufacturer => device category. Each configuration file contains the specific request protocol, request parameters, and request-response content. Within the configuration files of the same device category, the specific device model is matched using regular expressions.

3. The method for simulating network devices in microservice-based network management according to claim 2, characterized in that, The configuration file also includes the request latency.

4. A network device simulation implementation device for microservice-based network management, characterized in that, The device includes: a protocol-driven simulation service module, which includes: The knowledge base organization module is used to organize the request and response knowledge base of managed device models. When the protocol-driven simulation service starts, the configuration file is loaded into the request and response knowledge base memory. The mapping relationship establishment module is used to add devices and establish a mapping relationship between device IP address and device model when the protocol-driven simulation service is used, and save it to Redis; The request-response simulation module is used to retrieve the corresponding device model from Redis based on the device IP address in the northbound Restful API request URL when a northbound Restful API request arrives at the protocol-driven simulation service. Then, based on the device model, it retrieves the corresponding request-response information from the request-response knowledge base in memory. Finally, it finds the specific request-response content based on the parameters in the request-response information and returns it to the northbound Restful API, thereby simulating the device at the protocol layer.

5. The network device simulation implementation device for microservice-based network management according to claim 4, characterized in that, The request-response knowledge base is organized in a hierarchical directory format, with configuration files organized in the manner of manufacturer => device category. Each configuration file contains the specific request protocol, request parameters, and request-response content. Within the configuration files of the same device category, the specific device model is matched using regular expressions.

6. The network device simulation implementation device for microservice-based network management according to claim 5, characterized in that, The configuration file also includes the request latency.

7. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method according to any one of claims 1-3.

8. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the steps of the method according to any one of claims 1-3.

Images