Zero-touch onboarding and automated device configuration method

Abstract

This application relates to a zero-contact deployment and automated device configuration method, including obtaining the address information of an intelligent boot server and establishing a connection with the intelligent boot server based on the address information; sending identity credential information to the cloud control plane through the intelligent boot server, so that the cloud control plane can perform secure authentication of the identity credential information. If the authentication is successful, a corresponding short-term access token is generated and returned; based on the short-term access token, the device identity and environment information are reported to the policy service of the cloud control plane, so that the policy service generates and returns the corresponding final configuration policy; the final configuration policy is loaded into the runtime configuration, and a self-check process is executed to generate and report the corresponding self-check results to the cloud control plane. This method shortens the device deployment cycle and reduces the probability of human error, enabling the acquisition of matching configurations in different network environments, thereby improving the overall efficiency, reliability, and manageability of large-scale distributed network deployment.

Description

Technical Field

[0001] This invention relates to the technical field of equipment configuration, and more particularly to a zero-contact start-up and automated equipment configuration method. Background Technology

[0002] Currently, in the initial deployment of network devices in distributed sites, existing technologies typically employ pre-configured images or simplified ZTP solutions relying on vendor-specific protocols. While pre-configured images can reduce on-site operations to some extent, their configurations are fixed before shipment, making them difficult to adapt to changes in the on-site network environment. Furthermore, managing the binding relationship between devices and sites is complex, and there is a security risk of sensitive configuration leakage. Simplified ZTP solutions relying on vendor-specific protocols achieve a degree of automation, but are usually limited by a single vendor's ecosystem, making it difficult to support heterogeneous devices. Their functionality is also relatively basic, lacking robust authentication mechanisms and dynamic policy generation capabilities based on environment information. They also have high requirements for network connectivity and insufficient reliability in complex network environments. Therefore, existing technologies generally suffer from insufficient flexibility and scalability, as well as low security, making it difficult to meet the needs of rapid, secure, and intelligent deployment of network devices in large-scale distributed scenarios. Summary of the Invention

[0003] To address the issues of insufficient flexibility, scalability, and low security caused by existing technologies that employ pre-configured images or simple ZTP solutions that rely on vendor-specific protocols, this application provides a zero-contact start-up and automated equipment configuration method.

[0004] A zero-contact start-up and automated equipment configuration method, the method comprising: Obtain the address information of the intelligent boot server, and establish a connection with the intelligent boot server based on the address information; The intelligent guidance server sends identity credential information to the cloud control plane so that the cloud control plane can perform security authentication on the identity credential information. If the authentication is successful, a corresponding short-term access token is generated and returned. Based on the short-term access token, the device identity and environment information are reported to the policy service of the cloud control plane, so that the policy service generates and returns the corresponding final configuration policy; The final configuration strategy is loaded into the runtime configuration, and a self-test process is executed to generate and report the corresponding self-test results to the cloud control plane.

[0005] By adopting the above technical solutions, devices can be automatically deployed without human intervention. At the same time, a trusted access mechanism is established through identity credentials and short-term access tokens to ensure the security of the configuration acquisition process. Furthermore, the online status can be verified and managed through the feedback of self-test results, thereby improving overall deployment efficiency and system reliability.

[0006] Preferably, the step of obtaining the address information of the intelligent boot server and establishing a connection with the intelligent boot server based on the address information includes: The system checks if the device is powered on. If it is, it loads the factory default configuration to enter the initial network state and then initializes the wired interface. Based on the wired interface, an address acquisition request is initiated to the external network, wherein the address acquisition request is broadcast based on the DHCP protocol; Receive response messages returned based on the address request in real time; Parse the response message to obtain the corresponding IP address; Obtain the address information of the intelligent boot server, and establish a connection with the intelligent boot server based on the address information and the IP address.

[0007] By adopting the above technical solutions, the device can automatically complete basic network access in unknown network environments. At the same time, by combining response message parsing and address information acquisition mechanisms, the device can accurately establish a connection with the intelligent boot server, thereby improving the device's startup success rate and network adaptability in complex field environments.

[0008] Preferably, the step of obtaining the address information of the intelligent boot server specifically includes: Parse the startup file name or vendor-specific information in the response message to obtain the address information of the smart boot server; Alternatively, the pre-configured DNS domain name in the factory default settings can be called to resolve the DNS domain name and obtain the address information of the smart boot server.

[0009] By adopting the above technical solutions, multi-path guidance capability is achieved, enabling server discovery under different network conditions or device configurations, thereby enhancing system compatibility and robustness and reducing dependence on a single network configuration method.

[0010] Preferably, the step of sending identity credential information to the cloud control plane through the intelligent bootstrap server, so that the cloud control plane can perform security authentication on the identity credential information, and if the authentication is successful, generating and returning the corresponding short-term access token, includes: The system sends identity credential information to the intelligent boot server to generate a corresponding authentication request, and then forwards the authentication request to the security authentication service of the cloud control plane through the intelligent boot server. Based on the security authentication service, the certificate validity and inventory status of the identity credential information are verified to achieve secure authentication of the identity credential information by the cloud control plane; If authentication is successful, a corresponding short-term access token will be generated and returned based on the inventory status.

[0011] By adopting the above technical solutions, the authentication process is transferred from the device side to the cloud for unified processing. At the same time, the joint verification mechanism of certificate validity and inventory status ensures that only legitimate devices that are in a deployable state can obtain short-term access tokens, thereby improving the security and controllability of the overall system.

[0012] Preferably, the identity credential includes a unique device certificate injected during the manufacturing process, and an alternative credential, wherein the alternative credential is composed of a device serial number, a MAC address, and a one-time factory activation code.

[0013] By adopting the above technical solutions, a compatibility solution is provided based on the preferred strong authentication method, so that the system can ensure high security while taking into account accessibility under different device conditions, thereby improving the system's applicability and deployment flexibility.

[0014] Preferably, based on the security authentication service, the step of verifying the certificate validity and inventory status of the identity credential information includes: Based on the security authentication service, the certificate validity of the identity credential information is verified, and a corresponding first authentication result is generated. Based on the security authentication service, the pre-stored policy library is invoked to determine whether an inventory status associated with the identity credential information is matched in the policy library, and a corresponding second authentication result is generated. The inventory status includes registration information and a pending deployment status identifier. If both the first authentication result and the second authentication result indicate successful authentication, then the security authentication service is determined to be successful. If the first authentication result and / or the second authentication result indicate authentication failure, then the security authentication service is determined to be an authentication failure.

[0015] By adopting the above technical solutions, multi-dimensional verification of device identity is achieved, thereby effectively preventing counterfeit or unauthorized devices from accessing the system and further enhancing the rigor and security of the authentication process.

[0016] Preferably, the step of reporting device identity and environment information to the policy service of the cloud control plane based on the short-term access token, so that the policy service generates and returns the corresponding final configuration policy, includes: Based on the short-term access token, a communication path is established through a secure channel, proxied by the smart bootstrap server. This communication path is used to connect to the policy service of the cloud control plane. Through the communication path, device identity and environment information are reported to the policy service, wherein the environment information includes the IP address obtained by accessing the wired interface, the autonomous system number of the connected operator, the device model and hardware version; Based on the policy service, a corresponding environment context and specific environment variables are generated according to the environment information, wherein the specific environment variables include the service IP range and VPN endpoint address allocated to the site; Based on the policy service, a corresponding policy template is determined from a preset policy library according to the device identity and environmental context. Based on the policy template and the specific environment variables, the corresponding final configuration policy is generated.

[0017] By adopting the above technical solutions, the transformation from static configuration distribution to environment-based dynamic policy generation is realized, thereby significantly improving the adaptability and intelligence level of configuration.

[0018] Preferably, the step of generating the corresponding final configuration policy based on the policy template and the specific environment variables includes: Based on the configuration template engine in the policy service, a corresponding preliminary configuration policy is rendered and generated according to the policy template and the specific environment variables. The corresponding native format is determined based on the device identity; Based on the original format, the initial configuration strategy is converted to generate the corresponding final configuration strategy.

[0019] By adopting the above technical solutions, the configuration generation process becomes structured and automated, while also enabling format adaptation between different devices, thereby improving the flexibility and cross-device compatibility of configuration generation.

[0020] Preferably, the native format includes CLI scripts, NETCONF / YANG data models, or vendor API call sequences.

[0021] By adopting the above technical solutions, the system can be adapted to the configuration interfaces of devices from different manufacturers, thereby achieving unified management of heterogeneous devices, reducing system integration complexity and improving scalability.

[0022] Preferably, the step of loading the final configuration strategy into the runtime configuration and executing a self-check process to generate and report the corresponding self-check results to the cloud control plane includes: Verify the syntax logic in the final configuration strategy. If the verification is successful, load the final configuration strategy into the runtime configuration. The self-test process is executed, which includes testing whether the connectivity performance of the core data reaches a preset performance threshold and detecting whether the status information of the key routes reaches a preset status threshold, thereby generating the corresponding self-test results. Based on the cloud control plane, it is determined whether the self-test result indicates that the device has been successfully launched. If the self-test result indicates that the device has been successfully launched, the inventory status in the inventory system is updated, and the configuration version and launch timestamp corresponding to the self-test result are recorded.

[0023] By adopting the above technical solutions, closed-loop verification and status feedback of configuration execution results can be achieved, thereby improving the stability, observability, and automation level of system operation and maintenance management.

[0024] In summary, this application includes at least one of the following beneficial technical effects: This application constructs an automated configuration chain that is automatically triggered by the device, with unified decision-making and closed-loop verification in the cloud. This transforms the device online process from a traditional method relying on manual or static configuration to one based on remote interaction and dynamic generation. Specifically, after powering on, the device first automatically discovers and connects to the intelligent boot server via the network, thus establishing a communication entry point with the cloud control plane. Based on this, the device sends identity credential information, and the cloud control plane performs centralized security authentication. After successful authentication, a short-term access token is issued, granting the device controlled access to subsequent services. Subsequently, the device reports its status and network environment information to the policy service of the cloud control plane based on this short-term access token. This allows the cloud to analyze and process the information under a unified policy system, combining the device's identity and the actual environment, to generate a final configuration policy for the device. After obtaining the configuration policy, the device directly loads it into the runtime configuration and executes a self-check process, feeding back the execution results to the cloud control plane, thus forming a complete closed loop from configuration generation to configuration verification. This not only eliminates the reliance on on-site manual configuration, significantly shortening the equipment deployment cycle and reducing the probability of human error, but also enhances the security of system access through centralized authentication and token control. Furthermore, it leverages cloud-based policy generation mechanisms to achieve configuration uniformity and adaptability, enabling devices to obtain matching configurations in different network environments. This, in turn, improves the overall efficiency, reliability, and manageability of large-scale distributed network deployments. Attached Figure Description

[0025] Figure 1This is a flowchart of a zero-contact start-up and automated equipment configuration method according to an embodiment of this application. Detailed Implementation

[0026] The present application will be further described in detail below with reference to the accompanying drawings.

[0027] In one embodiment, such as Figure 1 As shown, this application discloses a zero-contact start-up and automated equipment configuration method, which includes: S10. Obtain the address information of the intelligent boot server and establish a connection with the intelligent boot server based on the address information; S20. Send identity credential information to the cloud control plane through the intelligent boot server so that the cloud control plane can perform security authentication on the identity credential information. If the authentication is successful, generate and return the corresponding short-term access token. S30. Based on short-term access tokens, report device identity and environment information to the policy service of the cloud control plane so that the policy service can generate and return the corresponding final configuration policy; S40. Load the final configuration policy into the runtime configuration and execute the self-test process to generate and report the corresponding self-test results to the cloud control plane.

[0028] In this embodiment, the intelligent boot server is a boot node deployed in the network. It provides an initial access point when the device is in its factory default state. Specifically, after the device completes basic network initialization, it obtains the device's address through a preset discovery mechanism and establishes a communication connection with the device, thus serving as an intermediate access point between the device and the cloud control plane. This point is used to forward subsequent authentication requests and establish communication paths. The cloud control plane is a management system centrally deployed in a data center or cloud environment. It integrates security authentication services and policy services to uniformly manage device access, identity verification, and configuration policy generation. By analyzing and processing the identity and environmental information of the accessed devices, it achieves centralized control of the devices. Policy distribution; Identity credential information is a data set used to identify the device's identity. It is generated and stored internally by the device during manufacturing or initialization and sent to the cloud control plane for verification during device access. This information uniquely identifies a specific device, thus determining the device's legitimacy; Security authentication is the process by which the cloud control plane verifies the identity credential information. It compares the validity of the identity credential information with pre-stored data to determine whether the device has access permissions and triggers subsequent access control procedures upon successful authentication; Short-term access tokens are time-limited access credentials generated by the cloud control plane after successful authentication. They are used to indicate that the device has been authenticated during subsequent communication. This serves as the authorization basis for access policy services, thereby avoiding duplicate authentication and improving communication security. Device identity is the device identifier obtained by matching identity credentials in the cloud control plane. It is used to determine the device's category and management scope in the policy service, thus serving as an important basis for policy matching. Environmental information consists of network and hardware status data collected by the device through local interfaces during operation. This includes information such as the IP address obtained through the wired interface, the autonomous system number corresponding to the connected network, and the device model and hardware version, reflecting the actual operating environment of the device. The policy service is a functional module in the cloud control plane that analyzes and processes device identity and environmental information to generate a policy that matches the current... The configuration strategy matches the device status, enabling dynamic configuration generation. The final configuration strategy is the result data directly usable for device configuration after processing by the policy service. It includes network parameters, routing rules, and related service configuration content, guiding the device to complete network access and service initialization. The running configuration is the configuration state currently being executed by the device. It is stored in the device's operating environment and updates the corresponding parameters after loading the final configuration strategy, enabling the device to operate according to the new configuration. The self-test process is a detection process automatically executed by the device after loading the configuration. It detects key network connectivity and operating status to determine whether the configuration is effective and meets preset requirements, and generates corresponding detection results for feedback.The self-test result is the output data after the self-test process is executed. It is used to characterize the current operating status and configuration execution of the equipment, and is transmitted back to the cloud control plane for status determination and management, thereby completing the closed-loop control of the entire process from equipment access to online operation.

[0029] In another embodiment, the method is implemented collaboratively by a cloud control plane, an intelligent bootstrapping server, and the device side. The cloud control plane, as the core control node, integrates a device identity and policy library, a configuration template engine, and a security authentication service to manage device identities, generate configuration policies, and control access. The device identity and policy library stores the device identity information of authorized devices and their associated configuration policy templates. The device identity information includes the device serial number, hardware identification information, and corresponding unique device certificate, and establishes a mapping relationship with specific devices. The configuration policy templates are categorized and stored based on conditions such as device model, deployment location, business domain, and access network type to support subsequent policy matching. The configuration template engine parses and renders the policy templates by matching and replacing the parameter placeholder structures in the policy template with specific environment variables to generate the final configuration policy that meets the device's execution requirements. The security authentication service verifies the identity credential information sent by the device by jointly verifying the validity of the unique device certificate and the device's inventory status in the device identity and policy library to control device access permissions.

[0030] On the network side, the intelligent boot server is deployed in the data center or network access node. It is used to respond to the discovery request initiated by the device during the startup phase and provide the device with a connection entry point. At the same time, it acts as a relay node between the device and the cloud control plane, forwarding authentication requests and carrying subsequent communication paths. In specific implementations, the intelligent boot server supports communication methods based on secure channels, thereby ensuring the security of data transmission. In complex network environments, proxy nodes can be further deployed in the network to establish a stable communication path between the device and the cloud control plane, so as to solve connection problems caused by network address translation or access restrictions.

[0031] On the device side, the device integrates device-side agent logic, which automatically starts after the device is powered on. First, it completes network initialization through the wired interface and obtains the address information of the smart boot server according to preset rules. Then, it sends identity credential information to the cloud control plane through the smart boot server to complete security authentication. After successful authentication and obtaining a short-term access token, the device-side agent logic establishes a communication path with the cloud control plane based on the short-term access token and reports the device identity and environment information. The cloud control plane matches the corresponding policy template in the device identity and policy library according to the device identity and environment information, and generates the final configuration policy by combining the configuration template engine with specific environment variables. After receiving the final configuration policy, the device loads it into the running configuration and executes the self-check process, thereby completing the automated process from device startup and access to configuration taking effect.

[0032] Furthermore, the steps of obtaining the address information of the smart boot server and establishing a connection with the smart boot server based on the address information include: S101. Detect whether the power is on. If the power is on, load the factory default configuration to enter the initial network state and then initialize the wired interface. S102. Based on the wired interface, initiate an address acquisition request to the external network, wherein the address acquisition request is broadcast based on the DHCP protocol; S103. Receive the response message returned by the address acquisition request in real time; S104. Parse the response message to obtain the corresponding IP address; S105. Obtain the address information of the smart boot server, and establish a connection with the smart boot server based on the address information and IP address.

[0033] In this embodiment, "power-on" refers to the startup state after the device is connected to a power source. This state triggers the internal processing unit of the device to execute a preset startup program and enter the system initialization phase. The factory default configuration is a set of basic configurations pre-written into the storage medium after the device is manufactured. It provides the minimum available network functionality when the device has not undergone any user configuration, enabling the device to establish basic communication capabilities in an unknown environment. The initial network state is the basic operating state formed after the device loads the factory default configuration. In this state, the device possesses the most basic network protocol processing capabilities, thus enabling it to execute subsequent network request operations. The wired interface is the physical communication interface on the device used to connect to external networks. It establishes a link connection with external network devices through Ethernet electrical characteristics and has data transmission and reception capabilities after initialization. The address acquisition request is a data packet sent by the device to the network through the wired interface to request network parameters. It follows the message format of the Dynamic Host Configuration Protocol (DHCP) and is sent via broadcast in the local area network to request an IP address and related network configuration information. The DHCP protocol is also mentioned. This is a communication protocol used for dynamically allocating network addresses. It uses a set of standard interaction procedures to negotiate addresses between devices and network servers, enabling devices to automatically obtain IP addresses and parameters such as gateways and DNS. The response message is a data packet returned by the DHCP server in the external network in response to the address acquisition request. It contains the IP address assigned to the device and other network configuration information, and is transmitted to the device side for reception and processing. The IP address is a logical address used to identify the device's location in the network. It is assigned by the network side after the device interacts with the device through the DHCP protocol and is used for subsequent data communication and server access. The address information is used to identify the location of the intelligent boot server in the network. It can be obtained by parsing specific fields in the response message or through a preset resolution mechanism and is used to guide the device to establish subsequent connections. Through the synergistic effect of the above elements, the device can complete the entire process from power-on startup and network initialization to obtaining a network address and determining the location of the target server without manual intervention, thereby providing the basic network conditions and communication path for establishing a connection with the intelligent boot server.

[0034] Furthermore, the specific steps for obtaining the address information of the intelligent boot server are as follows: Parse the boot file name or vendor-specific information in the response message to obtain the address information of the smart boot server; Alternatively, it can call the DNS domain name pre-configured in the factory default settings, resolve the DNS domain name, and obtain the address information of the smart boot server.

[0035] In this embodiment, the startup file is a boot parameter field included in the response message. It indicates the network resource path or server location information that the device needs to access during the startup phase. During the actual parsing process, the device extracts and parses the corresponding fields in the response message, converting the server address or path information into address data that can be used to establish a communication connection. Vendor-specific information is an extended field reserved in the response message. It carries boot server-related information configured by the network or system side according to a predefined data structure. The device decodes and parses the content of this field to extract the intelligent boot server address information, thereby achieving compatibility support for devices from different vendors. The DNS domain name is the default one set at the factory. The domain name identifier pre-written in the configuration points to the network location of the intelligent boot server. After the device calls this DNS domain name, it sends a query request to the DNS server through the domain name resolution mechanism and receives the corresponding resolution result, converting the domain name into an actual accessible network address, thereby obtaining the address information of the intelligent boot server. Through the above two methods, the device can flexibly obtain the address information of the intelligent boot server under different network environments and configuration conditions. On the one hand, it realizes boot discovery based on network dynamic allocation by resolving the boot file name or vendor-specific information in the response message. On the other hand, it realizes boot location of a fixed entry point through the pre-configured DNS domain name, thereby improving the system's adaptability and reliability in complex network environments.

[0036] Specifically, after power-on, the device automatically enters the startup process and loads the preset factory default configuration, thus entering the initial network state. In this state, the device completes the initialization of the wired interface and initiates an address acquisition request to the external network through the wired interface to obtain an IP address. The IP address is used to identify the device's communication location in the current network and serves as the basic parameter for establishing a subsequent communication connection. After obtaining the IP address, the device's proxy logic obtains the address information of the intelligent boot server based on a preset boot discovery mechanism. Specifically, this is done by parsing the boot file name or manufacturer-specific information field in the response message, or by calling and resolving the DNS domain name pre-configured in the factory default configuration, thereby obtaining the address information of the intelligent boot server. The DNS domain name, for example, is ztp.corp.com, used to provide a unified boot entry point in different network environments. After obtaining the address information, the device establishes a connection with the intelligent boot server based on the IP address. The connection is established through a secure channel to ensure data security during communication, thus completing the device discovery and boot process and providing a communication foundation for subsequent identity credential information transmission and security authentication.

[0037] Furthermore, the step of sending identity credential information to the cloud control plane via the intelligent bootstrap server, enabling the cloud control plane to securely authenticate the identity credential information, and generating and returning the corresponding short-term access token if authentication is successful, includes: S201. Send identity credential information to the intelligent boot server to generate a corresponding authentication request, and then forward the authentication request to the cloud control plane's security authentication service through the intelligent boot server. S202. Based on the security authentication service, verify the certificate validity and inventory status of the identity credential information to achieve secure authentication of the identity credential information by the cloud control plane; S203. If authentication is successful, a corresponding short-term access token will be generated and returned based on the inventory status.

[0038] In this embodiment, the authentication request is a standardized authentication data message generated by the device after sending identity credential information. It includes identity credential information and additional parameters related to the authentication process, used to trigger subsequent identity verification procedures, and is transmitted to the intelligent boot server via the network after generation. The security authentication service is an authentication processing module deployed in the cloud control plane, used to receive authentication requests forwarded by the intelligent boot server and perform unified authentication logic processing on the identity credential information contained therein. Certificate validity is the result of a legality verification of the unique device certificate in the identity credential information. It verifies the certificate's issuing source, integrity, and validity period to determine whether the certificate is trustworthy. Inventory status is the current device status recorded in the device identity and policy database. Management status indicates whether a device has been registered with the system and is in an accessible state. This status is usually associated with the device's registration information and deployment stage, thus serving as an important basis for determining whether the device is qualified to go online. During the authentication process, the security authentication service first judges the credibility of the identity credential information based on the certificate validity, and then verifies the device's authorization status in conjunction with the inventory status. Only when both meet the preset conditions is the authentication considered successful. The short-term access token is an access control credential generated after successful authentication. It is generated based on the inventory status or the management information corresponding to the device. It is used to identify that the device has been authenticated in subsequent communication processes and serves as the authorization basis for accessing policy services in the cloud control plane, thereby avoiding duplicate authentication and ensuring the security and continuity of subsequent interaction processes.

[0039] Furthermore, the identity credentials include a unique device certificate injected during the manufacturing process, as well as alternative credentials, which are composed of a device serial number, MAC address, and a one-time factory activation code.

[0040] In this embodiment, the unique device certificate is a digital certificate generated by the production system and injected into the device's internal storage medium during the device manufacturing process. It is generated based on the Public Key Infrastructure (PKI) system and corresponds one-to-one with the device hardware. It serves as the core identity identifier for authentication during subsequent network access. This unique device certificate cannot be modified or copied after generation, thus ensuring the uniqueness and immutability of the device's identity. The alternative credential is an alternative identity identifier used when the unique device certificate is unavailable or unsupported. It is formed by combining the device serial number, MAC address, and a one-time factory activation code. The device serial number is a unique identifier generated during the device's manufacturing process. The unique serial number assigned during the process is used to identify the production batch and individual information of the device. The MAC address is the hardware address corresponding to the device's network interface, used for link-layer identification in network communication. The one-time factory activation code is a temporary authentication credential generated and distributed with the device when it leaves the factory. It has a one-time use characteristic to prevent reuse or illegal copying. By combining the device serial number, MAC address and one-time factory activation code, a unique and secure identity identifier can be formed. This allows for device authentication even in the absence of a unique device certificate, ensuring the system's access compatibility and security under different device conditions.

[0041] Furthermore, the steps for verifying the certificate validity and inventory status of identity credential information based on security authentication services include: S2021. Based on the security authentication service, verify the validity of the identity credential information certificate and generate the corresponding first authentication result; S2022. Based on the security authentication service, call the pre-stored policy library, determine whether the inventory status associated with the identity credential information is matched in the policy library, and generate the corresponding second authentication result. The inventory status includes registration information and a pending deployment status identifier. S2023. If both the first and second authentication results indicate successful authentication, then the security authentication service is deemed to have been successfully authenticated. S2024. If the first authentication result and / or the second authentication result indicate authentication failure, then the security authentication service is determined to be authentication failure.

[0042] In this embodiment, the first authentication result is the judgment result output by the security authentication service after verifying the validity of the unique device certificate in the identity credential information. It is used to characterize whether the unique device certificate meets the trust conditions. Specifically, the security authentication service verifies parameters such as the issuance link, integrity, and validity period of the unique device certificate, and solidifies the verification conclusion as the first authentication result in the form of success or failure, thereby providing a directly referable basis for subsequent comprehensive judgment. The policy library is a set of device management data pre-stored in the cloud control plane. It at least includes device identity and device registration records and status records in the policy library, and is used to verify whether the device is included in the management scope and whether it has the qualification to go online during the authentication stage. The second authentication result is the judgment result output by the security authentication service based on the query matching of the policy library. It is used to characterize whether a match can be found in the policy library. The inventory status associated with identity credential information includes registration information and a pending deployment status identifier. Registration information indicates whether the device has been registered in the system, while the pending deployment status identifier indicates whether the device is currently in a stage where it is permitted to be deployed online. During the comprehensive judgment process, the security authentication service uses the first authentication result as the credibility criterion for identity credential information and the second authentication result as the device authorization status criterion. When both the first and second authentication results indicate successful authentication, authentication is confirmed as successful, allowing the generation and issuance of subsequent short-term access tokens. When the first and / or second authentication results indicate authentication failure, authentication is confirmed as failed, thus blocking the access process of devices that have failed the credibility verification or authorization status verification. This prevents unauthorized devices from accessing the system or devices not in a pending deployment state from being mistakenly deployed online, improving the security and controllability of the authentication process.

[0043] Specifically, after establishing a connection with the intelligent boot server, the device sends identity credential information to the server via its device-side proxy logic. The preferred identity credential information is a unique device certificate injected into the device during manufacturing. This unique device certificate conforms to the IEEE 802.1AR standard and serves as the device's unique identifier. If the unique device certificate is unavailable, an alternative credential can be used for identification. This alternative credential is formed by combining the device serial number, MAC address, and a one-time factory activation code, thus ensuring compatible acquisition of identity credential information under different device conditions. After the device sends the identity credential information, the intelligent boot server, based on the received identity credential information... The system generates a corresponding authentication request and forwards it to the security authentication service in the cloud control plane. Upon receiving the authentication request, the security authentication service verifies the identity credential information, including verifying the validity of the unique device certificate and checking the device inventory status corresponding to the identity credential information based on the device identity and policy library. The inventory status indicates whether the device has been registered in the system and is in a pending deployment state. When the certificate validity verification is successful and the inventory status indicates that the device is in a pending deployment state, the authentication is confirmed to be successful, and the security authentication service generates a corresponding short-term access token and returns it to the device, thereby providing authorization credentials for the device to access the policy service in the cloud control plane in the future.

[0044] Furthermore, the step of reporting device identity and environment information to the policy service in the cloud control plane based on short-term access tokens, so that the policy service can generate and return the corresponding final configuration policy, includes: S301. Based on a short-term access token, a communication path is established through a secure channel, proxies by the intelligent boot server. This communication path connects to the policy service of the cloud control plane. After obtaining the short-term access token, the device embeds it as a session credential into subsequent communication messages and establishes an encrypted connection with the intelligent boot server based on a preset secure transmission protocol, thus constructing a secure channel. During the establishment process, the device initiates a connection request through the intelligent boot server, which forwards the request and acts as an intermediate proxy node to establish a corresponding session link with the policy service of the cloud control plane. Simultaneously, the encrypted state of the messages is maintained during forwarding to prevent data leakage. This method forms a communication path from the device to the intelligent boot server and then to the policy service. The short-term access token is used for access verification on the policy service side, ensuring that only authenticated devices can access the policy service, achieving security in the communication process and consistency in access control.

[0045] S302. Through the communication path, the device reports its identity and environment information to the policy service. The environment information includes the IP address obtained by accessing the wired interface, the autonomous system number of the connected operator, the device model, and the hardware version. After the communication path is established, the device constructs a data packet containing the device identity and environment information and sends it to the policy service through the communication path. The device identity is filled in by the device identifier obtained by parsing or mapping the identity credential information. The environment information is collected and generated in real time by the device during local operation. Specifically, the device obtains the assigned IP address through the wired interface, obtains the corresponding operator autonomous system number by performing network query or routing analysis on the IP address, and reads the device model and hardware version information stored in the device. The above data is then encapsulated according to a preset data structure and sent to the policy service for subsequent policy matching and configuration generation.

[0046] S303. Based on the policy service, the corresponding environmental context and specific environmental variables are generated according to the environmental information. The specific environmental variables include the service IP segment and VPN endpoint address allocated to the site. After receiving the environmental information reported by the device, the policy service parses and normalizes the environmental information, mapping the IP address, operator autonomous system number, device model, and hardware version to a pre-established rule model to determine the network type, access area, and device category of the device, thereby forming the corresponding environmental context. On this basis, the policy service further calls the pre-stored service configuration data and address allocation policy, calculates and allocates parameters according to the environmental context, and generates specific environmental variables for configuration rendering, including the service IP segment allocated to the corresponding site and the VPN endpoint address used to establish the tunnel connection, thereby providing structured parameter support for the generation of subsequent configuration policies.

[0047] S304. Based on the policy service, the corresponding policy template is determined in the preset policy library according to the device identity and environment context. After obtaining the device identity and the corresponding environment context, the policy service uses the device identity as the main index condition and combines it with parameters such as network type, access area and device category in the environment context to perform multi-dimensional matching processing on the preset policy library. The policy library pre-stores a set of policy templates corresponding to different device types and deployment scenarios. During the matching process, the policy service filters and compares the conditions of each dimension according to the preset priority rules, thereby determining the policy template that best matches the current device in the policy library, and calling this policy template as the base template for subsequent configuration generation.

[0048] S305. Based on the policy template and specific environment variables, generate the corresponding final configuration policy. After determining the policy template, the policy service calls the built-in configuration template engine to parse the policy template, mapping the parameter placeholder structure in the policy template to specific environment variables one by one, and filling the specific environment variables into the corresponding positions according to preset rendering rules, thereby generating structurally complete configuration data. During the generation process, the configuration template engine also verifies the dependencies between various parameters and determines the corresponding configuration output format according to the device identity, so that the generated configuration data meets the configuration interface specification of the target device, and finally forms a final configuration policy that can be directly issued and executed, thereby ensuring that the configuration content is logically correct and formatted to adapt to the device-side execution environment.

[0049] Furthermore, the step of generating the corresponding final configuration policy based on the policy template and specific environment variables includes: S3051. Based on the configuration template engine in the policy service, the corresponding preliminary configuration policy is rendered and generated according to the policy template and specific environment variables. S3052. Determine the corresponding native format based on the device identity; S3053. Based on the original format, the initial configuration strategy is converted to generate the corresponding final configuration strategy.

[0050] In this embodiment, the configuration template engine is a configuration generation module integrated into the policy service. It is used to parse the policy template structure and perform variable substitution operations. During actual operation, the configuration template engine first identifies the parameter placeholder structure in the policy template and maps specific environment variables to their corresponding positions according to preset syntax rules, thereby generating configuration data that is structurally complete but not yet adapted to the specific device interface format. The preliminary configuration policy is an intermediate configuration result obtained after rendering by the configuration template engine. It contains complete business parameters and logical structures, but still uses a unified abstract expression form and has not yet been converted into a native configuration format that the target device can directly execute. Device identity in this step is used to indicate the type of device and its supported configuration interface capabilities. The service parses the device type information corresponding to the device identity and determines the configuration expression method supported by the device from the pre-established device capability mapping relationship, thereby obtaining the corresponding native format. The native format is the configuration expression form directly supported by the device's operating system or management interface, which is used to describe the specific syntax structure and calling method of the device configuration, such as command-line script form, structured data model form, or interface call sequence form. During the format conversion process, the policy service reconstructs and adjusts the syntax of the preliminary configuration policy according to the native format to make it conform to the configuration interface specification of the target device, thereby generating the final configuration policy. This final configuration policy can be directly parsed by the device side and loaded into the runtime environment for execution, thereby completing the adaptation process of configuration distribution.

[0051] Furthermore, native formats include CLI scripts, NETCONF / YANG data models, or vendor API call sequences.

[0052] In this embodiment, the CLI script is a configuration expression based on the device command-line interface. It sets parameters for the device item by item through a command sequence organized according to preset syntax rules. During execution, the device parses and applies the corresponding configuration according to the command order, thereby loading functions such as interface, routing, and security policies. The NETCONF / YANG data model is a configuration method based on structured data modeling. YANG is used to define the data structure and constraints of device configuration, and NETCONF is used as a transmission protocol to carry out the distribution and management of configuration data. The device updates its internal configuration database by parsing the configuration content that conforms to the data model specification, thereby achieving structured management and consistency control of the configuration. The vendor API call sequence is a set of call flows defined by the programming interface provided to the device. It constructs request data according to the interface specification and calls the relevant interfaces in sequence to realize the configuration and control of various functional modules of the device. It is suitable for device environments that support open interfaces. By supporting the above-mentioned multiple native formats, the generated configuration strategy can be adapted to the configuration interface capabilities of different devices, thereby achieving unified management and flexible configuration of heterogeneous devices.

[0053] Specifically, after establishing a connection with the intelligent boot server, the device sends identity credential information to the server via its device-side proxy logic. The preferred identity credential information is a unique device certificate injected into the device during manufacturing. This unique device certificate conforms to the IEEE 802.1AR standard and serves as the device's unique identifier. If the unique device certificate is unavailable, an alternative credential can be used for identification. This alternative credential is formed by combining the device serial number, MAC address, and a one-time factory activation code, thus ensuring compatible acquisition of identity credential information under different device conditions. After the device sends the identity credential information, the intelligent boot server, based on the received identity credential information... The system generates a corresponding authentication request and forwards it to the security authentication service in the cloud control plane. Upon receiving the authentication request, the security authentication service verifies the identity credential information, including verifying the validity of the unique device certificate and checking the device inventory status corresponding to the identity credential information based on the device identity and policy library. The inventory status indicates whether the device has been registered in the system and is in a pending deployment state. When the certificate validity verification is successful and the inventory status indicates that the device is in a pending deployment state, the authentication is confirmed to be successful, and the security authentication service generates a corresponding short-term access token and returns it to the device, thereby providing authorization credentials for the device to access the policy service in the cloud control plane in the future.

[0054] Furthermore, the steps of loading the final configuration strategy into the runtime configuration and executing a self-check process to generate and report the corresponding self-check results to the cloud control plane include: S401. Verify the syntax logic in the final configuration strategy. If the verification is successful, load the final configuration strategy into the runtime configuration. S402. Execute the self-test process. The self-test process includes testing whether the connectivity performance of the core data reaches the preset performance threshold, and detecting whether the status information of the key routes reaches the preset status threshold, thereby generating the corresponding self-test results. S403. Based on the cloud control plane, determine whether the self-test result indicates that the device has been successfully launched. If the self-test result indicates that the device has been successfully launched, update the inventory status in the inventory system and record the configuration version and launch timestamp corresponding to the self-test result.

[0055] In this embodiment, the syntax logic is a set of configuration rules that the final configuration policy must satisfy before execution on the device side. This includes the legality of the command format, the validity of parameter values, and the dependencies between configuration items. In specific implementation, the device uses its built-in configuration parsing module to parse the final configuration policy line by line, verifying the command structure and parameter range to determine whether the configuration meets the device's execution requirements. The running configuration is the set of configurations currently in effect on the device, stored in the device's running memory or configuration database. After verification, the final configuration policy is written into the running configuration by calling the device configuration interface, enabling the device to operate according to the new parameters. The self-test process is a detection mechanism automatically triggered by the device after configuration loading. It verifies network functions by calling the device's internal detection module. The connectivity performance of core data refers to the data communication capability between the device and key nodes. For example, it detects connectivity with the gateway or remote nodes by sending test packets and determines whether a preset performance threshold is reached by statistically analyzing response time or packet loss. The status information of key routes refers to the availability status of key paths in the device's routing table, which is determined by detecting whether the route exists, is reachable, and forwards. The system determines whether a device has reached a preset state threshold by checking if the table is updated normally. The self-check result is the data generated after the self-check process is executed. It is used to comprehensively reflect the running status after the configuration is loaded and is reported to the cloud control plane through the communication path. The inventory system is a management module in the cloud control plane used to manage the device lifecycle. It records data such as the device's registration information, deployment status, and running status. After receiving the self-check result, it is used to update the current status of the device. The configuration version is the version information that identifies the final configuration policy issued and applied each time. It is used to distinguish different configuration contents and support subsequent traceability and rollback operations. The online timestamp is the time stamp that records the time when the device completes the online process. It is used to identify the time point when the device enters the normal operating state. In the overall process, the device first performs syntax and logic verification on the final configuration policy. After the verification is passed, the configuration is loaded into the running configuration and the self-check process is executed. After generating the self-check result, it is reported to the cloud control plane. The cloud control plane determines whether the device has been successfully online based on the self-check result. When successful, it updates the inventory status in the inventory system and records the corresponding configuration version and online timestamp, thereby realizing closed-loop management and status traceability of the device online process.

[0056] Specifically, after generating the final configuration policy, the cloud control plane distributes the final configuration policy to the device through a secure channel established with the device. The final configuration policy is expressed using a configuration interface format natively supported by the device, including CLI scripts, NETCONF / YANG data models, or vendor API call sequences, thereby ensuring that the final configuration policy can be directly recognized and processed by the device. After receiving the final configuration policy, the device parses and processes it through its device-side proxy logic and verifies its syntax logic in the device's memory to ensure the correctness and executability of the configuration content. After successful verification, the final configuration policy is loaded into the runtime configuration, enabling the device to initialize network parameters and service functions according to the final configuration policy. After the configuration is loaded, the device immediately executes a self-test process. This process includes testing the connectivity of core data, such as the VPN connectivity between the device and remote nodes, and checking the status information of key routes to determine whether the network path is established correctly. Based on the test results, the device generates corresponding self-test results. Subsequently, the device reports the self-test results to the cloud control plane through the communication path. After receiving the self-test results, the cloud control plane analyzes and judges them to confirm whether the device has successfully gone online. When the self-test result indicates that the device has successfully gone online, the cloud control plane updates the inventory status in the inventory system to online and records the configuration version and online timestamp corresponding to the self-test result, thereby realizing closed-loop management of device configuration distribution, execution verification, and status update.

[0057] In this embodiment, a unique device certificate is pre-injected into the device during the device manufacturing stage, and this unique device certificate is used as a core component of the identity credential information during the device access process for security authentication. This enables the cloud control plane to complete a trusted verification of the device identity based on the unique device certificate. Thus, the authentication stage simultaneously achieves joint verification of the certificate validity and the device inventory status, avoiding the risk of identity forgery caused by relying solely on the device serial number or MAC address. Furthermore, a short-term access token mechanism is used to authorize and control subsequent access, thereby establishing a secure and reliable communication foundation in the initial stage of device access, preventing unauthorized device access and man-in-the-middle attacks in the communication link, and improving the security and reliability of the overall automated process. After passing security authentication, the device reports its identity and environment information to the policy service of the cloud control plane based on a short-term access token. The environment information includes the IP address obtained through the wired interface, the autonomous system number of the connected operator, the device model, and the hardware version. The cloud control plane generates a corresponding environment context based on the environment information and matches the corresponding policy template with the device identity and policy library. Then, the policy template and specific environment variables are rendered through the configuration template engine to generate the final configuration policy. This realizes the transformation from static configuration distribution to dynamic configuration generation based on environment information, so that the same device can obtain the appropriate configuration content in different network environments and deployment scenarios, improving the accuracy and adaptability of configuration. By setting up device-side proxy logic and combining a configuration template engine with various native format generation mechanisms in the cloud control plane, the final configuration policy can automatically adapt to different configuration interface forms such as CLI scripts, NETCONF / YANG data models, or vendor API call sequences based on the device identity. At the same time, the device-side proxy logic parses the final configuration policy and loads it into the runtime configuration, thereby enabling configuration execution of devices from different vendors under a unified process, shielding the differences in the underlying device interfaces, achieving unified management of heterogeneous devices, reducing system complexity, and improving system scalability.

[0058] The following scenario illustrates the specific implementation steps of this method through the example of a large retail chain "XX" deploying a new generation SD-WAN store network nationwide.

[0059] Background: "XX" plans to deploy new SD-WAN CPE devices in 300 stores to replace old routers. Each store has a different network environment (China Telecom, China Unicom, China Mobile broadband), and the new devices involve two different brands (BrandX and BrandY).

[0060] Step 1: Preliminary Preparations and "Fingerprint" Injection 1. In orders with equipment manufacturers (OEMs), “XX” requires that each device be injected with a unique X.509 device certificate (compliant with IEEE 802.1AR) at the end of the factory production line, and that information such as the certificate fingerprint (hash value), device serial number, and model number be pre-batch imported into the cloud device identity and policy library of this invention, with the status marked as “in stock”.

[0061] 2. The network operations team creates configuration policy templates for different scenarios in the cloud policy library: Template_Store_BrandX_Telecom: Applicable to stores with Brand X devices and access to the China Telecom network.

[0062] Template_Store_BrandX_Unicom: Applicable to Brand X devices and stores connected to the China Unicom network.

[0063] Template_Store_BrandY_Telecom: The appropriate template for Brand Y devices.

[0064] The template content is a variable configuration skeleton, including, for example: Placeholders such as ${STORE_ID}, ${WAN1_GATEWAY}, ${VPN_HUB_ADDRESS}, and ${DNS_SERVER}.

[0065] Step 2: Equipment Distribution and Simplified On-site Operation 1. The logistics company delivers the pre-certified equipment to each store. The accompanying "Getting Started Guide" contains only one sentence: "Connect the equipment to a power source and connect the WAN port to the store's broadband modem."

[0066] 2. Non-IT personnel in the store (such as the store manager) can follow these steps to complete the physical connection and then leave without any other settings.

[0067] Step 3: Automated Startup and Configuration Process (Taking a store connected to a telecommunications network as an example) Time point T0 (Power-on): The device is powered on and the built-in universal ZTP agent is started.

[0068] Time point T1 (network initialization): The device's WAN port obtains a dynamic public IP address (such as 58.32.10.100) and DNS server address from the telecom modem via DHCP.

[0069] Time point T2 (Server Discovery): The device agent performs a DNS query to resolve the pre-configured domain name ztp.retailchain.com and obtain the IP address of the intelligent boot server. This boot server has been deployed in multiple telecom cloud resource pools across the country, and the device will choose the one with the lowest latency.

[0070] Time point T3 (Security Authentication - mTLS Handshake): The device establishes an HTTPS connection with the bootstrap server and initiates a two-way TLS (mTLS) handshake. The device presents its factory certificate, and the server verifies whether the certificate was issued by a root certificate authority trusted by "RetailChain" and whether the certificate fingerprint exists in the "Inventory" device list in the identity database. At the same time, the server also presents its server certificate to the device, completing two-way authentication.

[0071] Time point T4 (Environment Reporting and Policy Request): After successful authentication, the device sends a JSON-formatted request message to the cloud control plane through a secure channel. json { "device_id": "SNX123456789", "certificate_thumbprint": "a1b2c3...", "model": "BrandX-CPE-1000", "wan_interface_info": [ { "ifname": "ge0 / 0", "assigned_ip": "58.32.10.100", "gateway": "58.32.10.1", "isp_asn": 4134 / / China Telecom AS number obtained through IP address lookup or route probing } ], "location_hint": "Shanghai-Pudong-Store-025" / / Optional, pre-associated based on device GPS or store information } Time point T5 (Dynamic Strategy Matching and Rendering): The cloud strategy service receives the request.

[0072] 1. Identity verification: Based on device_id and thumbprint, it is confirmed that this is the device assigned to "Shanghai Pudong No. 025 Store".

[0073] 2. Context matching: Identify isp_asn:4134 as China Telecom, and model as BrandX-CPE-1000.

[0074] 3. Strategy selection: Automatically match Template_Store_BrandX_Telecom.

[0075] 4. Variable Population: Query the business parameters of "Shanghai Pudong Store No. 025" from the store information database: STORE_ID=025, assigned VPNHub address is 203.0.113.10, and internal DNS is 10.10.10.10. Combine this with the gateway information reported by the device.

[0076] 5. Configuration Rendering: The template engine generates the final configuration. For BrandX devices, the final configuration may be a CLI script: bash Hostname and basic configuration hostname Store-025-CPE-X IP NameServer 10.10.10.10 ! WAN port configuration interface GigabitEthernet0 / 0 IP address 58.32.10.100 255.255.255.0 ip nat outside negotiation auto ! Default route ip route 0.0.0.0 0.0.0.0 58.32.10.1 IPSec VPN Configuration crypto isakmp policy 10 encryption aes 256 hash sha256 authentication pre-share group 14 crypto isakmp key mySecureSharedKey address 203.0.113.10 crypto ipsec transform-set MY-TRANSFORM esp-aes 256 esp-sh a256-hmac ... (More VPN and internal interface configurations) Time point T6 (Secure Distribution and Device Application): The rendered configuration is distributed to the device via the same mTLS channel. The device agent's configuration adapter (BrandX driver) is responsible for parsing this CLI script and securely injecting it line by line (avoiding interruption of the current management connection) into the device operating system in "configuration mode".

[0077] Time point T7 (Self-verification and Status Reporting): After the application configuration is complete, the device agent automatically performs an internal health check. 1. Test connectivity to gateway 58.32.10.1.

[0078] 2. Initiate an ICMP probe against VPN center 203.0.113.10 and attempt to establish an IPSecSA.

[0079] 3. Test DNS resolution to internal DNS 10.10.10.10. After all tests pass, the device sends a final status report to the cloud: {"status":"operational","config_version":"1.0","vpn_tunnel_status":"up"}.

[0080] Time point T8 (Closed loop and visualization): The cloud control plane updates the device status to "Online" and lights up the "Shanghai Pudong Store No. 025" node on the network topology map. The operations and maintenance center's large screen displays "Store No. 025 successfully online," with the entire process taking approximately 3-5 minutes.

[0081] Step 4: Scaling Up and Anomaly Handling 300 stores nationwide have implemented this process in parallel. The cloud-based system boasts high-concurrency processing capabilities. Abnormal scenario handling: Authentication failed: If the device certificate is invalid or not registered, the connection will be terminated immediately and a security alert will be generated in the console.

[0082] Network unreachable: If the store network cannot resolve or access the guiding domain name, the device will enter standby mode: attempt to obtain a local proxy address via DHCPOption, or eventually downgrade to a secure "call home" mode (send an SMS alert via the built-in 4G module to request remote assistance).

[0083] Configuration error: If the issued configuration causes the device management plane to lose connection, the device's built-in watchdog mechanism will automatically roll back to the last known good configuration after the timeout and report the error log.

[0084] Quantification of implementation results: Deployment efficiency: Traditionally, sending engineers to each store takes an average of 2 hours, totaling over 600 person-days. Using the method of this invention, physical operations at a single store take only 5 minutes, and the automated back-end process takes another 5 minutes, reducing total manpower input to near zero. Nationwide deployment can be completed in parallel within one week.

[0085] Configuration accuracy: 100%, completely eliminating human error.

[0086] Security baseline: All devices access the network with a trusted identity, and the entire transmission process is encrypted, meeting the Level 3 requirements of the Information Security Protection Scheme 2.0.

[0087] Standardized operation and maintenance: It establishes a sustainable automated pipeline for future equipment replacement and configuration updates.

[0088] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A zero-contact commissioning and automated equipment configuration method, characterized in that, The zero-contact commissioning and automated equipment configuration method includes: Obtain the address information of the intelligent boot server, and establish a connection with the intelligent boot server based on the address information; The intelligent guidance server sends identity credential information to the cloud control plane so that the cloud control plane can perform security authentication on the identity credential information. If the authentication is successful, a corresponding short-term access token is generated and returned. Based on the short-term access token, the device identity and environment information are reported to the policy service of the cloud control plane, so that the policy service generates and returns the corresponding final configuration policy; The final configuration strategy is loaded into the runtime configuration, and a self-test process is executed to generate and report the corresponding self-test results to the cloud control plane.

2. The zero-contact commissioning and automated equipment configuration method according to claim 1, characterized in that, The step of obtaining the address information of the intelligent boot server and establishing a connection with the intelligent boot server based on the address information includes: The system checks if the device is powered on. If it is, it loads the factory default configuration to enter the initial network state and then initializes the wired interface. Based on the wired interface, an address acquisition request is initiated to the external network, wherein the address acquisition request is broadcast based on the DHCP protocol; Receive response messages returned based on the address request in real time; Parse the response message to obtain the corresponding IP address; Obtain the address information of the intelligent boot server, and establish a connection with the intelligent boot server based on the address information and the IP address.

3. The zero-contact commissioning and automated equipment configuration method according to claim 2, characterized in that, The step of obtaining the address information of the intelligent boot server specifically includes: Parse the startup file name or vendor-specific information in the response message to obtain the address information of the smart boot server; Alternatively, the pre-configured DNS domain name in the factory default settings can be called to resolve the DNS domain name and obtain the address information of the smart boot server.

4. The zero-contact commissioning and automated equipment configuration method according to claim 1, characterized in that, The step of sending identity credential information to the cloud control plane through the intelligent boot server, so that the cloud control plane can perform security authentication on the identity credential information, and if the authentication is successful, generating and returning the corresponding short-term access token, includes: The system sends identity credential information to the intelligent boot server to generate a corresponding authentication request, and then forwards the authentication request to the security authentication service of the cloud control plane through the intelligent boot server. Based on the security authentication service, the certificate validity and inventory status of the identity credential information are verified to achieve secure authentication of the identity credential information by the cloud control plane; If authentication is successful, a corresponding short-term access token will be generated and returned based on the inventory status.

5. The zero-contact commissioning and automated equipment configuration method according to claim 4, characterized in that, The identity credentials include a unique device certificate injected during the manufacturing process, and alternative credentials, wherein the alternative credentials are composed of a device serial number, a MAC address, and a one-time factory activation code.

6. The zero-contact commissioning and automated equipment configuration method according to claim 4, characterized in that, Based on the security authentication service, the step of verifying the certificate validity and inventory status of the identity credential information includes: Based on the security authentication service, the certificate validity of the identity credential information is verified, and a corresponding first authentication result is generated. Based on the security authentication service, the pre-stored policy library is invoked to determine whether an inventory status associated with the identity credential information is matched in the policy library, and a corresponding second authentication result is generated. The inventory status includes registration information and a pending deployment status identifier. If both the first authentication result and the second authentication result indicate successful authentication, then the security authentication service is determined to be successful. If the first authentication result and / or the second authentication result indicate authentication failure, then the security authentication service is determined to be an authentication failure.

7. The zero-contact commissioning and automated equipment configuration method according to claim 1, characterized in that, The step of reporting device identity and environment information to the cloud control plane policy service based on the short-term access token, so that the policy service generates and returns the corresponding final configuration policy, includes: Based on the short-term access token, a communication path is established through a secure channel, proxied by the smart bootstrap server. This communication path is used to connect to the policy service of the cloud control plane. Through the communication path, device identity and environment information are reported to the policy service, wherein the environment information includes the IP address obtained by accessing the wired interface, the autonomous system number of the connected operator, the device model and hardware version; Based on the policy service, a corresponding environment context and specific environment variables are generated according to the environment information, wherein the specific environment variables include the service IP range and VPN endpoint address allocated to the site; Based on the policy service, a corresponding policy template is determined from a preset policy library according to the device identity and environmental context. Based on the policy template and the specific environment variables, the corresponding final configuration policy is generated.

8. The zero-contact commissioning and automated equipment configuration method according to claim 7, characterized in that, The step of generating the corresponding final configuration policy based on the policy template and the specific environment variables includes: Based on the configuration template engine in the policy service, a corresponding preliminary configuration policy is rendered and generated according to the policy template and the specific environment variables. The corresponding native format is determined based on the device identity; Based on the original format, the initial configuration strategy is converted to generate the corresponding final configuration strategy.

9. The zero-contact commissioning and automated equipment configuration method according to claim 8, characterized in that, The native formats include CLI scripts, NETCONF / YANG data models, or vendor API call sequences.

10. The zero-contact commissioning and automated equipment configuration method according to claim 7, characterized in that, The step of loading the final configuration strategy into the runtime configuration and executing a self-check process to generate and report the corresponding self-check results to the cloud control plane includes: Verify the syntax logic in the final configuration strategy. If the verification is successful, load the final configuration strategy into the runtime configuration. The self-test process is executed, which includes testing whether the connectivity performance of the core data reaches a preset performance threshold and detecting whether the status information of the key routes reaches a preset status threshold, thereby generating the corresponding self-test results. Based on the cloud control plane, it is determined whether the self-test result indicates that the device has been successfully launched. If the self-test result indicates that the device has been successfully launched, the inventory status in the inventory system is updated, and the configuration version and launch timestamp corresponding to the self-test result are recorded.

Images