Open Plug N Play is no longer being developed or supported and has been archived on DevNet.

Discover Open Plug-n-Play Agent

Installation of new or replacement networking devices can be expensive, time consuming and error prone when done manually. Typically, the new devices are first sent to a central staging facility where the devices are unboxed, connected to a staging network, updated with the right licenses, configurations and images; then packaged and shipped to the actual installation location. Also, expert installers (CLI experts) will need to travel to the installation location to perform the installation. Even in scenarios where the install location is in the NOC/Data Center itself, doing manual install process may not scale for the sheer number of devices with the number of installers available. All these issues contribute to delays in deployment and add to the operational costs.

Cisco Plug-n-Play solution allows customers to reduce the costs associated with deployment/installation of network devices, increase the speed and reduce the complexity of deployments without compromising the security. Using Cisco Plug-n-Play solution, customers can do Zero Touch Installs of Cisco gear in various deployment scenarios and deployment locations. Plug-n-Play provides same user experience for routers and switches whether they are being installed in a campus or branch or a data center.

Existing solutions

Prior to Plug-n-Play, multiple solutions such as Auto Install, Smart Install, CNS with Config Engine, WSMA etc. have tried to solve the problem of installation. Even though these existing solutions alleviate the problem to some extent, these solutions differed in workflow, user experience and address specific deployment scenario or device type. These solutions used proprietary protocols and messaging mechanisms, which did not allow for any customer or third party integration. Also, these solutions did not take advantage of Secure UDI (a hardware certificate) to provide the additional security as required by ever increasing security requirements.

The need for simple, secure and consistent zero touch deployment across platforms and across deployment scenarios triggered the development of Plug-n-Play solution.

Typical Solution Workflow

Workflow for a typical Plug-n-Play deployment of new router/switch is depicted in the diagram below.

  • Step 0: Network administrator pre-provisions the new device in PnP server. He/she identifies the image, configuration and other files (such as scripts) to be loaded on the new device against the device unique identifier (typically serial number).
  • Step 1: The installer connects the all the cables (network cables and power cables) per instructions and powers on the new device. In certain scenarios the installer may need to use the PnP helper mobile application, but that is not considered in this workflow.
  • Step 2: The new device boots up and PnP agent gets triggered because there is no startup configuration in the NVRAM (new devices will not have any startup configuration by default). As part of the boot process, PnP agent discovers PnP server’s IP address using variety of mechanisms (described in detail in “PnP server discovery” chapter).
  • Step 3: Once PnP server is discovered, PnP agent initiates communication with PnP server using selected transport protocol (selected during PnP server discovery process) and authenticates itself using UDI or Secure UDI. Once the device is authenticated, a communication channel is established between PnP agent and PnP server.
  • Step 4: PnP server retrieves device information like product ID, serial number, file system contents etc.
  • Step 5: PnP server uses device information to match against pre-provisioned devices and determines the right image, configuration file and other files to download to the new device.
  • Step 6: PnP server sends service requests to install the right image, configuration and other files.
  • Step 7: PnP agent services all the requests which would involve downloading a new image, a new configuration file and other files from the file server. The file server can be on the same physical server where PnP server application is running or it can be in a different server which is in close proximity to the new device (for example, another networking device in the same location where the new device is being deployed). The service requests contain URLs to the files and PnP agent can service the request as long as the URLs are accessible.
  • Step 8: PnP agent installs the new image, uploads the configuration to the running configuration, saves the running configuration to startup configuration and reloads. Once the device comes back up, it will be fully operational with the right image, right configuration and other scripts/files as pre-provisioned by the administrator.
PnP solution Components

PnP deployment solution has 4 major components.

  1. PnP agent

    2. PnP agent is in the network OS that starts when the new device is booting for the first time. It is triggered at the boot time when the boot process finds no startup configuration in the NVRAM. It can also be triggered, by creating a PnP profile using the configuration commands. During the boot process, PnP agent discovers the IP address of the PnP server using various discovery mechanisms (listed in PnP server discovery chapter) and establishes a communication channel using open PnP protocol. It receives instructions from the PnP server to complete the deployment process.

  2. PnP server

    3. PnP server is an application that typically resides in customer’s network and it is pre-configured with the information about what files (images, configurations, files and licenses) must be delivered to the network device to deploy it fully and make it operational. PnP Server communicates with the PnP agent on the device using open PnP protocol. Cisco Plug-n-Play solution includes a PnP server developed by Cisco, but customers and partners can develop their own PnP servers based on the protocol specification described in this document.

  3. PnP protocol

    4. PnP Protocol defines the transport bindings and schemas for various messages that get exchanged between the PnP agent and PnP server. This is an open, developer friendly protocol allowing customer or third-party development of PnP servers. Transport protocols supported by PnP are HTTP(/S) and XMPP. The encoding scheme is XML and XSDs are listed in the Appendix A. The message schemas are independent of transport protocol. Detailed description of each message is provided in “PnP Protocol Specification” chapter.

  4. PnP helper application

    5. PnP helper application is an Apple iOS or an Android application that runs on smart phones or tablets. In certain scenarios where PnP agent cannot discover or connect to PnP server, installer connects the mobile device to the networking device and bootstraps the device to a state where PnP agent can establish the communication with PnP server.

  5. PnP cloud redirection service

    6. PnP cloud redirection service is a cloud hosted redirection service offered in Open Plug-n-Play solution which helps the PnP agent locate the PnP server by redirecting it to the correct server. It is used to address scenarios where a small branch/satellite location needs to be deployed in a zero touch way.