Network equipment configuration method and device, electronic equipment and storage medium
By employing an automatic identification and multi-level verification method for network device configuration, this approach solves the configuration challenges of static adaptation technology in rapidly iterating and heterogeneous environments, achieving efficient and reliable automated configuration of network devices.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- JINAN INSPUR DATA TECH CO LTD
- Filing Date
- 2026-02-27
- Publication Date
- 2026-05-01
AI Technical Summary
Existing static adaptation technologies are difficult to adapt to the rapid iteration of network devices and the need for automated configuration in heterogeneous environments, resulting in long operation and maintenance times and high labor costs.
By automatically identifying network devices, obtaining device information, matching pre-stored information, generating candidate configuration commands, and performing multi-level verification, the device driver is finally generated and deployed, achieving fully automated configuration throughout the entire process.
It reduces maintenance time, decreases labor costs, and improves configuration efficiency and system compatibility.
Smart Images
Figure CN121967199A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of computer technology, and in particular to a network device configuration method, apparatus, electronic device, and storage medium. Background Technology
[0002] In existing technologies, modern bare-metal cloud platforms generally employ a static driver architecture to automate switch configuration. While this architecture can interface with devices from multiple vendors, its implementation has inherent limitations, relying on pre-written static adapter drivers manually tailored to specific models and firmware versions. However, bare-metal service delivery is heavily dependent on the configuration of the underlying access switches, and the existing network contains a large number of devices from different vendors, exhibiting significant heterogeneity in syntax, configuration mode hierarchy, and parameter formats. Furthermore, frequent firmware version iterations on switches cause existing drivers to become ineffective. When new devices are deployed or older devices are upgraded, maintenance personnel must manually analyze technical documentation and write or debug driver code, resulting in time-consuming and costly operations that hinder the delivery efficiency and reliability of cloud services. Therefore, existing static adapter technologies are ill-suited to the demands of rapid network device iteration and automated configuration in heterogeneous environments. Summary of the Invention
[0003] This application provides a network device configuration method, apparatus, electronic device, and storage medium to at least solve the technical problem that static adaptation technology is difficult to adapt to the rapid iteration of network devices and the need for automated configuration in heterogeneous environments.
[0004] This application provides a network device configuration method, which includes: in response to identifying a network device, obtaining the current device information of the network device, matching the current device information with pre-stored device information, determining whether there is a change in the device status of the network device, wherein the device status change includes the access of a new network device and the version upgrade of the network device, generating candidate configuration commands based on the current device information and port configuration requirements of the network device, performing multi-level verification on the candidate configuration commands, and in response to the candidate configuration commands passing the verification, generating a driver corresponding to the network device and deploying it.
[0005] This application also provides a network device configuration apparatus, which includes: The acquisition module is used to acquire the current device information of the network device in response to the identification of the network device.
[0006] The matching module is used to match the current device information with the pre-stored device information to determine whether there are any changes in the device status of the network device. These changes include the access of new network devices and the upgrade of network device versions.
[0007] The command generation module is used to generate candidate configuration commands based on the current device information and port configuration requirements of the network device in response to the access of a new network device or the version upgrade of a network device.
[0008] The verification module is used to perform multi-level verification on candidate configuration commands.
[0009] The deployment module is used to generate and deploy the corresponding driver for the network device in response to the successful verification of the candidate configuration command.
[0010] This application also provides an electronic device, which includes: Memory, used to store computer programs; A processor is used to perform the following steps when executing a computer program: In response to the identification of a network device, the current device information of the network device is obtained, and the current device information is matched with the pre-stored device information to determine whether there is a change in the device status of the network device. The device status change includes the access of a new network device and the upgrade of the network device version. In response to the access of a new network device or the upgrade of the network device version, candidate configuration commands are generated based on the current device information and port configuration requirements of the network device. The candidate configuration commands are verified at multiple levels. In response to the successful verification of the candidate configuration commands, the driver corresponding to the network device is generated and deployed.
[0011] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, performs the following steps: In response to the identification of a network device, the current device information of the network device is obtained, and the current device information is matched with the pre-stored device information to determine whether there is a change in the device status of the network device. The device status change includes the access of a new network device and the upgrade of the network device version. In response to the access of a new network device or the upgrade of the network device version, candidate configuration commands are generated based on the current device information and port configuration requirements of the network device. The candidate configuration commands are verified at multiple levels. In response to the successful verification of the candidate configuration commands, the driver corresponding to the network device is generated and deployed.
[0012] This application achieves awareness of status changes such as device access or version upgrades by automatically identifying network devices and obtaining their device information. It determines the type of network device compatibility status change by matching device information with pre-stored information, providing a clear decision-making basis for subsequent processing. Based on device status changes, device information, and port configuration requirements, it automatically generates candidate configuration commands to solve the adaptation problem of configuration differences between heterogeneous devices. Multi-level verification of candidate commands ensures the security and reliability of configuration operations. Finally, by generating and deploying device drivers, the verified configuration commands are transformed into sustainable device adaptation capabilities. This solution achieves full automation of network device configuration from status awareness, command generation, security verification to driver deployment, reducing the need for manual intervention and improving configuration efficiency and system compatibility.
[0013] Therefore, this method can solve the technical problem that static adaptation technology is difficult to adapt to the rapid iteration of network devices and the need for automated configuration in heterogeneous environments, and achieves the technical effect of reducing the time spent on operation and maintenance and reducing the high labor costs. Attached Figure Description
[0014] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0015] Figure 1 An application environment diagram for a network device configuration method provided in this application embodiment; Figure 2 A flowchart illustrating a network device configuration method provided in an embodiment of this application; Figure 3 A flowchart illustrating another network device configuration method provided in an embodiment of this application; Figure 4 This is a schematic diagram of the structure of a network device configuration apparatus provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.
[0017] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.
[0018] It should be noted that the terms "S1," "S2," etc., are used only for descriptive purposes and do not specifically refer to the order or sequence, nor are they intended to limit this application. They are merely for the convenience of describing the method of this application and should not be construed as indicating the sequential order of the steps. Furthermore, the technical solutions of the various embodiments can be combined with each other, but this must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or impossible to implement, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed in this application.
[0019] To address the technical challenge of static adaptation technology's inability to adapt to the rapid iteration of network devices and the need for automated configuration in heterogeneous environments, this application, upon identifying a network device, obtains the current device information of the network device, matches the current device information with pre-stored device information, and determines whether there is a change in the network device's state. These changes include the access of a new network device and version upgrades of existing network devices. Based on the current device information and port configuration requirements of the network device, candidate configuration commands are generated. These candidate configuration commands undergo multi-level verification. Upon successful verification of the candidate configuration commands, a driver corresponding to the network device is generated and deployed. This approach achieves the technical effect of reducing maintenance time and lowering labor costs.
[0020] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments. The network device configuration method provided in this application can be applied to, for example... Figure 1 , Figure 1 This diagram illustrates an application environment for a network device configuration method provided in this embodiment. Terminal 12 communicates with server 14 via a network. Terminal 12 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. Server 14 can be a standalone server or a server cluster consisting of multiple servers.
[0021] The embodiments of this application provide a network device configuration method, and the method is described in detail below in conjunction with the execution flow of the network device configuration method.
[0022] In one embodiment, such as Figure 2 As shown, Figure 2 This is a flowchart illustrating a network device configuration method provided in an embodiment of this application.
[0023] S101: In response to the identification of a network device, obtain the current device information of the network device.
[0024] In this embodiment, network device refers to the target configuration device that needs to be configured. Specifically, it can refer to any network infrastructure device that needs to be configured via command line, such as switches, routers, firewalls, and load balancers.
[0025] Current device information represents the device's unique identifier, consisting of digital information that can uniquely identify the device's model, version, type, and other characteristics. Specifically, it may include the device model, hardware serial number, operating system type, operating system version, firmware version, etc. This current device information can form the device's fingerprint for subsequent device information matching and decision-making.
[0026] In this embodiment, a device discovery mechanism is used to detect target configuration devices. Specifically, in response to the identification of a network device, the system uses triggering mechanisms such as network scanning, device online notification, and periodic polling to detect a new network device or an existing network device entering the management domain, and automatically collects the device's characteristic identification information. This achieves automated detection and information collection of network devices, replacing manual data entry and providing data input for subsequent automated processes.
[0027] S102: Match the current device information with the pre-stored device information to determine if there are any changes in the device status of the network device, including new network device access and network device version upgrades.
[0028] In this embodiment, the pre-stored device information refers to the registered device feature library. This refers to the collection of feature identification information for all known and supported network devices pre-stored in the system; this collection can be a database or knowledge base. The collection of feature identification information serves as the benchmark for determining whether a currently accessing network device is a new or old device.
[0029] A device status change refers to a change in the compatibility status of a network device. Specifically, it refers to two situations requiring different system adaptation strategies: the introduction of new network devices and version upgrades of existing network devices.
[0030] In this context, "new network device access" refers to the detection of a network device whose identifier, such as its model number or version, is completely absent from the registered device identifier database. The system is entirely unfamiliar with this network device and needs to adapt it from scratch.
[0031] Network device version upgrade refers to a situation where a network device model is detected in the database, but its version information, such as the operating system (OS) version, does not match the version information recorded in the database. The system is partially aware of this, but version iteration may cause the original configuration commands to become invalid, requiring readjustment or adaptation.
[0032] In this embodiment, the collected device feature identifiers are compared with a registered device feature database to determine whether the network device has a change in compatibility status, that is, whether there is a brand new network device or a version upgrade of an existing network device. This step enables intelligent identification and classification of changes in network device compatibility status, clarifying whether the subsequent process needs to solve the problem of generating configuration commands from scratch or updating existing configuration commands, making the automated processing more targeted and directional, and reducing the consumption of computing resources.
[0033] S103: In response to the access of a new network device or the upgrade of a network device version, generate candidate configuration commands based on the device information and port configuration requirements of the network device.
[0034] In this embodiment, port configuration requirements refer to a description of the network device configuration intent. Specifically, it represents the desired configuration state of the network device, expressed in the form of natural language, structured data, or API (Application Programming Interface) call parameters, such as "add port X to VLAN Y".
[0035] Candidate configuration commands represent a collection of alternative configuration instructions. They are one or more potentially correct and specific device command-line instructions generated by the system to address the configuration intent description of network devices and based on the device characteristics of the network devices. These instructions have not yet been verified, hence they are called candidate configuration commands.
[0036] Specifically, when a change in the compatibility status of a network device is detected, a set of alternative configuration instructions for that network device model and version is automatically derived based on the device's characteristic identifiers and configuration intent descriptions. Specifically, automated methods, such as large language models, can be used to translate business intents into device-related technical instructions, resolving the issue of differences in configuration syntax between heterogeneous devices and replacing the traditional process of manually consulting documents and writing commands.
[0037] S104: Perform multi-level verification on candidate configuration commands.
[0038] In this embodiment, multi-level verification refers to a verification process that performs layered security verification on candidate configuration commands. This verification process does not simply execute commands, but uses a multi-layered filtering verification mechanism to ensure the absolute security and effectiveness of commands.
[0039] Specifically, verification mechanisms can typically include syntactic or logical verification, such as LLM (Large Language Model) self-confidence assessment, sandbox environment simulation verification, and result conformity verification.
[0040] In this embodiment, a layered security verification process is used to simulate the execution of candidate configuration command sets and verify the compliance of the results in an isolated environment, thereby selecting commands that are safe and can effectively configure network devices. Ensuring the security of the automation process is crucial for the application of this technical solution in a production environment. By identifying erroneous configuration commands before actual deployment, network outages or other security risks caused by configuration errors can be avoided.
[0041] S105: In response to the successful verification of the candidate configuration command, generate the driver corresponding to the network device and deploy it.
[0042] In this embodiment, the driver refers to the network device adapter code, specifically a piece of program code that encapsulates verified and correct configuration instructions for the specific network device model and version. It provides a standard configuration interface to the outside world and contains a specific CLI (Command Line Interface) command sequence to implement the function, which can encapsulate the differences between heterogeneous devices to provide a unified service.
[0043] Deployment refers to integration and release, which means integrating newly generated or updated device adapter code into an existing device management platform, such as a specific module of a cloud platform. Deployment makes the code effective and available for business calls.
[0044] In this embodiment, the verified configuration instructions are encapsulated into device adapter code and integrated and published to the device management platform to make it effective. This step not only solves the configuration problem of the current network device, but also expands the capabilities of the management platform by generating reusable driver code. This allows the management platform to avoid executing the aforementioned complete process again when encountering similar devices, thereby increasing automation capabilities.
[0045] In this embodiment, by automatically identifying network devices and obtaining their device information, the system can perceive changes in device status such as access or version upgrades. By matching device information with pre-stored information, the system determines the type of network device compatibility status change, providing a clear decision-making basis for subsequent processing. Based on device status changes, device information, and port configuration requirements, candidate configuration commands are automatically generated to address the adaptation problem of configuration differences between heterogeneous devices. Multi-level verification of candidate commands ensures the security and reliability of configuration operations. Finally, by generating and deploying device drivers, the verified configuration commands are transformed into sustainable device adaptation capabilities. This solution achieves full automation of network device configuration from status awareness, command generation, security verification to driver deployment, reducing the need for manual intervention and improving configuration efficiency and system compatibility.
[0046] In one embodiment, such as Figure 3 As shown, Figure 3 This is a flowchart illustrating another network device configuration method provided in an embodiment of this application. In this embodiment, network device configuration is completed through four stages: device awareness, configuration command generation, verification, and code self-healing.
[0047] In one specific embodiment, the device information includes at least the device model and operating system version. After determining whether there is a change in the device status of the network device, the process includes: If the device model and / or operating system version are not found in the pre-stored device information, the device status is determined to be a new network device access; if the device model and operating system version are found in the pre-stored device information, it is determined whether the operating system version matches the operating system version in the pre-stored device information; if the operating system version matches the operating system version in the pre-stored device information, the device status is determined to be a network device version upgrade.
[0048] Specifically, the system interacts with network devices through Simple Network Management Protocol, command-line interface, or Network Configuration Protocol, collecting device information database object information such as system description and physical serial number of the network device, as well as its operating configuration, and instantiating a network device fingerprint class to construct the unique identifier of the network device. The pre-built device information database already stores device records of known network devices generated by this unique identifier method. This unique identifier represents the device information of the network device, i.e., fingerprint information. This fingerprint information specifically includes the device model and operating system version, for example, {Device fingerprint: "AAA9000|7.0(3)I7(1)|ABC123", ...}, where AAA 9000 represents the device model and :7.0(3)I7(1) represents the operating system version. When the system identifies a newly connected network device, it obtains its current unique identifier, assuming it is "AAA|4.21.0F|XYZ789", and matches it with all device fingerprints in the pre-stored information database. If the fingerprint string is not found in the database, it immediately determines that the device status has changed to a new network device access. Conversely, if the system identifies a network device and obtains its fingerprint as "BBB9000|9.0(1)|DEF456", and finds that there is a fingerprint record of the same model BBB9000 in the pre-stored information database, but its complete fingerprint "BBB9000|7.0(3)I7(1)|ABC123" does not match the currently obtained fingerprint in the operating system version field, then it is determined that the device status change is a version upgrade of the network device.
[0049] Furthermore, when the system identifies a newly connected network device and obtains its device information as {Device Model: DDD DCS-7050, Operating System Version: 4.21.0F}, it matches the device information with the pre-stored information database. If it finds that the model DDD DCS-7050 does not exist in the database, it immediately determines that the device status change is a new network device access, meaning that the currently connected device is not a new network device that has not been connected before.
[0050] Conversely, if the system identifies the network device as {device model: CCC CE6850, operating system version: 9.0(1)}, and finds that the model exists in the pre-stored information database, but the record of the corresponding model in the database is version 7.0(3)I7(1), which does not match the currently obtained version 9.0(1), then it is determined that the device status change is a version upgrade of the network device.
[0051] In this embodiment, by matching the collected device model and operating system version with the pre-stored device information database, the system can identify two types of status changes: new device access and existing device version upgrade. This improves the system's awareness of network device status changes and enhances processing efficiency.
[0052] In one specific embodiment, the network device's current device information and port configuration requirements are used to generate candidate configuration commands, which include: In response to a device status change to a new network device access, the device information of the current network device is input into a preset language model; the preset language model is used to obtain the port configuration requirements that match the current network device; the port configuration requirements are parsed to generate candidate configuration commands for the current network device.
[0053] Specifically, the system has already determined through the previous embodiment that the current device is a completely new device model or combination of models and versions that the system has never supported before. When the system determines that the network device is a new network device, it automatically triggers the candidate command generation process. The system sends the device information of the new device, i.e., the device fingerprint, such as AAA DCS-7050|4.21.0F|XYZ789, to the preset language model, and sends a standardized port configuration requirement, such as configuring port Ethernet1 / 1 / 1 as Access mode and assigning it to VLAN 200.
[0054] Upon receiving input, the pre-defined language model identifies the network device, determining its manufacturer, model, and version based on its device fingerprint. Further, the model retrieves the most relevant configuration document fragments for that device model and version from its internal knowledge base or associated external vector database, such as the VLAN (Virtual Local Area Network) and interface configuration sections in the "AAADCS-7050 Configuration Guide." Based on the acquired configuration document information, it understands the natural language intent in port configuration requirements, such as configuring ports, entry modes, and specifying VLANs. Next, it performs command generation and reasoning. This includes crawling the manufacturer's switch user documentation based on the device model's webpage, segmenting and embedding all technical documents for the switch model, such as CLI guides, configuration manuals, and release notes, and storing them in the vector database. Based on the parsed configuration intent, it retrieves the most relevant document fragments from the vector database, using only these highly relevant fragments as context. The pre-defined language model parses these fragments and merges them into compliant CLI commands. Simultaneously, the pre-defined language model assigns a confidence score to the generated command, indicating its confidence in the command's correctness. The default language model ultimately outputs a structured result, which typically contains one or more candidate command sequences as subsequent candidate configuration commands.
[0055] In this embodiment, a language model is used to automatically convert device-independent configuration intents into specific device-related configuration commands. By crawling technical data, the traditional mode of relying on manually consulting technical documents and writing driver code is transformed into an automated process, shortening the command generation time.
[0056] In one specific embodiment, generating candidate configuration commands based on the current device information and port configuration requirements of the network device further includes: In response to a device status change to a network device version upgrade, the device information of the current network device is input into a preset language model; the preset language model is used to obtain the port configuration requirements matching the current network device; based on the device information of the current network device, the configuration command before the version upgrade of the current network device is obtained; based on the port configuration requirements matching the current network device, the configuration command after the version upgrade of the current network device is obtained; the configuration command before the version upgrade and the configuration command after the version upgrade are matched, and if they are different, the configuration command before the version upgrade is changed to the configuration command after the version upgrade, generating candidate configuration commands for the current network device.
[0057] Specifically, the configuration commands prior to the version upgrade refer to the pre-stored command-line instructions in the system that have been successfully verified on older operating systems for the device and are used to achieve specific port configuration requirements. These commands are usually stored in the device's driver code or configuration template library.
[0058] The configuration commands after the version upgrade refer to the specific command-line instructions generated by the preset language model based on the upgraded operating system version and the same port configuration requirements, conforming to the new version's syntax. These are theoretically correct commands inferred by the model from the documentation knowledge of the new version.
[0059] Matching refers to the analysis process by which the system compares the configuration commands before and after the version upgrade. This matching is not a simple string equality comparison, but a semantic and functional comparison, aiming to determine whether the two are equivalent commands in different versions that achieve the same functional intent.
[0060] A change refers to the operation performed when the system determines through matching analysis that the old and new commands are inconsistent, and confirms that the new command is correct. This means replacing or overwriting the configuration commands stored in the system before the version upgrade with the upgraded configuration commands to update the driver code.
[0061] Specifically, when the system determines that a device has undergone a version upgrade, it retrieves the old configuration commands. Based on the device model and port configuration requirements, it searches the existing device driver library or configuration template for a sequence of configuration commands that were stable on the old version of the operating system for that device—the configuration commands before the version upgrade. Simultaneously, the system inputs the new device information, including the new version number and the same port configuration requirements, into a preset language model. The language model then generates a new sequence of configuration commands that conforms to the new version's syntax, based on the new version's technical documentation—the configuration commands after the version upgrade.
[0062] The system further matches the old and new configuration commands. For example, the old configuration command is `switchportmode access`, and the new configuration command is `port link-type access`. Both semantically mean "set the port mode to access mode," and the system understands that these two different commands are functionally equivalent and consistent. If a match is found, it means that the configuration command has not changed between the old and new versions and does not need to be updated. The system may directly use the old command or consider the new command as a candidate configuration command.
[0063] If the match is inconsistent, it indicates that the version upgrade has caused a shift in command syntax or semantics. The system then determines that the old command is outdated, replaces it with a new command generated by the language model, and outputs it as a candidate configuration command for subsequent multi-level verification.
[0064] Traditionally, after a device upgrade, manual troubleshooting is usually only undertaken after configuration failures occur. In this embodiment, an adaptation process is proactively initiated upon device upgrade detection. Through semantic matching and comparison, commands that are truly invalidated due to the version upgrade are identified, avoiding blindly updating all commands and improving the accuracy and efficiency of adaptation. This achieves automated adaptation to configuration command changes caused by network device operating system version iterations, reducing maintenance interruptions and manual intervention due to version upgrades.
[0065] In one specific embodiment, in response to a device state change to a network device version upgrade, a first set of technical documents corresponding to the current operating system version of the network device and a second set of technical documents corresponding to the old operating system version stored in pre-stored device information are obtained. Based on the current device information and port configuration requirements, a difference analysis is performed on the first and second technical document sets to generate a version upgrade difference report. Specifically, this includes extracting configuration guide chapters related to port configuration requirements from the first and second technical document sets, comparing the extracted configuration guide chapters, identifying the addition, obsolescence, or modification information of command line statements, organizing the identified change information according to a preset structured format, and generating a version upgrade difference report. The difference report includes command line interface syntax change information related to port configuration between the old operating system version and the current operating system version. The version upgrade difference report, port configuration requirements, and current device information are input into a preset language model. Using the preset language model, based on the syntax changes indicated in the version upgrade difference report, the port configuration requirements are parsed to generate candidate configuration commands for the current network device.
[0066] In this embodiment, by analyzing the differences in technical documents before and after the version upgrade and generating a structured report, the command generation process of the language model can focus on specific grammatical changes, reduce the computational complexity of the model, and improve the accuracy and efficiency of command generation.
[0067] In one specific embodiment, the candidate configuration command carries a confidence score, and after generating the candidate configuration command for the current network device, it includes: Candidate configuration commands are sorted according to a preset sorting order based on their confidence scores to form a command sort. The confidence scores of the candidate configuration commands are then verified sequentially according to the command sort. If the confidence score is greater than or equal to a first preset score, the candidate configuration command is determined to be a port configuration command. A driver corresponding to the network device is generated based on the port configuration command and deployed. If the confidence score is less than the first preset score but greater than or equal to a second preset score, multi-level verification of the candidate configuration command is performed. If the confidence score is less than a third preset score, a manual review request for the candidate configuration command is generated. The network device is configured using the candidate configuration command based on the input instructions in response to the review request. If the network device is successfully configured using the candidate configuration command, the candidate configuration command is determined to be a port configuration command. A driver corresponding to the network device is generated based on the port configuration command and deployed.
[0068] The confidence score represents a probability value or rating generated by a pre-defined language model, used to quantify the model's confidence in the correctness and reliability of its generated candidate configuration commands. A higher score indicates that the model is more confident that the command conforms to the network device's configuration specifications in terms of syntax, semantics, and context.
[0069] Command sorting refers to the list generated by the system prioritizing a set of candidate configuration commands based on their confidence scores (e.g., from high to low). This sorting determines the order in which these commands are verified or processed in subsequent processes.
[0070] Port configuration commands represent configuration commands that are ultimately deemed secure, valid, and executable by the system. They represent the final state of candidate configuration commands that have passed verification and serve as the direct basis for generating device drivers and for deployment.
[0071] The first preset score represents a high confidence threshold. It defines the boundary for high-confidence commands. When a command's score reaches or exceeds this score, the system can skip the time-consuming verification process and directly determine it as valid.
[0072] The second preset score represents the medium confidence threshold. Together with the first preset score, it defines a medium confidence interval. Commands falling within this interval have some uncertainty regarding their correctness and must undergo rigorous multi-level verification before being adopted.
[0073] The third preset score represents a lower confidence threshold, used to define low-confidence commands. Commands with scores below this value are considered highly likely to be erroneous and can be directly handled manually without wasting verification resources. The first preset score is greater than the second preset score, and the second preset score is greater than the third preset score.
[0074] An audit request is an automatically generated work order or notification that requires manual intervention. It includes the problematic candidate configuration command, device context information, and the model's confidence score, aiming to request human judgment and handling.
[0075] Specifically, after generating candidate configuration commands using a preset language model, the system sorts each command in descending order based on its confidence score. The processing engine starts processing the command with the highest score in the list. The system obtains the score of the current command and compares it with a first preset score, for example, 0.95. If the confidence score is greater than or equal to 0.95, the system determines that the command has high reliability. Therefore, the verification step can be skipped, and the command can be directly used as a valid port configuration command, entering the driver generation and deployment process.
[0076] If the confidence score is less than the first preset score but greater than or equal to the second preset score (e.g., the second preset score is 0.75), the system determines that the command may be correct but requires further verification. The command will then be sent to a multi-level verification process. If verification passes, it will be converted into a port configuration command and deployed; if verification fails, the next command's score will be evaluated according to its order, and this process will be repeated.
[0077] If the current command score is less than the third preset score, for example, 0.4, the system model cannot be certain of the correctness of the candidate configuration command, as the verification risk and cost are too high. Therefore, an audit request is generated and sent to a human for processing. If the human confirms the command is valid, the system receives the instruction, uses the command as a port configuration command, and continues to complete driver generation and deployment. If the human finds an error in the command, they can provide modification suggestions or manually enter the correct command, and the system will then treat it as a valid command for further processing.
[0078] In this embodiment, a lenient verification mechanism is implemented for high-confidence commands to improve the execution efficiency of configuration tasks; a multi-level verification process is used for medium-confidence commands to ensure their reliability; and low-confidence commands trigger manual review to control risks and provide a safety net for the process. This confidence-based hierarchical processing strategy can improve configuration efficiency and security during configuration management, further enhance operational reliability, and reduce labor costs.
[0079] In one specific embodiment, multi-level verification of candidate configuration commands includes: Upon receiving a candidate configuration command, the system executes the command in a preset sandbox environment, which simulates the network device's operating environment. It then acquires the network device's configuration status after executing the candidate configuration command and compares it with the preset configuration result. If the configuration status matches the preset configuration result, the candidate configuration command is considered successfully executed, and the system checks whether the command has actually been executed. If the command has been executed, the candidate configuration command is considered verified and used as a port configuration command. If the configuration status does not match the preset configuration result or the command has not been executed, the candidate configuration command is considered to have failed, and its verification is deemed unsuccessful. If the command fails verification, the system continues to verify the next candidate configuration command according to the order.
[0080] The preset sandbox environment represents a simulated network device testing environment. Typically, a target network device, such as a mirror or simulation of a specific model and version of a switch, is deployed using containerization or virtualization technologies to prevent erroneous commands from affecting the real network through testing.
[0081] The configuration status represents the actual configuration data that takes effect on the simulated network device after executing a candidate configuration command in a preset sandbox environment. For example, after executing a VLAN switching command, the result obtained by executing a query command represents the current configuration status.
[0082] The default configuration result indicates the correct device configuration state that the system expects to achieve based on the port configuration requirements. For example, if the configuration requirement is "add port 1 to VLAN 200", then the default configuration result is "the VLAN membership of port 1 is 200".
[0083] A theoretically successful execution means that the candidate configuration command was accepted and executed by the simulated device in the sandbox environment without generating any direct error messages. However, this only indicates that the configuration command may be syntactically correct, but it does not prove that it actually achieved the expected effect.
[0084] The actual execution is used for deeper checks, indicating that the system confirms that the command was indeed processed by the device and the configuration was persistently changed. This is because some commands may be syntactically correct but fail to meet execution conditions, such as configuring a non-existent port, causing them to be ignored or rolled back by the device even though no error is reported.
[0085] Specifically, the system sends the sorted candidate configuration commands to a preset sandbox environment, where they are executed by the switch simulator, and the simulator's output is obtained. If the command returns an error message after execution, it is considered a failure, and the verification terminates. If the command does not report an error, meaning it theoretically executed successfully, the current configuration status of the simulated device is obtained by querying the command. This configuration status is then compared with the preset configuration result. If they match, it indicates that the command syntax is correct and the expected configuration goal has been achieved, and the process proceeds to the second stage. If they do not match, it indicates that the command syntax is correct but the semantics or logic is incorrect, and the verification fails. Candidate configuration commands that pass the first stage of verification will undergo a next stage check, confirming that the command has actually been executed and changed the running configuration. Specifically, the device's running configuration or change history is queried again to confirm that the previously sent candidate configuration command has indeed been persistently written to it, ensuring the reliability of the verification result. Only candidate configuration commands that pass both stages of verification are ultimately deemed to have passed verification and are identified as port configuration commands. Conversely, if any stage fails, the candidate command is deemed to have failed verification. The system will automatically retrieve the next candidate configuration command from the command sorting list and repeat the entire multi-level verification process until a successful command is found or all commands fail. It should be noted that once a successful command is found, the next and subsequent configuration commands will no longer be verified.
[0086] In this embodiment, a pre-set sandbox environment isolates testing and verification operations from the production network, avoiding the risk of network failures caused by incorrect test commands. This multi-level verification process not only checks whether the command is received but also verifies the semantic correctness of the command through result comparison, improving the accuracy of verification. The second-stage check ensures that the command is not only temporarily effective but also truly accepted and solidified by the device, avoiding situations where commands are found to be ineffective only after deployment, thus guaranteeing the determinism and reliability of the process.
[0087] In one specific embodiment, generating and deploying the driver corresponding to the network device includes: Based on the verified port configuration commands and network device information, generate network device driver code; store the network device driver code in the target repository according to the preset directory structure, and update the driver registration configuration file in the target repository to register the driver corresponding to the network device; the target repository is used to manage the network device driver code; transfer the network device driver code to a remote repository to trigger the continuous integration and continuous deployment process to deploy the driver corresponding to the network device.
[0088] The network device driver code encapsulates verified port configuration commands for a specific network device. It acts as a device adapter, providing a unified, abstract configuration interface to the outside world, while internally containing the specific CLI command sequence to implement the functionality. Its role is to encapsulate the differences between heterogeneous devices and provide standardized, programmable configuration services to the upper-layer management platform.
[0089] The target repository refers to the local or internal code repository in the version control system, which is used to store and version-manage the driver code of all network devices and maintain a list of all registered devices.
[0090] The driver registration configuration file represents a specific file stored in the target repository. It acts as a registry for device driver capabilities, recording the mapping between all supported device fingerprints and their corresponding driver code file paths. When the management platform needs to configure a device, it first queries this file to locate and load the correct driver.
[0091] A remote repository refers to an upstream or central repository of the target repository, typically serving as the trigger source for a Continuous Integration / Continuous Deployment (CI / CD) system. When code is pushed to this repository, CI / CD is automatically notified to begin its work. The Continuous Integration and Continuous Deployment process is an automated software build, testing, and release process. Once triggered, this process compiles, runs integration tests, packages the code, and deploys new or updated device drivers to the cloud platform management module in the production environment, making them effective.
[0092] Specifically, the system takes the verified port configuration command and device information as input, generates network device driver code files through code templates, saves the generated driver code files to the local target repository according to the preset directory structure, and pushes the new driver code files and updated registry from the target repository to the remote repository through Git (distributed version control system) operations to pull the code to run automated tests, and deploys it to the production environment management platform by building software packages.
[0093] In this embodiment, a device driver management system is constructed through a target repository and driver registration configuration files, which enhances the maintainability and scalability of the platform, enables automated deployment, and improves the efficiency of subsequent operation and maintenance.
[0094] In one embodiment, such as Figure 4 As shown, Figure 4 This is a schematic diagram of a network device configuration apparatus provided in an embodiment of this application. The network device configuration apparatus may include an acquisition module 21, a matching module 22, a command generation module 23, a verification module 24, and a deployment module 25.
[0095] The acquisition module 21 is used to acquire the current device information of the network device in response to the identification of the network device; Matching module 22 is used to match the current device information with the pre-stored device information to determine whether there is a change in the device status of the network device, including the access of a new network device and the upgrade of the network device version; Command generation module 23 is used to generate candidate configuration commands based on the current device information and port configuration requirements of the network device in response to the access of a new network device or the version upgrade of the network device. Verification module 24 is used to perform multi-level verification of candidate configuration commands; Deployment module 25 is used to generate and deploy the driver corresponding to the network device in response to the successful verification of the candidate configuration command.
[0096] Each module in the aforementioned network device configuration apparatus can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of the electronic device in hardware form or independent of it, or stored in the memory of the electronic device in software form, so that the processor can call and execute the operations corresponding to each module.
[0097] Embodiments of this application also provide an electronic device, including a memory for storing computer programs; A processor, when executing a computer program, can perform at least the following steps: In response to the identification of a network device, the current device information of the network device is obtained, and the current device information is matched with the pre-stored device information to determine whether there is a change in the device status of the network device. The device status change includes the access of a new network device and the upgrade of the network device version. In response to the access of a new network device or the upgrade of the network device version, candidate configuration commands are generated based on the current device information and port configuration requirements of the network device. The candidate configuration commands are verified at multiple levels. In response to the successful verification of the candidate configuration commands, the driver corresponding to the network device is generated and deployed.
[0098] In one embodiment, the electronic device may be a server, and its internal structure diagram may be as follows: Figure 5 As shown, this electronic device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores software management data. The network interface is used for communication with external terminals via a network connection.
[0099] Those skilled in the art will understand that Figure 5 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the electronic device to which the present application is applied. The specific electronic device may include more or fewer components than shown in the figure, or combine certain components, or have different component arrangements.
[0100] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, can perform at least the following steps: In response to the identification of a network device, the current device information of the network device is obtained, and the current device information is matched with the pre-stored device information to determine whether there is a change in the device status of the network device. The device status change includes the access of a new network device and the upgrade of the network device version. In response to the access of a new network device or the upgrade of the network device version, candidate configuration commands are generated based on the current device information and port configuration requirements of the network device. The candidate configuration commands are verified at multiple levels. In response to the successful verification of the candidate configuration commands, the driver corresponding to the network device is generated and deployed.
[0101] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.
[0102] Embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, can perform at least the following steps: In response to the identification of a network device, the current device information of the network device is obtained, and the current device information is matched with the pre-stored device information to determine whether there is a change in the device status of the network device. The device status change includes the access of a new network device and the upgrade of the network device version. In response to the access of a new network device or the upgrade of the network device version, candidate configuration commands are generated based on the current device information and port configuration requirements of the network device. The candidate configuration commands are verified at multiple levels. In response to the successful verification of the candidate configuration commands, the driver corresponding to the network device is generated and deployed.
[0103] 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 computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.
[0104] It will also be appreciated that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0105] The foregoing has provided a detailed description of a network device configuration method, system, device, and computer-readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of this application.
Claims
1. A network device configuration method, characterized in that, The network device configuration method includes: In response to the identification of a network device, the current device information of the network device is obtained; The current device information is matched with the pre-stored device information to determine whether there is a change in the device status of the network device, wherein the device status change includes the access of a new network device and the upgrade of the network device version; In response to the access of the new network device or the version upgrade of the network device, a candidate configuration command is generated based on the current device information and port configuration requirements of the network device. Perform multi-level verification on the candidate configuration commands; Upon successful verification of the candidate configuration command, a driver corresponding to the network device is generated and deployed.
2. The network device configuration method according to claim 1, characterized in that, The device information includes at least the device model and operating system version, and the determination of whether there is a change in the device status of the network device includes: If the device model and / or the operating system version are not found in the pre-stored device information, the device status is determined to be changed to new network device access. In response to the presence of the device model and the operating system version in the pre-stored device information, it is determined whether the operating system version matches the operating system version in the pre-stored device information; If the operating system version matches the operating system version in the pre-stored device information, then the device status is determined to be a version upgrade of the network device.
3. The network device configuration method according to claim 2, characterized in that, The process of generating candidate configuration commands based on the current device information and port configuration requirements of the network device includes: In response to the device status change to the new network device access, the device information of the current network device is input into the preset language model; The port configuration requirements matching the current network device are obtained using the preset language model; The port configuration requirements are parsed to generate candidate configuration commands for the current network device.
4. The network device configuration method according to claim 2, characterized in that, The method for generating candidate configuration commands based on the current device information and port configuration requirements of the network device also includes: In response to the device status change to a network device version upgrade, the device information of the current network device is input into a preset language model; The port configuration requirements matching the current network device are obtained using the preset language model; Based on the device information of the current network device, obtain the configuration command of the current network device before the version upgrade; Based on the port configuration requirements that match the current network device, obtain the configuration command after the version upgrade of the current network device; The configuration command before the version upgrade is matched with the configuration command after the version upgrade. If the two are different, the configuration command before the version upgrade is changed to the configuration command after the version upgrade, and candidate configuration commands for the current network device are generated.
5. The network device configuration method according to claim 3 or 4, characterized in that, The candidate configuration command carries a confidence score, and the process of generating the candidate configuration command for the current network device includes: The candidate configuration commands are sorted according to the confidence scores and a preset sorting order to form a command sort; The confidence scores of the candidate configuration commands are verified sequentially according to the command order. In response to the confidence score being greater than or equal to a first preset score, the candidate configuration command is determined to be a port configuration command, and a driver corresponding to the network device is generated based on the port configuration command and the driver is deployed. In response to the confidence score being less than a first preset score and greater than or equal to a second preset score, it is determined that the candidate configuration command will undergo multi-level verification. In response to the confidence score being less than a third preset score, a review request for manual review of the candidate configuration command is generated. Based on the input instruction in response to the review request, the network device is configured using the candidate configuration command. In response to the successful configuration of the network device using the candidate, the candidate configuration command is determined to be a port configuration command. Based on the port configuration command, a driver corresponding to the network device is generated and the driver is deployed. The first preset score is greater than the second preset score, and the second preset score is greater than the third preset score.
6. The network device configuration method according to claim 1, characterized in that, The multi-level verification of the candidate configuration commands includes: In response to receiving the candidate configuration command, the candidate configuration command is executed in a preset sandbox environment; wherein the preset sandbox environment simulates the operating environment of the network device; Obtain the configuration status of the network device after executing the candidate configuration command, and compare the configuration status with the preset configuration result; In response to the matching of the configuration status with the preset configuration result, it is determined that the candidate configuration command was successfully executed, and it is detected whether the candidate configuration command was actually executed. If the candidate configuration command has been actually executed, it is determined that the candidate configuration command has passed the verification and is used as the port configuration command. If the configuration status does not match the preset configuration result or the candidate configuration command is not actually executed, it is determined that the candidate configuration command execution failed, or the candidate configuration command verification failed. If the candidate configuration command fails verification, the next candidate configuration command will be verified according to the order.
7. The network device configuration method according to claim 1, characterized in that, The step of generating and deploying the driver corresponding to the network device includes: Based on the verified port configuration command and the network device information, generate network device driver code; The network device driver code is stored in a target repository according to a preset directory structure, and the driver registration configuration file in the target repository is updated to register the driver corresponding to the network device; wherein, the target repository is used to manage the network device driver code; The network device driver code is transferred to a remote repository to trigger a continuous integration and continuous deployment process to deploy the driver corresponding to the network device.
8. A network device configuration apparatus, characterized in that, include: The acquisition module is used to acquire the current device information of the network device in response to the identification of the network device; The matching module is used to match the current device information with the pre-stored device information to determine whether there is a change in the device status of the network device, wherein the device status change includes the access of a new network device and the upgrade of the network device version; The command generation module is used to generate candidate configuration commands based on the current device information and port configuration requirements of the network device in response to the access of the new network device or the version upgrade of the network device. The verification module is used to perform multi-level verification on the candidate configuration commands; The deployment module is used to generate and deploy the driver corresponding to the network device in response to the successful verification of the candidate configuration command.
9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to implement the steps of the network device configuration method as described in any one of claims 1 to 7 when executing the computer program.
10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the network device configuration method as described in any one of claims 1 to 7.