Seamless automation of network device migration to and from cloud management systems

Abstract

The present technology relates to an automated end-to-end network migration process from a locally deployed management platform to a cloud-based management platform (or vice versa). The disclosed technology describes an enhanced Plug and Play (PnP) software agent that is operatively coupled to a device and is capable of interacting with a PnP service hosted on a target management platform to initiate a migration process. Upon receiving a migration request from the device PnP agent, the PnP service on the target management platform maps the requesting device to a client profile present on the target management platform and identifies an associated default controller for the device based on the client profile. Subsequently, the device is directed to obtain and boot in accordance with a new software image that is compatible with the target management platform, and after converting the device's existing configuration to a version compatible with the new software image, the device is migrated to the associated default controller.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of and priority to U.S. non-provisional patent application No. 16 / 399,304, filed on April 30, 2019, entitled “SEAMLESS AUTOMATION OF NETWORK DEVICE MIGRATION TO AND FROM CLOUD MANAGED SYSTEMS,” and claims the benefit of U.S. provisional patent application No. 62 / 770,087, filed on November 20, 2018, entitled “SEAMLESS AUTOMATION OF NETWORK DEVICE MIGRATION TO AND FROM CLOUD MANAGED SYSTEMS,” the entire contents of which are incorporated herein by reference. Technical Field

[0003] The present technology relates to systems and methods for managing network devices. More specifically, the present technology relates to automated cross-platform migration of network devices. Background Art

[0004] The simplicity, ease of use, and manageability of cloud-based networking systems have driven the networking industry to increasingly adopt cloud-managed networking solutions. One challenge facing the industry involves seamlessly converting a large number of conventionally deployed networking devices to cloud-managed networking products. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] In order to describe the manner in which the above-mentioned and other advantages and features of the present disclosure can be obtained, a more particular description of the principles briefly described above will be presented, which is carried out by reference to specific embodiments thereof shown in the accompanying drawings. Under the understanding that these drawings depict only exemplary embodiments of the present disclosure and are therefore not to be considered limiting of its scope, the principles of the present invention are described and explained with additional specificity and detail through the use of the accompanying drawings, in which:

[0006] Figure 1 illustrates an example user interface for initiating a platform migration of a network device according to some embodiments of the present technology;

[0007] Figure 2 illustrates an example process flow for end-to-end automation of network migration to and from a cloud management platform in accordance with some embodiments of the present technology;

[0008] Figure 3shows an example cloud platform user interface for managing a migration process according to some embodiments of the present technology;

[0009] Figure 4 A flow chart illustrating an example workflow related to seamless automation of a device migration process to and from a cloud management platform in accordance with some embodiments of the present technology;

[0010] Figure 5 illustrates an example of a physical topology of an enterprise network according to some embodiments of the present technology;

[0011] Figure 6 An example of a logical architecture for an enterprise network according to some embodiments of the present technology is shown;

[0012] Figure 7 shows an example of a physical topology for a multi-site enterprise network according to some embodiments of the present technology;

[0013] Figure 8 An example network device according to some embodiments of the present technology is shown;

[0014] Fig. 9 An example architecture of a computing device in accordance with some embodiments of the present technology is shown. DETAILED DESCRIPTION

[0015] Various example embodiments of the present disclosure are discussed in detail below. Although specific implementations are discussed, it should be understood that this is done for illustrative purposes only. Those skilled in the relevant art will recognize that other components and configurations may be used without departing from the spirit and scope of the present disclosure. Therefore, the following description and drawings are illustrative and should not be interpreted as limiting. Many specific details are described to provide a thorough understanding of the present disclosure. However, in some cases, in order to avoid making the description unclear, well-known or conventional details are not described. References to an embodiment or an embodiment in the present disclosure may be references to the same embodiment or any embodiment; and such references mean at least one embodiment.

[0016] Reference to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The phrase "in one embodiment" appearing in various places in the specification is not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. In addition, various features are described that may be exhibited by some embodiments and not by others.

[0017] The terms used in this specification, in the context of the present disclosure, and in the specific context in which each term is used, generally have their ordinary meaning in the art. For one or more terms discussed herein, alternative language and synonyms can be used, and special meanings should not be applied to whether the term is described or discussed in detail herein. In some cases, synonyms for certain terms are provided. The recording of one or more synonyms does not exclude the use of other synonyms. The use of examples (including examples of any terms discussed herein) anywhere in this specification is only illustrative, and is not intended to further limit the scope and meaning of the present disclosure or any example terms. Similarly, the present disclosure is not limited to the various embodiments given in this specification.

[0018] Without intending to limit the scope of the present disclosure, examples of tools, devices, methods and related results thereof according to embodiments of the present disclosure are given below. Note that, for the convenience of the reader, titles or subtitles may be used in the examples, which should never limit the scope of the present disclosure. Unless otherwise defined, the technical and scientific terms used herein have the meanings commonly understood by those of ordinary skill in the field to which the present disclosure belongs. In the event of a conflict, this document (including definitions) shall prevail.

[0019] Additional features and advantages of the present disclosure will be set forth in the following description, and in part will be apparent from the description, or may be learned by practicing the principles disclosed herein. The features and advantages of the present disclosure may be realized and obtained by the tools and combinations particularly pointed out in the appended claims. These and other features of the present disclosure will become more apparent from the following description and the appended claims, or may be learned by practicing the principles set forth herein.

[0020] Overview

[0021] Various aspects of the invention are set out in the independent claims, and preferred features are set out in the dependent claims. Features of one aspect may be applicable to each aspect alone or in combination with other aspects.

[0022] Systems, methods, and computer-readable media are disclosed for seamless automation of network migration between on-premise systems and cloud-managed systems.

[0023] In some aspects of the present technology, a method includes: receiving, by a first server hosted on a first management platform, a migration request associated with an identifier of a device hosted on a second management platform. The method also includes: mapping the identifier to a client account on the first management platform; and directing the device to boot up according to a software image provided by the second server on the first management platform. In addition, the method includes: updating, by the first server, an existing configuration of the device to be compatible with the software image provided by the second server; and migrating the device to a host controller identified by the client account on the first management platform.

[0024] Detailed Description

[0025] As cloud-managed networking becomes more prevalent, many networking vendors are faced with the challenge of expending time and resources to migrate an existing number of on-premises managed or legacy (BROWNFIELD) devices to a cloud-based platform. Traditional methods for performing cloud-based platform migrations for legacy network devices include performing a manual download of the relevant software and device image files, and then manually converting the existing device configuration (i.e., the input configuration) to the cloud-recommended version (i.e., the output configuration). This is a time-consuming process requiring multiple manual steps that increase the complexity and turnaround time of the task. Furthermore, manually modifying the configuration of on-premises managed devices to achieve cloud compatibility (or vice versa) is prone to human error and requires a level of expertise and experience, which are themselves limited and valuable resources.

[0026] An alternative approach that significantly reduces the turnaround time (and required effort / expertise and complexity associated with performing network migrations between different management platforms) can be very beneficial to network vendors and end users alike. Accordingly, some aspects of the present technology disclose a robust, efficient, and fully automated mechanism for seamlessly migrating networked devices from a locally deployed system to a cloud-managed system (and vice versa) in an operationally flexible manner that significantly reduces the associated complexity and turnaround time.

[0027] A fully automated process for facilitating bidirectional network migration between a locally deployed network management platform and a cloud-based network management platform (as described in accordance with some embodiments of the present technology) significantly minimizes the involvement of end users in the migration process. According to some embodiments of the present technology, this can be achieved by enabling the device to communicate the migration intent to the cloud using an embedded software component (e.g., a Plug and Play (PnP) agent), which can be installed on the device or operationally coupled to the device. The user can communicate / interact with the PnP software agent using a CLI wrapper, which is an executable command line wrapper for enabling communication with the PnP software agent on the network device using, for example, one or more CLI commands. For example, the PnP (software) agent can receive a user-provided CLI command through the CLI wrapper for migration to a cloud host. This can trigger the process of the PnP agent initiating an initial discovery and connecting to an onboarding cloud server. After finding cloud access server (that is, Cisco PnP redirect server) and setting up connection, PnP agent can send conversion or migration request to initiate migration process to the access server of cloud hosting.In this way, migration process can be initiated in response to simple CLI command input from user.

[0028] The PnP software agent functions may include: initiating a connection to a cloud access server (after an initial discovery phase), and sending a migration request to the cloud access server to initiate a cloud migration process. The PnP agent may be initialized in response to a CLI command provided by a provider for a user through a CLI wrapper. In addition, a web user interface for configuration management may be enhanced to support a CLI wrapper so that a user can simply initiate a migration process from a web user interface with a single action (i.e., clicking a button). The PnP agent may also be triggered to initiate a migration process by a mobile application having, for example, a graphical user interface and a wireless connection (i.e., Bluetooth). The mobile application may then communicate with the network device and initiate the migration process via the CLI wrapper. Figure 1 An example user interface 100 associated with the Cisco Plug and Play Cloud Portal for device migration is shown. In the example user interface 100, the migration request specified by the user selection corresponding to field 102 involves a conversion from an on-premises managed network device (i.e., Cisco's Viptela ISR device) to a cloud-managed network device (i.e., a cloud-based cEdge device).

[0029] According to some embodiments of the present technology, an existing software component of a device (i.e., a device agent) can be enhanced to periodically save the device's running configuration to a secure location that will not be erased by a factory reset. In addition, the (enhanced) device agent can replace the configured configuration files associated with the existing controller / management server with a configuration file that identifies the cloud-hosted onboarding server. According to some embodiments, an enhanced (PnP) device agent associated with a network device can automatically trigger a connection request to a cloud onboarding server when the device is reset (i.e., when recovering from a reset operation). In this case, a single, user-initiated device reset operation will automatically generate a connection request to the cloud.

[0030] Referring to the described scenario, if a connection request is not followed by a migration request, the network administrator / operator may need to mark the device for migration using the appropriate cloud service (i.e., the onboarding server) on the target platform. The onboarding server can then verify (based on, for example, the device serial number) whether the connecting device is marked for migration using the cloud service before initiating the migration process in response to a communication from a particular device.

[0031] Another feature of the fully automated bi-directional network migration process as disclosed in some embodiments of the present technology relates to automatically obtaining necessary information to facilitate the cloud migration process. Information acquisition is based on the successful association of the device to be migrated with, for example, an account profile of an existing cloud-based client / network. Identifying the client account associated with the requesting device enables the access server to obtain information, such as the default, cloud-based controller / management server for the client / organization, and the recommended cloud-compatible software image that may be specified in the client's account profile. If the device information provided (i.e., the device serial number) does not match an existing client account, the device's source IP address can be used to identify the relevant cloud-based device from existing cloud-managed devices (i.e., a previously migrated device that belongs to the same network / organization as the device to be migrated).

[0032] According to some embodiments of the present technology, by mapping device information to one or more client records in, for example, an account database (i.e., a Cisco Smart Account database), a cloud-based onboarding server can identify a default, cloud-based host and cloud-compatible software image for a requesting device. If a device is successfully mapped to an existing client account, information that may be needed for automated cloud deployment can be obtained, such as a default cloud-based host controller for hosting a particular device and a cloud-recommended device software image.

[0033] According to some embodiments of the present technology, in the event that a device identifier (i.e., serial number) is not successfully mapped to an existing client account, the onboarding server can check the source IP of the device (to be migrated) and search for devices originating from the same network / organization in the inventory of existing cloud-based devices based on a comparison of the source IP. If such a match is found, the necessary information can be obtained from the matching client / organization account (i.e., client smart account) associated with the cloud-based device. The smart account can contain additional information that may be needed to complete the migration process, such as a cloud platform-compatible device image to be pushed to the migrated device.

[0034] Once the cloud onboarding server associates the migration device with the existing client / network account, the onboarding server can redirect the device to the cloud-based central management server (i.e., DNA-C server) for upgrading the device image to the cloud-recommended software image specified in the client account (i.e., Cisco Smart Account). Once the image has been upgraded to the cloud-recommended image, the existing configuration (i.e., input configuration) on the device (which was previously sent to the onboarding server with the migration request) can be converted to an output configuration that is compatible with the new cloud-recommended image, and the new configuration (i.e., output configuration) is pushed to the device. After the configuration is successfully applied, the cloud onboarding server device can redirect the device to the default, cloud-based host controller for the device (i.e., default host controller), for example, as specified in the client's account or metadata.

[0035] Figure 2 An example flow chart 200 of an end-to-end seamless migration of a BROWNFIELD (previously deployed) device to a cloud-managed network according to some embodiments of the present technology is shown. Referring to flow chart 200, a device 202 is to be migrated to a cloud-based management platform that includes at least a cloud-based access server 204, a cloud-based central management server 206 (i.e., a DNA-C server), and one or more default cloud controllers (denoted as 208). The device 202 may include a PnP agent for initiating a connection to the cloud access server 204 (which may function as a PnP server).

[0036] Prior to initiating the process, device 202 is active and hosted on a locally deployed network. At this point, device 202 cannot connect to the cloud. A user may initiate a migration of a device to the cloud by, for example, entering a configuration command on the device indicating an intent to migrate to the cloud. This action may automatically generate a migration request 210, which is sent to cloud hosting server 204 after the PnP agent on device 202 performs an initial discovery and connection routine. The existing device configuration may also be sent to cloud hosting server 204 along with the migration request.

[0037] Upon receiving the migration request 210, the cloud onboarding server 204 will attempt to map the identifier of the requesting device 202 to an existing client account to obtain information, such as the identity of a cloud controller that can be used as a cloud hosting endpoint for the requesting device 202. This may be necessary to discover the identity of the specific cloud host (i.e., the default cloud host controller 208) to which the device will ultimately be migrated. Once the onboarding server identifies the source network / client associated with the device, the onboarding server will associate the default host controller assigned to that network / client with the requesting device 202. The migration process continues, with the (cloud-based) onboarding server 204 sending a redirect response 212 to redirect the device to the (cloud-based) central management server 206 for upgrading the device image to a version recommended for the default cloud controller 208. The recommended device image may be specified in the client account, or as part of the client metadata, or simply identified by the cloud-based central management server 206 based on the specification of the default controller host 208. The device dispatches a redirection request for migration (214) to the DNA-C server 206. The cloud-based central management server (i.e., DNA-C server) 206 can initiate a device image upgrade by, for example, redirecting the device to a data entry server dedicated to software image upgrades and instructing the download and installation of the identified software image. The DNA-C server directs the requesting device 202 to download the recommended software image and issues specific instructions to cause the device to reboot using the newly downloaded software image, as shown in operation flow line 216.

[0038] At the end of 216, the device is booted using the new software image. At the beginning of the boot, the device can return to the hosting server again and check if there is anything else to do with a work request 218. Upon receiving the work request, the cloud hosting server 204 will convert the device's existing configuration received from the device with the migration request at 210 to a version compatible with the new software image configuration (220).

[0039] The cloud hosting server 204 sends the updated configuration back to the device (222) (along with a redirect request 224 instructing the device to contact its default controller 208 to complete the migration process). Accordingly, the device 202 initiates a connection request 226 to its default cloud host (i.e., the default cloud controller 208). Subsequently, the default cloud controller 208 establishes a connection to the device and takes over its management (228). Once the connection to the default cloud controller 208 is established (228), normal cloud management operations can begin.

[0040] While the described examples involve a migration flow direction from a locally deployed platform to a cloud-based platform, a similar set and sequence of operations include: using a locally deployed bootstrap server to automatically initiate the migration process, and automatically replacing the cloud-recommended device images and configurations with device images and configurations associated with the locally deployed management platform (which can then be pushed to the cloud-hosted device to convert the cloud-hosted device to a locally deployed managed device).

[0041] Figure 3 A snapshot of a user cloud interface 300 for facilitating device migration from a locally managed platform to a cloud managed platform (or vice versa) is shown. Referring to the snapshot 300, Figure 3 The sample user interface in also provides the ability to monitor the migration status for one or more associated devices. Figure 3 In the snapshot provided in, text and / or graphical elements can be used to convey the device migration status. For example, line items 302, 304 and 306 correspond to successful, pending and error migration conditions, respectively.

[0042] Figure 4 A flowchart 400 is shown for describing an example end-to-end operational flow of an automated cloud migration mechanism in accordance with some embodiments of the present technology. Figure 4The example end-to-end operational flow in corresponds to the automatic initiation of a cloud migration process triggered by resetting a device with an enhanced PnP agent. Referring to flowchart 400, at step 402, after a user-initiated reset operation, the device automatically generates a connection request to a cloud PnP server (i.e., a cloud mediation server). At step 404, the cloud PnP server / mediation server verifies that the connected device is marked for migration with an appropriate cloud service (i.e., a PnP server). If the device (i.e., identified, for example, by an associated serial number) is not marked for migration, the workflow is aborted (405). Otherwise, the operation proceeds to step 406, where the mediation server collects existing device configuration information from the device. In addition, at step 406, the cloud mediation server may query one or more appropriate sources (i.e., a client account database) to identify and obtain metadata records related to the migration process (i.e., cloud-recommended software images and default controller hosts associated with the device). According to some embodiments of the present technology, this can be achieved by matching one or more portions of the device serial number or the device source IP address with, for example, an existing inventory of records. Once the metadata or account information associated with the source network / organization to which the device belongs (as well as the existing device configuration) is identified and collected, the operation proceeds to step 408, where the cloud management server (i.e., DNA-C server) directs the device to the appropriate source to download the cloud-recommended software image (followed by specific instructions for installing and booting the cloud-recommended software image). Once the device is booted according to the new image, the operation proceeds to step 410, where the existing device configuration obtained by the cloud-recommended server at step 406 is converted to a version compatible with the new cloud-recommended software image. Finally, at step 410, the cloud-recommended server redirects the device to its default cloud controller host identified at step 406, at which point the device can be fully managed through the cloud. Some embodiments of the present technology propose an end-to-end automated mechanism for migrating networked devices from a locally deployed network to a cloud-managed network (or vice versa). Thus, some embodiments of the disclosed technology combine various tools and mechanisms that were previously used separately into a single automated mechanism with additional novel aspects. For example, embodiments of the present technology provide a novel way to enhance the current PnP agent on the device to trigger migrations as well as retain and share existing configurations on the device for conversion. By leveraging an enhanced Plug and Play (PnP) agent on the device, embodiments of the present technology provide a true zero-touch migration solution for end users, where only a reset of the device is required to initiate the automated process to perform the desired migration. Embodiments of the present technology also provide a novel way to detect devices and map devices to their smart accounts or source networks based on matching the device source IP with the source IP of existing cloud management devices. Other embodiments may leverage existing serial numbers on the device to perform mapping to smart account records.

[0043] According to some embodiments, the present technology may be implemented in the context of Cisco's Digital Network Architecture Center (DNA-C), which is the foundation controller and analytics platform for intent-based enterprise networks.

[0044] The present disclosure now turns to Figure 5 , Figure 6 and Figure 7 To provide a structural and operational description of some aspects of DNA-C.

[0045] Figure 5 An example of a physical topology of an enterprise network 500 for providing intent-based networking is shown. It should be understood that for the enterprise network 500 and any network discussed herein, additional or fewer nodes, devices, links, networks, or components may be present in similar or alternative configurations. Example embodiments with different numbers and / or types of endpoints, nodes, cloud components, servers, software components, devices, virtual or physical resources, configurations, topologies, services, devices, or deployments are also contemplated herein. In addition, the enterprise network 500 may include any number or type of resources that can be accessed and utilized by an endpoint or network device. The illustrations and examples provided herein are for clarity and simplicity.

[0046] In this example, the enterprise network 500 includes a management cloud 502 and a network structure 520. Although shown as a network or cloud external to the network structure 520 in this example, the management cloud 502 can be located on the organization's premises or in a colocation center (in addition, hosted by a cloud provider or similar environment) instead or in addition. The management cloud 502 can provide a central management plane for building and operating the network structure 520. The management cloud 502 can be responsible for forwarding configuration and policy distribution as well as device management and analysis. The management cloud 502 can include one or more network controller devices 504, one or more authentication, authorization, and accounting (AAA) devices 506, one or more wireless LAN controllers (WLCs) 508, and one or more structure control plane nodes 510. In other embodiments, one or more elements of the management cloud 502 can be co-located with the network structure 520.

[0047] The network controller device(s) 504 may serve as a command and control system for one or more network structures and may accommodate automated workflows for deploying and managing the network structures. The network controller device(s) 504 may include automation, design, policy, provisioning, and assurance capabilities, etc., as described below with respect to Figure 6 Further discussion. In some embodiments, one or more Cisco Digital Network Architecture (Cisco DNATM ) devices may be used as (one or more) network controller devices 504. Other examples of network controller devices may be Figure 2 The cloud hosting server 204 and cloud management server 206 are shown to provide an automated process for seamless end-to-end migration across management platforms (as described in some embodiments of the present technology) that can be implemented in the context of one or more network controller devices.

[0048] The AAA device(s) 506 can control access to computing resources, facilitate enforcement of network policies, audit usage, and provide information necessary for service accounting. The AAA device(s) can interact with the network controller device(s) 504 and with databases and directories containing information for users, devices, transactions, policies, accounting, and the like to provide authentication, authorization, and billing services. In some embodiments, the AAA device(s) 506 can communicate with devices and applications using Remote Authentication Dial-In User Service (RADIUS) or Diameter. In some embodiments, the AAA device(s) 506 can communicate with devices and applications using RADIUS or Diameter. An Identity Services Engine (ISE) device may be used as the AAA device(s) 506 .

[0049] (One or more) WLC 508 can support fabric-enabled access points attached to the network fabric 520, handling traditional tasks associated with WLCs and interaction with the fabric control plane for wireless endpoint registration and roaming. In some embodiments, the network fabric 520 can implement a wireless deployment that moves data plane terminations (e.g., VXLAN) from a centralized location (e.g., with a previous overlay Control and Provisioning of Wireless Access Points (CAPWAP) deployment) to the access point / fabric edge node. This can enable distributed forwarding and distributed policy application for wireless traffic while retaining the advantages of centralized provisioning and management. In some embodiments, one or more Wireless controller, Wireless LAN and / or other Cisco DNA-enabled TM A wireless controller may be used as (one or more) WLC 508.

[0050] The network fabric 520 may include fabric border nodes 522A and 522B (collectively 522), fabric intermediate nodes 524A-D (collectively 524), and fabric edge nodes 526A-F (collectively 526). Although in this example, the fabric control plane node(s) 510 are shown as being located outside the network fabric 520, in other embodiments, the fabric control plane node(s) 510 may be co-located with the network fabric 520. In embodiments where the fabric control plane node(s) 510 are co-located with the network fabric 520, the fabric control plane node(s) 510 may include a dedicated node or set of nodes, or the functionality of the fabric control plane node(s) 510 may be implemented by the fabric border node(s) 522.

[0051] The fabric control plane node(s) 510 can be used as a central database for tracking all users, devices, and things (when they are attached to the network fabric 520 and when they roam). The fabric control plane node(s) 510 can allow the network infrastructure (e.g., switches, routers, WLCs, etc.) to query the database to determine the location of users, devices, and things attached to the fabric, rather than using a flooding mechanism. In this way, the fabric control plane node(s) 510 can be used as a single source of truth about where each endpoint attached to the network fabric 520 is located at any point in time. In addition to tracking specific endpoints (e.g., / 32 addresses for IPv4, / 528 addresses for IPv6, etc.), the fabric control plane node(s) 510 can also track larger aggregation routers (e.g., IP / mask). This flexibility can help aggregate across fabric sites and improve overall scalability.

[0052] The fabric border nodes 522 can connect the network fabric 520 to a traditional layer 3 network (e.g., a non-fabric network) or to different fabric sites. The fabric border nodes 522 can also convert context (e.g., user, device, or thing mapping and identity) from one fabric site to another fabric site or to a traditional network. When the encapsulation is the same across different fabric sites, the conversion of fabric context is typically mapped 1:1. The fabric border nodes 522 can also exchange reachability and policy information with fabric control plane nodes at different fabric sites. The fabric border nodes 522 also provide border functions for internal networks and external networks. The internal border can advertise a defined set of known subnets, such as those leading to a set of branch sites or to a data center. On the other hand, the external border can advertise unknown destinations (e.g., to the Internet with operations similar to the functionality of a default route).

[0053] The fabric mid-node 524 may function as a pure layer 3 repeater that connects the fabric border node 522 to the fabric edge node 526 and provides a layer 3 underlay for fabric overlay traffic.

[0054] The fabric edge nodes 526 can connect endpoints to the network fabric 520, and can encapsulate / decapsulate traffic and forward traffic from these endpoints to the network fabric and from the network fabric to these endpoints. The fabric edge nodes 526 can operate at the periphery of the network fabric 520, and can be the first point for the attachment of users, devices, and things and the implementation of policies. In some embodiments, the network fabric 520 may also include a fabric extension node (not shown) for attaching downstream non-structure layer 2 network devices to the network fabric 520, thereby extending the network fabric. For example, the extension node can be a small switch (e.g., a compact switch, an industrial Ethernet switch, a building automation switch, etc.) that is connected to the fabric edge node via layer 2. Devices or things connected to the fabric extension node can use the fabric edge node 526 to communicate with external subnets.

[0055] In this example, the network structure can represent a single structure site deployment, which can be distinguished from a multi-site structure deployment, as described below with respect to Figure 5 Further discussion.

[0056] In some embodiments, all subnets hosted in a fabric site can be provisioned on each fabric edge node 526 in that fabric site. For example, if subnet 10.10.10.0 / 24 is provisioned in a given fabric site, that subnet can be defined on all fabric edge nodes 526 in that fabric site, and endpoints located in that subnet can be placed on any fabric edge node 526 in that fabric. This can simplify IP address management and allow for the deployment of fewer but larger subnets. In some embodiments, one or more Catalyst switches, Cisco Switch, Cisco MS switches, Integrated Services Router (ISR), Aggregation Services Router (ASR), Enterprise Network Computer System (ENCS), Cloud Service Virtual Router (CSRv), Cisco Integrated Services Virtual Router (ISRv), Cisco MX devices, and / or other Cisco DNA-ready TM Devices may be used as fabric nodes 522 , 524 , and 526 .

[0057] The enterprise network 500 may also include wired endpoints 530A, 530C, 530D, and 530F and wireless endpoints 530B and 530E (collectively 530). The wired endpoints 530A, 530C, 530D, and 530F may be connected to fabric edge nodes 526A, 526C, 526D, and 526F, respectively, by wires, and the wireless endpoints 530B and 530E may be wirelessly connected to wireless access points 528A and 528B (collectively 528), respectively, which in turn may be connected to fabric edge nodes 526B and 526E, respectively, by wires. In some embodiments, Cisco Access point, Cisco MR access points, and / or other Cisco DNA-enabled TM The access point can be used as the wireless access point 528.

[0058] Endpoints 530 may include general computing devices (e.g., servers, workstations, desktop computers, etc.), mobile computing devices (e.g., laptop computers, tablet computers, mobile phones, etc.), wearable devices (e.g., watches, glasses or other head-mounted displays (HMD), headphones, etc.), and the like. Endpoint 530 may also include Internet of Things (IoT) devices or apparatuses, such as agricultural equipment (e.g., livestock tracking and management systems, watering equipment, unmanned aerial vehicles (UAVs), etc.); connected cars and other vehicles; smart home sensors and devices (e.g., alarm systems, security cameras, lighting, appliances, media players, HVAC equipment, electric meters, windows, automatic doors, doorbells, locks, etc.); office equipment (e.g., desk phones, copiers, fax machines, etc.); healthcare equipment (e.g., pacemakers, biometric sensors, medical devices, etc.); industrial equipment (e.g., robots, factory machinery, construction equipment, industrial sensors, etc.); retail equipment (e.g., vending machines, point of sale (POS) equipment, Radio Frequency Identification (RFID) tags, etc.); smart city equipment (e.g., street lights, parking meters, waste management sensors, etc.); transportation and logistics equipment (e.g., turnstiles, rental car trackers, navigation equipment, inventory monitors, etc.); and the like.

[0059] In some embodiments, the network fabric 520 can support wired and wireless access as part of a single integrated infrastructure, so that connectivity, mobility, and policy enforcement behaviors are similar or identical for both wired and wireless endpoints. This can bring a unified experience to users, devices, and things independent of the access medium.

[0060] In an integrated wired and wireless deployment, control plane integration can be achieved by: (one or more) WLC 508 notifies (one or more) fabric control plane nodes 510 of the joining, roaming, and disconnection of wireless endpoints 530, so that (one or more) fabric control plane nodes can have connectivity information about both wired and wireless endpoints in the network fabric 520 and can be used as a single source of truth for endpoints connected to the network fabric. For data plane integration, (one or more) WLC 508 can instruct the fabric wireless access points 528 to form VXLAN overlay tunnels to their neighboring fabric edge nodes 526. The AP VXLAN tunnel can carry segmentation and policy information to and from the fabric edge nodes 526, thereby allowing the same or similar connectivity and functionality as wired endpoints. When a wireless endpoint 530 joins the network fabric 520 via the fabric wireless access point 528, (one or more) WLC 508 can load the endpoint into the network fabric 520 and notify (one or more) fabric control plane nodes 510 of the media access control (MAC) address of the endpoint. The WLC(s) 508 may then instruct the fabric wireless access point 528 to form a VXLAN overlay tunnel to the adjacent fabric edge node 526. Next, the wireless endpoint 530 may obtain its own IP address via Dynamic Host Configuration Protocol (DHCP). Once this operation is complete, the fabric edge node 526 may register the IP address of the wireless endpoint 530 with the fabric control plane node(s) 510 to form a mapping between the endpoint's MAC address and the IP address, and traffic to and from the wireless endpoint 530 may begin to flow.

[0061] Figure 6 An example of a logical architecture 600 for an enterprise network (e.g., enterprise network 500) is shown. One of ordinary skill in the art will appreciate that for the logical architecture 600 and any system discussed in this disclosure, there may be additional or fewer components in similar or alternative configurations. The illustrations and examples provided in this disclosure are for simplicity and clarity. Other embodiments may include different numbers and / or types of elements, but one of ordinary skill in the art will appreciate that such variations do not depart from the scope of this disclosure. In this example, the logical architecture 600 includes a management layer 602, a controller layer 620, a network layer 630 (e.g., embodied by network structure 520), a physical layer 640 (e.g., embodied by Figure 5 embodied in various components), and a shared service layer 650.

[0062] The management layer 602 can abstract the complexity and dependencies of other layers and provide users with tools and workflows for managing an enterprise network (e.g., enterprise network 500). Figure 2 and Figure 4The example automation workflows 200 and 400 provided in FIG. 600 may be implemented at a management layer 602. The management layer 602 may include a user interface 604, a design function 606, a policy function 608, a provisioning function 610, an assurance function 612, a platform function 614, and a base automation function 616. Figure 1 and Figure 3 The user interfaces 100 and 300 shown can be considered as user interface components of the management layer that implement the automation functions described in accordance with some embodiments of the present disclosure. The user interface 604 can provide a single point for managing and automating the network to the user. The user interface 604 can be implemented in the following items: a web application / web server accessible by a web browser; and / or an application / application server accessible by a desktop application, a mobile application, a shell program or other command line interface (CLI), an application programming interface (e.g., RESTful state transfer, REST, Simple Object Access Protocol, SOAP, Service Oriented Architecture, SOA, etc.), and / or another appropriate interface (in which the user can configure the network infrastructure, devices and things managed by the cloud; provide user preferences; specify policies, enter data; view statistics; configure interactions or operations, etc.). The user interface 604 can also provide visibility information, such as a view of the network, network infrastructure, computing devices and things. For example, user interface 604 may provide views of the status or condition of the network, ongoing operations, services, performance, topology or layout, implemented protocols, operating processes, errors, notifications, alerts, network structure, ongoing communications, data analysis, etc.

[0063] The design function 606 may include tools and workflows for managing site profiles, maps and floor plans, network settings, and IP address management, among others. The policy function 608 may include tools and workflows for defining and managing network policies. The provisioning function 610 may include tools and workflows for deploying networks. The assurance function 612 may use machine learning and analytics to provide end-to-end visibility of the network by learning from network infrastructure, endpoints, and other contextual information sources. The platform function 614 may include tools and workflows for integrating network management systems with other technologies. The basic automation function 616 may include tools and workflows for supporting the policy function 608, provisioning function 610, assurance function 612, and platform function 614.

[0064] In some embodiments, the design function 606, the policy function 608, the provisioning function 610, the assurance function 612, the platform function 614, and the basic automation function 616 can be implemented as microservices in which the corresponding software functions are implemented in multiple containers that communicate with each other, instead of merging all tools and workflows into a single software binary. Each of the design function 606, the policy function 608, the provisioning function 610, the assurance function 612, and the platform function 614 can be viewed as a set of related automated microservices for covering the design, policy making, provisioning, assurance, and cross-platform integration phases of the network lifecycle. The basic automation function 614 can support top-level functions by allowing users to perform certain network-wide tasks.

[0065] return Figure 6 , the controller layer 620 may include subsystems for the management layer 602, and may include a network control platform 622, a network data platform 624, and an AAA service 626. These controller subsystems may form an abstraction layer for hiding the complexity and dependencies of managing many network elements and protocols.

[0066] The network control platform 622 can provide automation and orchestration services for the network layer 630 and the physical layer 640, and can include settings, protocols, and tables for automating the management of the network layer and the physical layer. For example, the network control platform 622 can provide design functions 606, configuration functions 608 612. Some functions provided by the network control platform 622 can be used to implement a fully automated end-to-end migration process flow. In addition, the network control platform 622 can include tools and workflows for the following items: discovering switches, routers, wireless controllers, and other network infrastructure devices (e.g., network discovery tools); maintaining network and endpoint details, configurations, and software versions (e.g., inventory management tools); plug-and-play (PnP) for automatically deploying network infrastructure (e.g., network PnP tools); path tracking for creating visual data paths to speed up the resolution of connectivity issues; simple QoS for automating quality of service to prioritize applications on the network; and enterprise service automation (ESA) for automatically deploying physical and virtual network services, etc. In some embodiments of the present technology, the automated migration initiation process (which may be triggered by user input) may utilize the plug-and-play (PnP) features available via the network control platform 622. The network control platform 622 may communicate with network elements using Network Configuration (NETCONF) / Yet Another Next Generation (YANG), Simple Network Management Protocol (SNMP), Secure Shell (SSH) / Telnet, etc. In some embodiments, A network control platform (NCP) may be used as the network control platform 622 .

[0067] The network data platform 624 can provide network data collection, analysis, and assurance, and can include settings, protocols, and tables for monitoring and analyzing network infrastructure and endpoints connected to the network. The network data platform 624 can collect multiple types of information from network infrastructure devices, including Syslog, SNMP, NetFlow, Switched Port Analyzer (SPAN), and streaming telemetry, etc. The network data platform 624 can also collect and use shared context information.

[0068] In some embodiments, one or more Cisco DNA TMThe central device can provide the functions of the management layer 602, the network control layer 622, and the network data layer 624. Cisco DNA TM The central device can support horizontal scalability by adding additional Cisco DNA TM Central nodes; high availability for both hardware components and software packages; backup and storage mechanisms to support disaster discovery scenarios; role-based access control mechanisms for differentiated access to users, devices, and things based on roles and scopes; and programmable interfaces to enable integration with third-party vendors. Cisco DNA TM The hub device can also be cloud-bound to provide upgrades to existing functionality and the addition of new packages and applications without having to manually download and install them.

[0069] AAA services 626 can provide identity and policy services for the network layer 630 and the physical layer 640, and can include settings, protocols, and tables to support endpoint identification and policy enforcement services. AAA services 626 can provide tools and workflows for managing virtual networks and security groups, and for creating group-based policies and contracts. AAA services 626 can use AAA / RADIUS, 602.1X, MAC authentication bypass (MAB), web authentication, and EasyConnect to identify and profile network infrastructure devices and endpoints. AAA services 626 can also collect and use contextual information from network control platform 622, network data platform 624, and shared services 650, etc. In some embodiments, ISE may provide AAA services 626.

[0070] The network layer 630 can be conceptualized as a combination of two layers, a bottom layer 634, which includes physical and virtual network infrastructure (e.g., routers, switches, WLCs, etc.) and layer 3 routing protocols for forwarding traffic, and an overlay layer 632, which includes a virtual topology for logically connecting wired and wireless users, devices, and things and applying services and policies to these entities. The network elements of the bottom layer 634 can establish connectivity between each other, for example, via the Internet Protocol (IP). The bottom layer can use any topology and routing protocol.

[0071] In some embodiments, the network controller 504 may provide local area network (LAN) automation services (e.g., provided by Cisco DNA TMCentral LAN Automation Implementation) for automatic discovery, provisioning, and deployment of network devices. Once discovered, the automated underlying provisioning service can apply the required protocol and network address configuration to the physical network infrastructure using Plug and Play (PnP). In some embodiments, the LAN Automation service can implement the Intermediate System to Intermediate System (IS-IS) protocol. Some advantages of IS-IS include: neighbor establishment without IP protocol dependency; peer-to-peer capability using loopback addresses; and agnostic handling of IPv4, IPv6, and non-IP traffic.

[0072] The overlay 632 may be a logical virtualized topology built on top of the physical underlay 634 and may include a fabric data plane, a fabric control plane, and a fabric policy plane. In some embodiments, the fabric data plane may be created via packet encapsulation using a Virtual Extensible LAN (VXLAN) with a Group Policy Option (GPO). Some advantages of VXLAN-GPO include: its support for both layer 2 and layer 3 virtual topologies (overlays); and its ability to run on any IP network with built-in network segmentation.

[0073] In some embodiments, the fabric control plane may implement the Locator / ID Separation Protocol (LISP) for logically mapping and resolving users, devices, and things. LISP may simplify routing by eliminating the need for each router to handle every possible IP destination address and route. LISP may accomplish this by moving remote destinations to a centralized map database that allows each router to manage only its local routes and query the map system to locate the destination endpoint.

[0074] The fabric policy plane is where intent can be translated into network policies. That is, the policy plane is where network operators can instantiate logical network policies based on the services provided by the network fabric 520 (e.g., security segmentation services, quality of service (QoS), capture / copy services, application visibility services, etc.).

[0075] Segmentation is a method or technique for separating a specific group of users or devices from other groups in order to reduce congestion, improve security, contain network problems, control access, and the like. As discussed, the structure data plane can implement VXLAN encapsulation to provide network segmentation by using the virtual network identifier (virtual network identifier, VNI) and Scalable Group Tag (Scalable Group Tag, SGT) field in the packet header. The network structure 520 can support both macro segmentation and micro segmentation. Macro segmentation logically divides the network topology into smaller virtual networks by using a unique network identifier and a separate forwarding table. This can be instantiated as a virtual routing and forwarding (virtualrouting and forwarding, VRF) instance and is referred to as a virtual network (virtual network, VN). That is, VN is a logical network instance defined by a layer 3 routing domain within the network structure 520, and can provide both layer 2 and layer 3 services (using VXLAN VNI to provide both layer 2 and layer 3 segmentation). Micro-segmentation logically separates groups of users or devices in a VN by enforcing source-to-destination access control permissions (e.g., by using access control lists (ACLs)). A scalable group is a logical object identifier assigned to a group of users, devices, or things in the network fabric 520. It can be used as a source and destination classifier in a Scalable Group ACL (SGACL). SGTs can be used to provide group-based policies that are independent of addresses.

[0076] In some embodiments, the fabric control plane nodes 510 can implement a locator / identifier separation protocol (LISP) to communicate with each other and with the management cloud 502. Thus, the control plane nodes can operate a host tracking database, a map server, and a map resolver. The host tracking database can track endpoints 530 connected to the network fabric 520 and associate the endpoints with fabric edge nodes 526, thereby decoupling the identifier of the endpoint (e.g., an IP or MAC address) from its location in the network (e.g., the nearest router).

[0077] The physical layer 640 may include network infrastructure devices such as switches and routers 510 , 522 , 524 , and 526 and wireless elements 508 and 528 , as well as network devices such as network controller device(s) 504 and AAA device(s) 506 .

[0078] The shared services layer 650 may provide interfaces to the following external network services: for example, cloud services 652; Domain Name System (DNS), DHCP, IP Address Management (IPAM), and other network address management services 654; Firewall services 656; Network as a Sensor (Naas) / Encrypted Threat Analytic (ETA) services; and Virtual Network Function (VNF) 660; etc. The management layer 602 and / or the controller layer 620 may use APIs via the shared services layer 650 to share identities, policies, forwarding information, etc.

[0079] Figure 7 An example of a physical topology for a multi-site enterprise network 700 is shown. In this example, the network fabric includes fabric sites 720A and 720B. Fabric site 720A may include fabric control node 710A, fabric border nodes 722A and 722B, fabric intermediate nodes 724A and 724B (shown here in dashed lines and not connected to fabric border nodes or fabric edge nodes for simplicity), and fabric edge nodes 726A-C. Fabric site 720B may include fabric control node 710B, fabric border nodes 722C-E, fabric intermediate nodes 724C and 724D, and fabric edge nodes 726D-F. Corresponding to a single fabric (e.g., Figure 7 A plurality of fabric sites of a network structure (e.g., a transit network) may be interconnected through a transit network. A transit network may be part of a network structure that has its own control plane nodes and border nodes but no edge nodes. In addition, a transit network shares at least one border node with each fabric site it is interconnected with.

[0080] Typically, a transit network connects the network structure to the outside world. There are several methods for external connectivity, such as a traditional IP network 736, a traditional WAN 738A, a software-defined WAN (SD-WAN) (not shown), or a software-defined access (SD-Access) 738B. Traffic across structural sites and to other types of sites can provide connectivity between these sites using the control plane and data plane of the transit network. Local border nodes can be used as switching points from structural sites, and the transit network can pass traffic to other sites. The transit network can use other features. For example, if the transit network is a WAN, features such as performance routing can also be used. In order to provide end-to-end policies and segmentation, the transit network should be able to carry endpoint context information (e.g., VRF, SGT) across the network. Otherwise, traffic may need to be reclassified at the destination site boundary.

[0081] The local control plane in a fabric site may only maintain state related to endpoints connected to edge nodes within the local fabric site. For a single fabric site (e.g., network fabric 520), the local control plane may register local endpoints via local edge nodes. Endpoints that are not explicitly registered with the local control plane may be assumed to be reachable via border nodes connected to the transit network. As such, it may be necessary to identify a default cloud controller (which may serve as the final cloud-hosted endpoint for network devices being migrated to the cloud) (as described in accordance with some embodiments of the present technology and in Figure 2 and Figure 3 In some embodiments, the local control plane may not save the state of endpoints attached to other fabric sites, so that the border nodes do not register information from the transit network. In this way, the local control plane can be independent of other fabric sites, thereby enhancing the overall scalability of the network.

[0082] The control plane in the transit network can maintain the summary status of all the fabric sites it interconnects. This information can be registered to the transit control plane through the borders from different fabric sites. The border nodes can register EID information from the local fabric site to the transit network control plane for summary EIDs only, and thus further improve scalability.

[0083] The multi-site enterprise network 700 may also include a shared services cloud 732. The shared services cloud 732 may include one or more network controller devices 704, one or more AAA devices 706, and other shared servers (e.g., DNS; DHCP; IPAM; SNMP and other monitoring tools; NetFlow, Syslog, and other data collectors, etc.) may reside. These shared services may typically reside outside the network structure and reside in the global routing table (GRT) of the existing network. In this case, some method of inter-VRF routing may be required. One option for inter-VRF routing is to use a fusion router, which may be an external router that performs inter-VRF leaks (e.g., import / export of VRF routes) to fuse the VRFs together. Multiple protocols can be used for this route exchange because they can inherently prevent routing loops (e.g., using the AS_PATH attribute). Other routing protocols may also be used, but complex distribution lists and prefix lists may be required to prevent loops.

[0084] However, using fusion routers to implement inter-VN communication may have some disadvantages, such as: route duplication, because routes leaked from one VRF to another are programmed in hardware tables and may result in higher TCAM utilization; manual configuration at multiple touch points to implement route leaking; loss of SGT context, because SGTs may not be maintained across VRFs and must be reclassified once traffic enters another VRF; and traffic hairpinning, because traffic may need to be routed to the fusion router and then back to the fabric boundary node.

[0085] The SD-Access extranet can provide a flexible and scalable method for implementing inter-VN communication by: avoiding route duplication because inter-VN lookups are done in the fabric control plane (e.g., software), eliminating the need to replicate route entries in hardware; providing a single point of contact because network management systems (e.g., Cisco DNA TM Center) can automate inter-VN lookup policy to make it a single management point; maintain SGT context because inter-VN lookup is done in (one or more) control plane nodes (e.g., software); and avoid backhaul because inter-VN forwarding can be done at the edge of the fabric (e.g., inside the same VN), so traffic does not need to be backhauled at the border node. Another advantage is that a separate VN can be created for each common resource required (e.g., shared service VN, Internet VN, data center VN, etc.).

[0086] The present disclosure now turns to Figure 8 and Fig. 9 , which illustrate example architectures of computing network devices (e.g., client computers, switches, routers, servers, etc.).

[0087] Figure 8A computing system architecture 800 is shown that includes components that communicate electrically with each other using a connection 805 such as a bus. The system 800 includes a processing unit (CPU or processor) 810 and a system connection 805 that couples various system components (e.g., read-only memory (ROM) 820 and random access memory (RAM) 825) including a system memory 815 to the processor 810. The system 800 may include a cache of high-speed memory directly connected to, closely adjacent to, or integrated as a part of the processor 810. The system 800 may copy data from the memory 815 and / or storage device 830 to the cache 812 for rapid access by the processor 810. In this way, the cache may provide a performance boost, thereby avoiding delays in the processor 810 while waiting for data. These modules and other modules may control or be configured to control the processor 810 to perform various actions. Other system memories 815 may also be available. The memory 815 may include a variety of different types of memory with different performance characteristics. The processor 810 may include any general purpose processor and hardware or software services (e.g., service 1 832, service 2 834, and service 3 836 stored in the storage device 830) configured to control the processor 810, and the processor 810 may include a dedicated processor incorporating software instructions in the actual processor design. The processor 810 may be a completely independent computing system, including multiple cores or processors, buses, memory controllers, caches, etc. Multi-core processors may be symmetric or asymmetric.

[0088] In order to enable the user to interact with the computing device 800, the input device 845 can represent any number of input mechanisms, such as a microphone for voice, a touch-sensitive screen for gesture or graphic input, a keyboard, a mouse, motion input, voice, etc. The output device 835 can also be one or more of many output mechanisms known to those skilled in the art. In some cases, the multimodal system can enable the user to provide multiple types of input to communicate with the computing device 800. The communication interface 840 can generally dominate and manage user input and system output. There is no restriction on the operation on any specific hardware arrangement, so as the improved hardware or firmware arrangement is developed, the basic features here can be easily replaced with these improved hardware or firmware arrangements.

[0089] The storage device 830 is a non-volatile memory and may be a hard disk or other type of computer-readable medium capable of storing data accessible by a computer, such as a magnetic tape cartridge, a flash memory card, a solid-state memory device, a digital versatile disk, a cassette tape, a random access memory (RAM) 825, a read-only memory (ROM) 820, and a mixture thereof.

[0090] The storage device 830 may include services 832, 834, 836 for controlling the processor 810. Other hardware or software modules are contemplated. The storage device 830 may be connected to the system connection 805. In one aspect, a hardware module that performs a particular function may include a software component stored in a computer-readable medium that is combined with the necessary hardware components such as the processor 810, the connection 805, the output device 835, etc. to perform the function.

[0091] Fig. 9 An example network device 900 suitable for performing switching, routing, guaranteeing and other networking operations is shown. The network device 900 includes a central processing unit (CPU) 904, an interface 902 and a connection 910 (e.g., a PCI bus). When acting under the control of appropriate software or firmware, the CPU 904 is responsible for performing packet management, error detection and / or routing functions. The CPU 904 preferably completes all these functions under the control of software including an operating system and any appropriate application software. The CPU 904 may include one or more processors 908, such as a processor from the INTEL X106 series of microprocessors. In some cases, the processor 908 may be specially designed hardware for controlling the operation of the network device 900. In some cases, a memory 906 (e.g., non-volatile RAM, ROM, TCAM, etc.) also forms a part of the CPU 904. However, there are many different ways to couple the memory to the system. In some cases, the network device 900 may include a memory and / or storage hardware (e.g., TCAM) separate from the CPU 904. Such memory and / or storage hardware may be coupled with network device 900 and its components via connection 910, for example.

[0092] Interface 902 is usually provided as a modular interface card (sometimes referred to as a "line card"). Generally speaking, they control the sending and receiving of data packets on the network, and sometimes support other peripheral devices used with network device 900. The interfaces that can be provided include Ethernet interfaces, frame relay interfaces, cable interfaces, DSL interfaces, token ring interfaces, etc. In addition, various very high-speed interfaces can be provided, such as fast token ring interfaces, wireless interfaces, Ethernet interfaces, Gigabit Ethernet interfaces, ATM interfaces, HSSI interfaces, POS interfaces, FDDI interfaces, WIFI interfaces, 3G / 4G / 5G cellular interfaces, CAN BUS, LoRA, etc. In general, these interfaces can include ports suitable for communicating with appropriate media. In some cases, they can also include independent processors, and in some cases, volatile RAM can also be included. Independent processors can control communication-intensive tasks such as packet switching, media control, signal processing, encryption processing and management. By providing separate processors for communication-intensive tasks, these interfaces allow the main microprocessor 904 to effectively perform routing calculations, network diagnostics, security functions, etc.

[0093] although Fig. 9 The system shown is a specific network device of the present disclosure, but it is by no means the only network device architecture on which the concepts herein may be implemented. For example, an architecture with a single processor may be used that handles communications as well as routing calculations, etc. In addition, other types of interfaces and media may also be used with network device 900.

[0094] Regardless of the configuration of the network device, it can use one or more memories or memory modules (including memory 906), which are configured to store program instructions for general network operations and mechanisms for roaming, route optimization and routing functions described herein. Program instructions can control the operation of, for example, an operating system and / or one or more applications. One or more memories can also be configured to store tables such as mobility binding, registration, and association tables. Memory 906 can also accommodate various software containers and virtualized execution environments and data.

[0095] The network device 900 may also include an application specific integrated circuit (ASIC) that may be configured to perform routing, switching, and / or other operations. For example, the ASIC may communicate with other components in the network device 900 via connection 910 to exchange data and signals and coordinate various types of operations performed by the network device 900, such as routing, switching, and / or data storage operations.

[0096] In some embodiments, computer-readable storage devices, media, and memories may include cables or wireless signals containing bit streams, etc. However, when referred to, non-transitory computer-readable storage media explicitly exclude media such as energy, carrier signals, electromagnetic waves, and signals themselves.

[0097] In summary, the present technology relates to an automated end-to-end network migration process from a locally deployed management platform to a cloud-based management platform (or vice versa). The disclosed technology describes an enhanced Plug and Play (PnP) software agent that is operatively coupled to a device and is capable of interacting with a PnP service hosted on a target management platform to initiate a migration process. Upon receiving a migration request from the device PnP agent, the PnP service on the target management platform maps the requesting device to a client profile present on the target management platform, and identifies an associated default controller for the device based on the client profile. Subsequently, the device is directed to obtain and boot in accordance with a new software image that is compatible with the target management platform, and after converting the device's existing configuration to a version compatible with the new software image, the device is migrated to the associated default controller.

[0098] The method according to the above example can be implemented using computer executable instructions stored in a computer readable medium or otherwise available from a computer readable medium. Such instructions can include, for example, instructions and data that cause or otherwise configure a general-purpose computer, a special-purpose computer, or a special-purpose processing device to perform a specific function or functional group. The partial computer resources used can be accessible through a network. Computer executable instructions can be, for example, binary, intermediate format instructions, such as assembly language, firmware, or source code. Examples of computer readable media that can be used to store instructions, information used during the method according to the example, and / or information created include disks or optical disks, flash memory, USB devices equipped with non-volatile memory, networked storage devices, etc.

[0099] The equipment implementing the method according to these disclosures may include hardware, firmware and / or software, and may adopt any of a variety of form factors. Typical examples of such form factors include laptop computers, smart phones, small form factor personal computers, personal digital assistants, etc. The functionality described herein may also be embodied in peripheral devices or add-on cards. As a further example, such functionality may also be implemented on circuit boards between different chips or different processes executed in a single device.

[0100] Instructions, media for communicating such instructions, computing resources for executing such instructions, and other structures for supporting such computing resources are means for providing the functionality described in these disclosures.

[0101] Although various examples and other information are used to explain various aspects within the scope of the appended claims, limitations to the claims should not be implied based on specific features or arrangements in such examples, because those of ordinary skill in the art will be able to use these examples to derive a variety of implementations. In addition, although some topics may have been described in language specific to examples of structural features and / or method steps, it should be understood that the subject matter defined in the appended claims is not necessarily limited to these described features or actions. For example, such functionality may be distributed in different ways or performed in components other than those identified herein. Instead, the described features and steps are disclosed as examples of components and methods of systems within the scope of the appended claims.

Claims

1. A computer-implemented method for implementing a fully automated end-to-end network migration process across different management platforms, comprising: Receiving, by a first server on a first management platform, a migration request associated with an identifier for a device on a second management platform; mapping the identifier to a client account on the first management platform; directing the device to boot using a different software image than a software image previously installed on the device, wherein the different software image is provided by a second server on the first management platform, and wherein the different software image is identified for the device based on the client account, the client account designating the different software image as a recommended software image to be deployed on the device by the first management platform; updating, by the first server, an existing configuration of the device to a configuration compatible with the different software image provided by the second server; and Migrating the device to a host controller identified by the client account on the first management platform, wherein the client account specifies the host controller as a recommended host controller for the device.

2. The computer-implemented method of claim 1, wherein: The first server corresponds to a cloud-based access server.

3. The computer-implemented method of claim 2, wherein: The cloud-based gateway server hosts a PnP service for communicating with a PnP software agent.

4. A computer-implemented method according to any one of claims 1 to 3, wherein: The identifier for the device corresponds to at least one of a serial number and an IP address.

5. A computer-implemented method according to any one of claims 1 to 3, wherein: The second server corresponds to a cloud-based central management server.

6. The computer-implemented method of claim 5, wherein: The cloud-based central management server is implemented in a Digital Network Architecture Center (DNA-C).

7. A computer-implemented method according to any one of claims 1 to 3, wherein: The host controller on the first management platform corresponds to a default, cloud-based controller associated with the client account.

8. A computer-implemented method according to any one of claims 1 to 3, wherein: In addition to the migration request, the first server also receives a copy of the existing configuration of the device.

9. A computer-implemented method according to any one of claims 1 to 3, wherein: The migration request for the device on the second management platform is initiated by a PnP software agent on the device receiving input from a user.

10. The computer-implemented method of claim 9, wherein: The input from the user includes CLI commands.

11. The computer-implemented method of claim 10, wherein: A CLI wrapper on the device enables receipt of the CLI commands by the PnP software agent.

12. The computer-implemented method of claim 11, wherein: The CLI wrapper is implemented as a graphical user interface.

13. A system comprising: one or more processors; as well as At least one computer-readable storage medium having stored therein instructions that, when executed by the one or more processors, cause the one or more processors to perform the following operations: mapping an identifier received in association with a migration request from a device on a second management platform to a client account on the first management platform; directing the device on the second management platform to boot using a different software image than a software image previously installed on the device, wherein the different software image is compatible with the first management platform, and wherein the different software image is identified for the device based on the client account, the client account designating the different software image as a recommended software image to be deployed on the device by the first management platform; converting an input configuration for the device on the second management platform into an output configuration compatible with the different software image; and The device is migrated to a host controller associated with the client account on the first management platform, wherein the client account specifies the host controller as a recommended host controller for the device.

14. The system according to claim 13, wherein: The first management platform corresponds to at least one of the following: a locally deployed management platform, and a cloud-based management platform.

15. The system of claim 14, wherein: The cloud-based management platform is implemented as part of Cisco's Digital Network Architecture Center (DNA-C).

16. A system according to any one of claims 13 to 15, wherein: The second management platform corresponds to at least one of the following: a locally deployed management platform, and a cloud-based management platform.

17. A system according to any one of claims 13 to 15, wherein: The migration request of the device from the second management platform is initiated by a PnP software agent on the device in response to user input.

18. The system of claim 17, wherein: The user input corresponds to a CLI command, which is provided to the PnP software agent through a CLI wrapper.

19. The system of claim 18, wherein: The CLI wrapper is implemented as a graphical user interface.

20. The system according to any one of claims 13 to 15, wherein: The identifier received in association with the migration request from the device on the second management platform corresponds to at least one of a serial number and an IP address.

21. A device for implementing a fully automated end-to-end network migration process across different management platforms, comprising: means for receiving, by a first server on a first management platform, a migration request associated with an identifier for a device on a second management platform; means for mapping the identifier to a client account on the first management platform; means for directing the device to boot using a different software image than a software image previously installed on the device, wherein the different software image is provided by a second server on the first management platform, and wherein the different software image is identified for the device based on the client account, the client account designating the different software image as a recommended software image to be deployed by the first management platform on the device; means for updating, by the first server, an existing configuration of the device to a configuration compatible with the different software image provided by the second server; and Means for migrating the device to a host controller identified by the client account on the first management platform, wherein the client account designates the host controller as a recommended host controller for the device.

22. The apparatus according to claim 21, further comprising: A component for implementing the method according to any one of claims 2 to 12.

23. A computer program, a computer program product or a computer readable medium comprising instructions which, when executed by a computer, cause the computer to perform the steps of the method according to any one of claims 1 to 12.

Images