Device loading assurance

Abstract

Embodiments of the present disclosure relate to device load assurance. One aspect may provide a system and method for simulating loading of a networked device. During operation, a computing device may obtain a list of networked devices to be loaded into a device management platform method from a device activation platform. For a respective networked device on the list of networked devices, the system may collect hardware and firmware information associated with the respective networked device and use the collected hardware and firmware information to simulate a loading process for the respective networked device, the loading process including exchanging one or more handshake messages with the device activation platform. In response to failing to receive an acknowledgement message from the device management platform indicating that the simulated loading process is successful, the system may perform a diagnostic operation to determine one or more potential issues associated with the loading process of the respective networked device and display a result of the diagnostic operation on the user interface.

Description

Technical Field

[0001] The present disclosure generally relates to methods and systems for onboarding networked devices. More specifically, the present disclosure relates to monitoring and debugging of the onboarding process. BRIEF DESCRIPTION OF THE DRAWINGS

[0002] Figure 1 An example of a device loading scenario according to one aspect of the present application is illustrated.

[0003] Figure 2A An example block diagram of a device activation platform according to one aspect of the present application is illustrated.

[0004] Figure 2B An example block diagram of a device loading simulation system according to one aspect of the present application is illustrated.

[0005] Figure 3 An example of a graphical user interface (GUI) according to one aspect of the present application is presented.

[0006] Figure 4A A flow chart illustrating an example of a loading simulation process according to one aspect of the present application is presented.

[0007] Figure 4B A flowchart illustrating example loading simulation operations performed by a computing device according to one aspect of the present application is presented.

[0008] Figure 5 An example of a computer system that facilitates device loading simulation according to one aspect of the present application is illustrated.

[0009] In the drawings, like reference numerals refer to like drawing elements. DETAILED DESCRIPTION

[0010] The rapid development of cloud computing technology has changed the way people store, access and process data and applications. Instead of relying solely on local servers or personal computing devices, cloud computing uses the power of remote servers and networks to provide a wide range of services through the Internet. In addition to providing storage, computing power and software, cloud computing can also provide Network as a Service (NaaS), allowing organizations to access and configure network resources as needed without owning, maintaining or investing in physical networking hardware and equipment.

[0011] As part of the NaaS solution, device vendors can also provide enterprise users with a cloud-based management platform, so that each enterprise user can use the cloud-based management platform to manage a large number (e.g., hundreds or even thousands) of networked devices. For example, a vendor for wireless local area network (WLAN) equipment (e.g., access points or switches) can provide a centralized network management platform, allowing enterprise users to view and control their networks.

[0012] Enterprise users who use a network management platform to manage networked devices (e.g., access points or switches) should first onboard these networked devices, which can include initial configuration and setup of the networked devices so that they can interact securely with the network management platform. Onboarding networked devices ensures that they have the appropriate permissions and firmware to interact with the network management platform.

[0013] In order to improve the user experience (e.g., reduce the time required to load a networked device), it is desirable to implement zero-touch configuration (ZTP), which can automatically configure a large number of networked devices. The ZTP process can be managed by a device activation platform, which can receive configuration requests from networked devices and then send appropriate configuration files to the networked devices. In addition to providing ZTP, the activation platform can also be responsible for ensuring that the networked device is installed with the correct and latest firmware. For example, when loading a networked device, the device activation platform can first perform a ZTP process to configure the networked device, and then check whether the firmware currently running on the networked device is compatible with the management platform. If so, the activation platform can complete the loading process to allow the device to communicate with the management platform. If the networked device is running incompatible firmware or the device certificate has expired, the networked device cannot establish a connection with the management platform. In such a case, the activation platform can facilitate automatic firmware upgrades on the networked device (e.g., by "pushing" the firmware to the networked device or sending a firmware download link to the networked device). After upgrading the firmware, the networked device can begin to communicate with the management platform, and the loading process is successfully completed. Successful device loading usually results in the management platform sending a confirmation message (e.g., a "welcome" message) to the networked device. Please note that networked devices will not be visible in the Dashboard until they have completed the onboarding process.

[0014] The device loading process can be transparent to the user. From the user's perspective, once the networked device is powered on and connected to the network, it can be coupled to the management platform. However, the loading of networked devices may not always be successful. Many factors may cause device loading failures. For example, problems associated with the user's local network may prevent the correct communication between the device and the activation platform, resulting in ZTP operation failure or interruption. The ZTP service or firmware upgrade service may fail and fail to properly configure the device or upgrade its firmware. In another example, the firmware needs to be upgraded, but the corresponding device image is missing or not linked in the firmware upgrade service. Domain Name System (DNS) failures may also prevent networked devices from obtaining the correct uniform resource locator (URL) of the activation or management platform. There may also be problems with the networked device itself. When a networked device cannot be loaded into the management platform, it may be difficult to find out the exact cause of the failure. To troubleshoot a failed device loading process, the current method is to organize a debugging meeting, which involves multiple technical teams of customers and NaaS providers, such as a team that debugs the device, a team that debugs the activation platform, and a team that debugs the cloud-based management platform. Involve customer participation to provide direct access to networked devices. Such troubleshooting is tedious, especially for customers.

[0015] To reduce the burden on customers, the device onboarding solution described herein can automatically narrow down one or more possible causes of a device onboarding failure in response to the failure. More specifically, the device onboarding simulation system can be implemented to automatically detect and report potential onboarding issues associated with networked devices with reduced customer involvement.

[0016] Figure 1 An example of a device loading scenario according to one aspect of the present application is illustrated. Figure 1 In the example shown, a number of networked devices (including switches 102 and 104 and AP 106) are loaded into a device management platform 108 by a device activation platform 110. More specifically, the networked devices can be coupled to the device management platform 108 and the device activation platform 110 via a local network 112 and the Internet 114. The local network 112 can generally include any type of wired or wireless communication channel capable of coupling computing nodes together. In one example, the local network 112 can include a customer's intranet.

[0017] The device activation platform 110 may include a ZTP service 116 and a firmware service 118. The ZTP service 116 may be responsible for configuring the networked device, loading the device management software and sending the URL of the device management platform 108 to the networked device. The firmware service 118 may be responsible for ensuring that the firmware on each networked device is correct and compatible with the device management platform 108. According to one aspect, the firmware service 118 may check the firmware version currently running on the networked device. If the firmware is not compatible or the device certificate has expired due to firmware expiration, the firmware service 118 may facilitate downloading the latest firmware to the networked device.

[0018] Figure 1 Also illustrated are several potential failure points that may cause a device loading failure, indicated by an "X". Using the loading of the switch 102 as an example, one potential failure point may be a device failure (e.g., a hardware failure) on the switch 102, and another failure point may be a network failure. Note that the network failure may occur in the local network 112, the Internet 114, or both. Possible network failures may include a gateway failure, an address resolution protocol (ARP) failure, or a DNS failure. The ZTP service 116 or the firmware service 118 may also experience a failure, which may include a service or server failure. For example, the ZTP or firmware server may experience a hardware or software failure. Additionally, the device management platform 108 may also experience a hardware or software failure, resulting in a loading failure of the switch 102.

[0019] like Figure 1 As shown, a loading failure of a networked device may be caused by any one or any combination of potential failure points scattered throughout the network (from the customer site to the public cloud-hosted device management platform 108 and the device activation platform 110). Troubleshooting a failed loading process will involve identifying one or more failure points among all possible failure points, which may be challenging, especially considering that a customer may have many networked devices with different hardware configurations and / or firmware versions / builds. According to some aspects of the present application, a device loading simulation system 120 may be deployed at a customer's site to facilitate the customer's identification and correction of potential problems related to the loading of networked devices. According to one aspect, the device loading simulation system 120 may be part of a sidecar monitoring system, which includes several network sensors coupled to a local network 112. According to an alternative aspect, the device loading simulation system 120 may include a standalone application running on a computing device coupled to the local network 112. Since the network sensor or computing device running the application is coupled to the local network 112 and the Internet 114 , the device loading simulation system 120 can detect any potential problems associated with the local network 112 and the Internet 114 .

[0020] According to some aspects of the present application, before a customer attempts to load a networked device, the device loading simulation system 120 can simulate the loading process of the networked device based on various device parameters, such as the loading device type and model, media access control (MAC) address, serial number, firmware version / build, etc. In response to detecting a failure in the simulated loading process, the device loading simulation system 120 can perform a number of troubleshooting operations to identify potential causes of the loading failure. The device loading simulation system 120 can also display the device loading simulation results for a number of networked devices on a user interface.

[0021] To simulate the onboarding of a networked device, the device onboarding simulation system 120 can interact with the device activation platform 110 as if it were a networked device to be onboarded. Each system can include various units for performing different functions associated with device onboarding, and the different units can interact with each other to achieve successful device onboarding.

[0022] exist Figure 1 In the example shown, the device management platform 108 and the device activation platform 110 are shown as separate entities and can run on different computer server systems. In practice, the device management platform 108 and the device activation platform 110 can run on a single server, or can reside in the cloud. The device management platform 108 and the device activation platform 110 can also be integrated into a single system that supports activation and management of networked devices.

[0023] Figure 2A An example block diagram of a device activation platform according to one aspect of the present application is shown. The device activation platform 200 may include a front-end unit 202 , a firmware database 204 , a firmware management unit 206 , a device inventory database 208 , and a ZTP unit 210 .

[0024] The front-end unit 202 can provide a user interface to allow customers to access the device activation platform 200. For example, a customer can log into a user account to check the activation status of a networked device. According to an alternative aspect, the user interface provided by the front-end unit 202 can only be accessed by an administrator of the device activation platform 200.

[0025] The firmware database 204 may store firmware for different devices and various versions. According to one aspect, the firmware database 204 may store firmware for each type / model of networked devices. The stored firmware may include all versions compatible with the device management platform or software system, including the latest version. The firmware management unit 206 may be responsible for checking whether the firmware installed on the networked device matches the device type / model, is up to date, or is compatible with the device management platform. If the firmware on the networked device needs to be upgraded, the firmware management unit 206 may obtain the correct version of the firmware from the firmware database 204 and send the obtained firmware to the networked device.

[0026] The device inventory database 208 can maintain an inventory list for each customer. More specifically, each customer can be associated with a unique customer identifier assigned by the supplier and the device activation platform 200 can use such a unique identifier to identify each customer. When a customer places an order for a networked device, detailed information associated with each ordered device can be added to the device inventory database 208. The device information can include, but is not limited to, the device type (e.g., AP, gateway, switch, router, etc.), the device model, the serial number of the device, the MAC address of the device, the name and version number of the installed firmware, the device activation status, etc. According to some aspects of the present application, a separate system that manages the device ordering process can send the device information to the device inventory database 208 via a representational state transfer (REST) ​​application programming interface (API). Please note that the entry of the purchased networked device has its initial activation state set to "not yet activated". Once successfully activated or loaded, the activation state can be updated to "activated". If the device loading process encounters an error, the activation state can be updated to "load error found".

[0027] The ZTP unit 210 may be responsible for performing standard device onboarding operations. For example, the ZTP unit 210 may receive a request from a networked device to load the networked device into a device management platform. In response to the request, the ZTP unit 210 may exchange a number of handshake messages with the networked device to authenticate the networked device and send appropriate instructions to the networked device to allow the networked device to connect to the management platform. For example, the ZTP unit 210 may provide the URL of the management platform to the networked device.

[0028] Figure 2B An example block diagram of a device loading simulation system 220 according to one aspect of the present application is illustrated. The device loading simulation system 220 may include a front-end unit 222, a device orchestration manager 224, a loading initiation unit 226, a loading problem analysis unit 228, and a packet capture unit 230. When a customer attempts to load a networked device coupled to the same local network, the device loading simulation system 220 may be installed and started by the customer on a computing device coupled to the customer's local network.

[0029] The front end unit 222 may provide a user interface for allowing a customer to access the device loading simulation system 220. Note that a customer account in the device loading simulation system 220 may be associated with a unique customer identifier assigned by a vendor. For example, each customer may establish a user account in the device loading simulation system 220 using a unique customer identifier. According to some aspects, the user interface may be a graphical user interface (GUI) that may facilitate a customer to select a device for simulation. The GUI may also be used to display loading simulation results to the customer.

[0030] The device orchestration manager 224 may be responsible for generating a device orchestration list. According to some aspects, once a customer logs into a customer account, the device orchestration manager 224 may be triggered to send a device query message to the device activation platform 200. According to some aspects, the device query message may include identification information associated with the customer (e.g., user ID and password) to allow the device inventory database 208 within the device activation platform 200 to find a list corresponding to the customer. The list may include records of all networked devices that have been ordered by the customer. Each device record may include device information (e.g., device type, model, MAC address, serial number, firmware version, etc.) and the activation status of the device. In response to the device query message, the device activation platform 200 may send the customer's list to the device orchestration manager 224. The device orchestration manager 224 may then assemble a device orchestration list based on the received device inventory list. The device orchestration list may include devices that have not yet been loaded into (or are not visible to) the management system. In one example, a particular customer's device inventory list may include 50 wireless access points (APs) of different models. Among the 50 APs, 30 APs have been previously activated and are visible to the management platform, and the other 20 APs are to be loaded into the management platform. Therefore, the device orchestration manager 224 can generate a device orchestration list including 20 APs to be loaded. Each entry in the device orchestration list can include detailed information about the device, such as device type, model, MAC address, serial number, firmware version, etc.

[0031] The loading initiation unit 226 can be responsible for initiating the device loading process using the parameters of the networked device in the device orchestration list. More specifically, for each device, the loading initiation unit 226 can exchange a series of handshake messages with the activation platform. According to some aspects, in response to receiving a user command, the loading initiation unit 226 can simulate the loading process of the networked device by sending a loading request message to the ZTP unit within the activation platform. The loading request message can be generated based on the device parameters associated with the simulated device (i.e., the device in the device orchestration list). The loading initiation unit 226 can send the loading request message to the activation platform via the network interface of the computing device hosting the device loading simulation system 220.

[0032] From the perspective of the ZTP unit that receives the onboarding request message, the onboarding process is initiated by a networked device that is almost identical to the simulated device because the two devices are coupled to the same local network and have the same device parameters (e.g., device type, model, MAC address, serial number, firmware version, etc.). Therefore, if the onboarding process initiated by the onboarding-initiating unit 226 is successful, the actual onboarding of the simulated device will also be successful. On the other hand, if the onboarding process initiated by the onboarding-initiating unit 226 encounters a problem (e.g., a network connection problem or a firmware version problem), the actual onboarding of the simulated device will face similar problems.

[0033] If the simulated onboarding process for a particular networked device is successfully completed, the onboarding initiation unit 226 may receive a confirmation message (e.g., a "welcome" message) from the management platform. Depending on the firmware version, the confirmation message may vary from networked device to networked device. According to some aspects, the onboarding initiation unit 226 may perform an onboarding simulation for each networked device in the device orchestration list. For example, if there are 50 devices in the device orchestration list, the onboarding initiation unit 226 may send 50 onboarding request messages to the activation platform. If all onboarding processes are successful, the onboarding initiation unit 226 will receive 50 confirmation messages from the management platform.

[0034] Considering that devices of the same type, model, and firmware version may have similar loading behaviors, according to an alternative aspect, loading simulation may be performed for all different types / models of networked devices and all different firmware versions. For example, if 50 networked devices in the device orchestration list have the same device type / model and run the same firmware version (i.e., they are identical), the loading initiation unit 226 may simulate the loading process only once (e.g., by sending one loading request message to the activation platform), instead of performing 50 device loading simulations for the 50 networked devices. If the simulated loading process is successful, the loading initiation unit 226 may receive one confirmation message from the management platform. In another example, the 50 networked devices may have the same device type / model, but run different firmware versions, with 20 devices running firmware version 1 and the other 30 devices running firmware version 2. Therefore, the loading initiation unit 226 may simulate two loading processes using the same device type / model and two different firmware versions.

[0035] When there are multiple device types / models and multiple firmware versions between the devices to be loaded, the loading initiation unit 226 can group these devices into different groups, wherein each group includes devices with the same type / model and the same firmware version. The loading initiation unit 226 can simulate the loading process for each group based on the device type / model and the firmware version.

[0036] According to some aspects, the onboarding initiating unit 226 can initiate the onboarding process for multiple devices in succession, which means that the onboarding initiating unit 226 can perform the onboarding simulation for one device at a time. For example, the onboarding initiating unit 226 can send an onboarding request message for one networked device in the device orchestration list and wait for a confirmation message from the management platform. After the confirmation message is received or after the predetermined time interval for receiving the confirmation message expires, the onboarding initiating unit 226 will send an onboarding request message for a different networked device in the device orchestration list.

[0037] According to an alternative aspect, the onboarding initiating unit 226 can initiate the onboarding process for multiple networked devices in parallel, which means that the onboarding initiating unit 226 can perform onboarding simulations on multiple devices at the same time. For example, the onboarding initiating unit 226 can simultaneously send multiple onboarding request messages corresponding to multiple devices on the device orchestration list to the device activation platform.

[0038] The loading problem analysis unit 228 may be responsible for analyzing one or more potential causes of the loading failure. When the loading initiation unit 226 fails to receive a confirmation message corresponding to the loading process after a predetermined time interval (e.g., a few seconds), the loading initiation unit 226 may send a loading failure message and device information associated with the device experiencing the failure to the loading problem analysis unit 228. According to some aspects, in response to receiving the loading failure message, the loading problem analysis unit 228 may perform a series of diagnostic tests based on the received device information (e.g., device model and firmware version).

[0039] According to some aspects, the series of diagnostic tests may include at least a local network connection test, a gateway reachability test, an ARP test, a DNS test, a firmware test, a protocol test, a management platform test, and the like.

[0040] To test the local network connection, the loading problem analysis unit 228 can determine whether the computing device running the device loading simulation application is able to obtain a valid Internet Protocol (IP) address. Failure to obtain a valid IP address can indicate that the local network is experiencing connectivity issues or that there is a problem with the network interface of the computing device. Additional problems associated with the local network may be caused by a failure of the default gateway router of the local network. The loading problem analysis unit 228 can also determine whether the default gateway is reachable and / or whether the ARP server for the default gateway is functioning properly.

[0041] The loading problem analysis unit 228 can also perform a DNS test by determining whether the DNS resolution for the activation platform and the management platform is successful. According to one aspect, the loading problem analysis unit 228 can apply a DNS check tool to the URLs of the activation platform and the management platform. The loading problem analysis unit 228 can also determine whether the DNS server in the network is operating normally.

[0042] The loading problem analysis unit 228 can determine whether the firmware currently installed in the simulated device matches the device type / model and is compatible with the management platform. If the firmware is not compatible (e.g., it does not meet the minimum requirements), the loading problem analysis unit 228 can also check whether the firmware repository (e.g., the firmware database 204 in the device activation platform 200) can provide the required firmware upgrade to the networked device (i.e., whether the networked device can access the firmware repository and download the firmware upgrade).

[0043] If the device passes the firmware test (i.e., it has the correct firmware version or the firmware upgrade is successful), the loading problem analysis unit 228 can perform a protocol test to determine whether there is a protocol error in the activation platform. More specifically, the loading problem analysis unit 228 can determine whether the correct URL for the management platform is provided to the device.

[0044] The loading problem analysis unit 228 can also determine whether the management platform is running normally. In one example, the loading problem analysis unit 228 can ping the server hosting the management platform. In another example, the loading problem analysis unit 228 can use the hardware / firmware parameters of the computing device running the device loading simulation application to send a loading request message to check whether it can receive a confirmation message.

[0045] The loading problem analysis unit 228 can summarize the results of a series of diagnostic tests to determine the root cause of the loading failure. In most cases, the loading failure may be caused by a single reason (e.g., DNS or ARP errors, inability to upgrade firmware, local network failure, server failure of the activation or management platform, etc.). In some cases, there may also be multiple reasons that lead to the loading failure. In some embodiments, each specific reason that may cause the loading failure can be mapped to a unique loading problem identifier (ID) that can be presented to the customer. In one example, the loading problem ID can be a number. In another example, a three-digit number (e.g., 001, 002, etc.) can be used to represent a specific loading problem ID.

[0046] The packet capture unit 230 may be responsible for capturing packets sent and received by the device onboarding simulation system 200 during the onboarding simulation process. According to some aspects, the onboarding problem analysis unit 228 may also perform analysis on the captured packets when determining the root cause of the onboarding failure. For example, a response packet from the management platform may indicate that the management platform has encountered some failures. According to further aspects, the packet capture unit 230 may apply several filters (e.g., filters based on the destination address) to ensure that it only captures packets associated with the onboarding process (including a series of diagnostic tests). The captured packets may be packaged together with the diagnostic test results for presentation to the customer.

[0047] Figure 3 An example of a graphical user interface (GUI) according to one aspect of the present application is illustrated. The device loading simulation user interface 300 may include a device table 302 , a simulate all devices button 304 , and a simulate selected devices button 306 .

[0048] The device table 302 may include several entries, each of which corresponds to a networked device to be loaded. Each table entry may include information related to the device hardware (e.g., device serial number, device type / model, device MAC address, etc.) and information related to the device firmware (e.g., firmware version).

[0049] The customer may select a number of networked devices for onboarding simulation and click button 306 to simulate the onboarding process for the selected networked devices. Alternatively, the customer may click button 304 to simulate the onboarding process for all networked devices in device table 302. As previously described, the simulation may be performed for each individual networked device or each group of identical networked devices (i.e., networked devices with the same device type / model and firmware version). When simulating device onboarding, the simulation system may sequentially send an onboarding request message for each device or each group of identical devices to the activation platform.

[0050] The device onboarding simulation results can be presented for each networked device in table 302. According to some aspects, the simulation results can indicate whether the networked device passes the onboarding test. More specifically, if the onboarding process simulated for the specific networked device can result in a confirmation message from the management platform, the specific networked device is said to have passed the onboarding test. If the networked device fails the onboarding test (for example, no confirmation message is received after a predetermined timeout period), the simulation results can include one or more onboarding problem IDs associated with the failed onboarding test. Figure 3 In the example shown, the simulation results displayed for a failing test may also provide the customer with a link to download a detailed load failure report that includes an analysis of the root cause of the load failure and may also include the captured packets.

[0051] Figure 4A A flow chart illustrating an example of an onboarding simulation process according to one aspect of the present application is presented. During operation, a customer orders a number of networked devices (operation 402). Device parameters for the ordered networked devices may be sent to a device activation platform and added to a device inventory list for the customer in a device inventory database maintained by the device activation platform (operation 404). Each device record may include information about the device hardware (e.g., type and model, serial number, MAC address, etc.) and information about the firmware installed on the device (e.g., version number).

[0052] These networked devices may be deployed to the customer's local network. Before loading the networked devices into the management platform, the customer may wish to test whether the networked devices can be successfully loaded and perform necessary diagnostic tests when one or more networked devices encounter a loading failure. To this end, the customer may install and start a device loading simulation system on a computing system within the same local network as those networked devices to be loaded (operation 406). For example, the customer may install the device loading simulation system on a personal computer (PC) or a laptop computer, which is coupled to the same local network where the networked devices to be loaded are deployed.

[0053] The device onboarding simulation system may then access the device activation platform to obtain a device inventory list and generate a device orchestration list (operation 408). The device orchestration list may include networked devices to be onboarded by the customer and may be displayed on a user interface to allow the customer to select a number of networked devices for onboarding simulation. According to one aspect, the networked devices to be onboarded may be grouped based on device type / model and firmware version. Networked devices of the same type and model and with the same firmware version installed may be grouped together.

[0054] The customer may input a user command for performing a loading simulation (operation 410). For example, the customer may click button 304 or button 306 in the device loading simulation user interface 300 to initiate a simulation of a loading process for all networked devices or selected networked devices, respectively. In response to the user command, the simulation system may perform a device loading simulation (operation 412) using various parameters associated with the simulated device. For example, the simulation system may send a series of loading request messages to the activation platform to exchange handshake messages with the loading request system. Each loading request message may correspond to a networked device or a group of networked devices of the same type / model and firmware version. The loading request message may include information related to the device hardware (e.g., type / model, serial number, MAC address, etc.) and information related to the device firmware (e.g., firmware version).

[0055] For each simulated loading process, the simulation system can determine whether the loading is successful (operation 414). More specifically, the simulation system can determine whether a confirmation message responding to a specific loading request message can be received from the management platform within a predetermined time interval. If so, the specific loading simulation is considered successful, and the simulation system displays the result in the GUI (operation 416). If the specific loading simulation fails, the simulation system can perform a series of diagnostic tests (operation 418). Diagnostic tests may include, but are not limited to, local network connection tests, gateway reachability tests, tests on ARP servers, tests on DNS servers, tests on whether firmware upgrades are available when needed, tests on whether the activation platform contains protocol errors, tests on whether the management platform encounters failures, etc. According to some aspects, performing diagnostic tests may include sending query packets to a default gateway, an ARP server, a DNS server, an activation platform, a management platform, etc. Performing diagnostic tests may also include capturing packets associated with the simulated loading process and diagnostic tests.

[0056] The simulation system may further analyze the results of the diagnostic test and the captured packets to identify one or more possible causes of the loading failure (operation 420). The simulation system may then display the results of the fault analysis in the GUI (operation 416). According to some aspects of the present application, each cause (e.g., local network connection problem, DNS problem, ARP problem, firmware server problem, activation server problem, management server problem, etc.) may be mapped to a loading problem ID, which is displayed in the GUI. According to further aspects, the GUI may also provide a link for allowing the customer to download a detailed fault report file, which includes the fault analysis and the captured packets.

[0057] If the onboarding simulation for a specific networking device is successful, the customer can then perform the actual onboarding of the networking device (i.e., turning on the device and connecting it to the network). Note that if the actual onboarding fails, it is likely that the networking device has a faulty component (e.g., a faulty network interface card). If the onboarding simulation for a specific networking device is unsuccessful, the customer can take remedial actions based on the fault report. For example, the fault may be caused by the inability to obtain a correct firmware upgrade, and the customer can contact the device vendor to request the upgrade file. If the fault is caused by connectivity issues in the local network, the customer will need to fix these connectivity issues before onboarding the networking device. Similarly, for ARP or DNS issues, the customer may need to resolve these issues before onboarding the networking device.

[0058] Figure 4B A flowchart illustrating an example onboarding simulation operation performed by a computing device according to one aspect of the present application is presented. During operation, the computing device may obtain a list of networked devices to be onboarded to the device management platform from a device activation platform (operation 422). The device activation platform may use various methods to collect customer inventory information. In one example, the device activation platform may receive a report from a centralized device purchasing system that tracks all networked devices purchased by a customer. The report may specify a customer identifier, a type / model of the device, a serial number and MAC address of the device, a version of firmware / software installed on the device, and the like. In another example, the device activation platform may also receive customer inventory information from the customer.

[0059] For a corresponding networked device on the list of networked devices, the computing device may collect hardware and firmware information associated with the corresponding networked device (operation 424). In one example, the computing device may maintain a list of networked devices to be loaded and collecting hardware and firmware information associated with the networked device may include performing a lookup based on a serial number of the networked device.

[0060] The computing device may use the collected hardware and firmware information to simulate a loading process of the corresponding networked device, including exchanging one or more handshake messages with the device activation platform (operation 426). For example, the computing device may send a loading request message to the device activation platform on behalf of the networked device.

[0061] In response to failing to receive a confirmation message from the device management platform indicating that the simulated onboarding process was successful, the computing device may perform a diagnostic operation to determine one or more potential issues associated with the onboarding process of the corresponding networked device (operation 428). The computing device may also display the results of the diagnostic operation on a user interface (operation 430).

[0062] although Figure 4A-4B The example process in the flowchart shows a specific order in which certain operations are performed, but the method is not limited to such an order. For example, the operations shown continuously in the flowchart can be performed in different orders, can be performed simultaneously, or some of them can be performed concurrently, or according to the above combination.

[0063] Figure 5 An example of a computer system that facilitates device loading simulation according to one aspect of the present application is illustrated. Computer system 500 may include a processor 502, a memory 504, and a storage device 506. In addition, computer system 500 may be coupled to peripheral input / output (I / O) user devices 510, such as a display device 512, a keyboard 514, and a pointing device 516. Storage device 506 may store an operating system 518, a device loading simulation system 520, and data 540.

[0064] The device loading simulation system 520 may include instructions that, when executed by the computer system 500, may cause the computer system 500 or the processor 502 to perform the methods and / or processes described in the present disclosure. Specifically, by executing these instructions, the computer system 500 can achieve the goal of simulating the device loading process for many networked devices and identifying the most likely cause of the loading failure. The device loading simulation system 520 may include instructions for implementing a front end (front end implementation instructions 522), instructions for generating a device orchestration list based on a device inventory list maintained by a device activation platform (device orchestration instructions 524), instructions for simulating the device loading process for multiple devices or multiple device groups (device loading simulation instructions 526), ​​instructions for troubleshooting the loading process in the event of a loading failure (device loading troubleshooting instructions 528), instructions for capturing network packets during the loading simulation (packet capture instructions 530), and instructions for displaying simulation results (simulation result display instructions 532). The data 540 may include a device orchestration list 542.

[0065] In general, the present disclosure describes a mechanism for simulating the loading process of networked devices. More specifically, before actually loading networked devices (e.g., APs, gateways, switches, routers, etc.) into a device management platform provided by a device vendor, a customer can start a device loading simulation application on a computing device (e.g., a PC or laptop) within a customer's local network. The device loading simulation application can obtain a list of networked devices purchased by a customer and generate an orchestration device list including multiple devices to be loaded. Each entry in the orchestration device list corresponds to a networked device to be loaded and can include information related to the device hardware (e.g., device type and model, serial number, MAC address, etc.) and information related to the device firmware (e.g., firmware version). For each device or each device group with a unique combination of device model and firmware version, the device loading simulation application can use the device hardware and firmware information to simulate the device loading process. The device loading simulation application can exchange handshake messages with the device activation platform on behalf of each simulated device or device group. A successful simulation can cause the device management platform to send a confirmation message to the device loading simulation application. If such a confirmation message is not received after a predetermined time interval, the simulation will be deemed to have failed. In response to a failed loading simulation, the device loading simulation application can perform a series of diagnostic tests (e.g., connection tests in the local network, ARP tests, DNS tests, firmware tests, tests on the server, etc.) and analyze the test results to identify the most likely cause of the loading failure. The device loading simulation application can provide a fault analysis to the customer via a GUI. The device loading simulation application can also be connected to a packet capture application to capture a large number of network packets associated with the loading simulation process (including the troubleshooting process). The captured network packets can also be analyzed together with the diagnostic test results to enhance the accuracy of the diagnosis. Please note that if the loading process simulated for the networked device is successful, but the networked device encounters a loading failure, the loading failure is likely caused by a hardware component failure (e.g., a network interface card or NIC failure) on the networked device.

[0066] One aspect of the present application may provide a system and method for simulating the loading of a networked device. During operation, a computing device may obtain a list of networked devices to be loaded into a device management platform method from a device activation platform. For a corresponding networked device on the list of networked devices, the system may collect hardware and firmware information associated with the corresponding networked device and use the collected hardware and firmware information to simulate the loading process of the corresponding networked device, the loading process including exchanging one or more handshake messages with the device activation platform. In response to failing to receive a confirmation message from the device management platform indicating that the simulated loading process was successful, the system may perform a diagnostic operation to determine one or more potential problems associated with the loading process of the corresponding networked device and display the results of the diagnostic operation on a user interface.

[0067] In variations of this aspect, the hardware information may include one or more of: device type; device model; serial number; and media access control (MAC) address.

[0068] In a variation of this aspect, the firmware information includes a firmware version number.

[0069] In a variation of this aspect, the system may select a subset of networking devices from a list of networking devices to be onboarded and simulate the onboarding process of the selected subset of networking devices.

[0070] In a further variation, simulating the onboarding process of the selected subset of networked devices may include sequentially sending a set of onboarding request messages corresponding to the selected subset of networked devices to the device activation platform.

[0071] In a further variation, simulating the onboarding process of the selected subset of networked devices may include sending a set of onboarding request messages corresponding to the selected subset of networked devices to the device activation platform in parallel.

[0072] In a variation of this aspect, performing the diagnostic operation includes performing a series of tests, the tests including one or more of the following: a connectivity test on a local network to which the networked device is coupled; a reachability test on a default gateway of the local network; a test on an address resolution protocol (ARP) server; a test on a domain name system (DNS) server; a test on whether a firmware upgrade is available; a test on whether a device activation platform contains a protocol error; and a test on whether a device management platform has encountered a failure.

[0073] In further variations, performing the diagnostic operation may also include capturing incoming and outgoing communication packets during the diagnostic operation.

[0074] In further variations, determining one or more potential problems may include analyzing results of a series of tests and captured communication packets.

[0075] The terms used herein are only used to describe examples and are not intended to be limiting. Unless the context clearly states otherwise, as used herein, the singular forms "a", "an" and "the" are also intended to include plural forms. The term "multiple" used herein is defined as two or more than two. It should also be understood that although the terms first, second, etc. may be used herein to describe various elements, unless otherwise stated or the context states otherwise, these elements should not be limited by these terms because these terms are only used to distinguish one element from another element. As used herein, the term "includes" means including but not limited to, and the term "including" means including but not limited to. The term "based on" means at least partially based on.

[0076] The above description is presented to enable any person skilled in the art to make and use the examples and is provided in the context of a specific application and its requirements. Various modifications to the disclosed examples will be apparent to those skilled in the art and the general principles defined herein may be applied to other implementations and applications without departing from the spirit and scope of the present disclosure. Therefore, the scope of the present disclosure is not limited to the examples shown, but should be given the broadest scope consistent with the principles and features disclosed herein.

[0077] The methods and processes described in the detailed description section may be embodied as code and / or data, which may be stored in a computer-readable storage medium as described above. When a computer system reads and executes the code and / or data stored on a computer-readable storage medium, the computer system executes the methods and processes embodied as data structures and codes and stored in a computer-readable storage medium. A computer-readable storage medium may be any electronic, magnetic, optical, or other physical storage device that contains or stores information such as executable instructions, data, and the like. For example, any computer-readable storage medium described herein may be any one of RAM, EEPROM, volatile memory, non-volatile memory, flash memory, storage drive devices (e.g., HDD, SSD), any type of storage disk (e.g., optical disk, DVD, etc.), or a combination thereof. In addition, any computer-readable storage medium described herein may be non-transitory.

[0078] In addition, the above methods and processes may be included in hardware devices or apparatuses. Hardware devices or apparatuses may include, but are not limited to, application specific integrated circuit (ASIC) chips, field programmable gate arrays (FPGAs), dedicated or shared processors that execute specific software units or code segments at specific times, and other programmable logic devices now known or later developed. When the hardware devices or apparatuses are activated, they will execute the methods and processes included therein.

[0079] The description of the foregoing examples is for illustration and description purposes only. They are not intended to be exhaustive or to limit the scope of the present disclosure to the disclosed forms. Therefore, many modifications and variations are apparent to those skilled in the art.

Claims

1. A method comprising: Obtaining, by the computing device, a list of networked devices to be loaded into the device management platform from the device activation platform; For a corresponding networked device on the networked device list, collecting hardware information and firmware information associated with the corresponding networked device; Using the collected hardware information and firmware information, simulating a loading process of the corresponding networked device, the loading process comprising exchanging one or more handshake messages with the device activation platform; In response to failing to receive a confirmation message from the device management platform indicating that the simulated onboarding process was successful, performing diagnostic operations to determine one or more potential issues associated with the onboarding process of the respective networked device; as well as The results of the diagnostic operation are displayed on a user interface.

2. The method according to claim 1, wherein the device activation platform is to access a centralized device purchasing system that tracks networked devices purchased by customers to obtain inventory information associated with each customer; and Wherein obtaining the list of networked devices to be loaded includes accessing the inventory information associated with the client.

3. The method according to claim 1, The hardware information includes one or more of the following: Type of device; Device model; Serial number; and Media Access Control (MAC) address; and The firmware information includes a firmware version number.

4. The method according to claim 1, further comprising: selecting a subset of networked devices from said list of networked devices to be loaded; as well as The loading process of the selected subset of the networked devices is simulated.

5. The method of claim 4, wherein simulating the onboarding process of the selected subset of the networked devices comprises: A set of onboarding request messages corresponding to the selected subset of network-connected devices are sent in sequence to the device activation platform.

6. The method of claim 4, wherein simulating the onboarding process of the selected subset of the networked devices comprises: A set of onboarding request messages corresponding to the selected subset of network-connected devices are sent in parallel to the device activation platform.

7. The method of claim 1 , wherein performing the diagnostic operation comprises performing a series of tests, the series of tests comprising one or more of the following: Testing the connection of the local network to which the networked device is coupled; Reachability test of the default gateway of the local network; Testing of the Address Resolution Protocol (ARP) server; Testing of Domain Name System DNS servers; Testing whether firmware upgrades are available; Testing whether the device activation platform contains protocol errors; as well as A test of whether the device management platform encounters a failure.

8. The method of claim 7, wherein performing the diagnostic operation further comprises: During the diagnostic operation, incoming and outgoing communication packets are captured.

9. The method of claim 8, wherein determining the one or more potential issues comprises: The results of the series of tests and the captured communication packets are analyzed.

10. A computer system comprising: processor; as well as A storage device storing instructions, which, when executed by the processor, cause the processor to perform a method, the method comprising: Obtaining a list of networked devices to be loaded into the device management platform from the device activation platform; For a corresponding networked device on the networked device list, collecting hardware information and firmware information associated with the corresponding networked device; Using the collected hardware information and firmware information, simulating a loading process of the corresponding networked device, the loading process comprising exchanging one or more handshake messages with the device activation platform; In response to failing to receive a confirmation message from the device management platform indicating that the simulated onboarding process was successful, performing diagnostic operations to determine one or more potential issues associated with the onboarding process of the respective networked device; and The results of the diagnostic operation are displayed on a user interface.

11. The computer system according to claim 10, wherein the device activation platform is to access a centralized device purchasing system that tracks networked devices purchased by customers to obtain inventory information associated with each customer; and Wherein obtaining the list of networked devices to be loaded includes accessing the inventory information associated with the client.

12. The computer system according to claim 10, The hardware information includes one or more of the following: Type of device; Device model; Serial number; and Media Access Control (MAC) address; and The firmware information includes a firmware version number.

13. The computer system of claim 10, wherein the method further comprises: selecting a subset of networked devices from said list of networked devices to be loaded; as well as The loading process of the selected subset of the networked devices is simulated.

14. The computer system of claim 13, wherein simulating the loading process of the selected subset of the networked devices comprises: A set of onboarding request messages corresponding to the selected subset of network-connected devices are sent in sequence to the device activation platform.

15. The computer system of claim 13, wherein simulating the loading process of the selected subset of the networked devices comprises: A set of onboarding request messages corresponding to the selected subset of network-connected devices are sent in parallel to the device activation platform.

16. The computer system of claim 10, wherein performing the diagnostic operation comprises performing a series of tests, the series of tests comprising one or more of the following: Testing the connection of the local network to which the networked device is coupled; Reachability test of the default gateway of the local network; Testing of the Address Resolution Protocol (ARP) server; Testing of Domain Name System DNS servers; Testing whether firmware upgrades are available; Testing whether the device activation platform contains protocol errors; as well as A test of whether the device management platform encounters a failure.

17. The computer system of claim 16, wherein performing the diagnostic operation further comprises: During the diagnostic operation, incoming and outgoing communication packets are captured.

18. The computer system of claim 17, wherein determining the one or more potential issues comprises: The results of the series of tests and the captured communication packets are analyzed.

19. A non-transitory computer-readable storage medium storing instructions which, when executed by a processor, cause the processor to perform a method comprising: Obtaining a list of networked devices to be loaded into the device management platform from the device activation platform; For a corresponding networked device on the networked device list, collecting hardware information and firmware information associated with the corresponding networked device; Using the collected hardware information and firmware information, simulating a loading process of the corresponding networked device, the loading process comprising exchanging one or more handshake messages with the device activation platform; In response to failing to receive a confirmation message from the device management platform indicating that the simulated onboarding process was successful, performing diagnostic operations to determine one or more potential issues associated with the onboarding process of the respective networked device; as well as The results of the diagnostic operation are displayed on a user interface.

20. The non-transitory computer-readable storage medium of claim 19, wherein performing the diagnostic operation comprises performing a series of tests, the series of tests comprising one or more of the following: Testing the connection of the local network to which the networked device is coupled; Reachability test of the default gateway of the local network; Testing of the Address Resolution Protocol (ARP) server; Testing of Domain Name System DNS servers; Testing whether firmware upgrades are available; Testing whether the device activation platform contains protocol errors; as well as A test of whether the device management platform encounters a failure.

Images