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

 

PnP server discovery
PnP protocol specification

PnP agent discovering PnP server at boot time is a key step in PnP workflow. Discovering the PnP server depends on multitude of factors such as reachability and accessibility to DHCP and DNS servers, connectivity to the network and connectivity to the Internet. To support various deployment scenarios, PnP agent uses the following discovery mechanisms to locate the PnP server.

These discovery methods are tried in a sequence and if one method is successful, PnP agent will not try the remaining discovery methods and concludes the discovery process. If none of the discovery methods succeed, the process repeats again for 1 week/month.

Additional discovery mechanisms will be supported in future (example: discovery over 3G/4G cellular connection etc.)

Note that PnP server can be seeded using the Mobile App or manually by entering PnP commands on the console at any time the device console become accessible. In this case, the PnP server discovery process breaks out of the retry loop and go with the PnP server configured by the Mobile App or manual CLI.

The following sections describe each discovery method in detail.

 


DHCP Vendor Specific Options

DHCP vendor specific options in DHCP response are commonly used to supply additional data along with the IP address in response to a DHCP request from a device (typically at boot time). RFC 2132 defines two DHCP Options that are relevant to vendor specific options. They are Option 60 and Option 43.

DHCP Option 60 is the Vendor Class Identifier (VCI). The VCI is a text string that uniquely identifies a type of vendor device. Option 60 is included in the initial DHCP discover message that a DHCP client broadcasts in search of an IP address. Option 60 is used by DHCP client in order to identify itself to the DHCP server.

DHCP servers return vendor specific information as DHCP Option 43. The RFC allows vendors to define encapsulated vendor-specific sub-option codes between 0 and 255. The sub-options are all included in the DHCP offer as type-length-value (TLV) blocks embedded within Option 43. The definition of the sub-option codes and their related message format is left to the vendors. When the DHCP server sees a recognizable VCI in a DHCP discover from a DHCP client, it returns the mapped vendor specific information in its DHCP offer to the client as DHCP Option 43. On the DHCP server, option 43 is defined in each DHCP pool (Scope).

DHCP client on PnP enabled networking device uses “CiscoPnP” as the VCI. In order to facilitate PnP server discovery using DHCP Options 60 and 43, the DHCP server must be configured to return PnP server IP address in option 43 when VCI received in Option 60 matches to “CiscoPnP”.

Syntax for Option 43:

<DHCP-typecode><feature-opcode><version><debug-option><arglist>

Parameter Description
DHCP-typecode DHCP sub-option type. The DHCP sub-option type for PnP is 5.
feature-opcode Feature operation code – can be either Active (A) or Passive (P). The feature operation code for PnP is Active (A) which implies that PnP agent initiates a connection to the PnP server. If the PnP server cannot be reached, PnP agent retries until it makes a connection.
version Version of template to be used by PnP agent.
debug-option Turns ON or OFF the debug messages during the processing of the DHCP Option 43.
  • D – debug option is ON
  • N – debug option is OFF
; Delimiter used to separate the parameters.
arglist List of named arguments for the command separated by a semicolon. Letter codes are used to identify the arguments. Name and value pairs can be listed in any order and are delimited by a semicolon. To use the default value for an argument, do not specify values for that parameter.

Syntax for arglist:

B<IP address type>;I<IP address/hostname>;J<Port>;K<Transport protocol>;N<XMPP User name>;O<XMPP Password>;P<XMPP server JID>;T<Trust pool CA bundle URL>;Z<NTP server IP address>”

Letter code Description Mandatory?
B IP address type of PnP server IP address specified with the letter code ‘I’
  • 1—host
  • 2—IPv4
  • 3—IPv6
 Optional.
Default is IPv4.
I IP address or hostname of PnP server. If hostname is specified, DNS related options must be present in the DHCP server to allow for successful use of hostname. Mandatory
J Port number to be used to establish PnP server connection. Optional.
Defaults are:
HTTP – 80
HTTPS – 443
XMPP-
starttls/XMPP
socket – 5222
XMPP-tls – 5223
K Transport protocol to be used between PnP agent and PnP server
  • 1 – XMPP-starttls
  • 2 – XMPP-socket
  • 3 – XMPP-tls
  • 4 – HTTP
  • 5 – HTTPS
 Optional.
Default is HTTP.
N Username to connect to PnP server Mandatory when transport protocol is XMPP.
Optional for HTTP/HTTPS.
O Password to connect to PnP server Mandatory when transport protocol is XMPP.
Optional for HTTP/HTTPS.
P JID of XMPP server Mandatory when transport protocol is XMPP.
Not applicable for HTTP/HTTPS.
T URL of trust pool CA bundle. Mandatory when transport protocol is XMPP-starttls, XMPP-tls and HTTPS.
Z NTP server IP address. Required to sync the clock before configuring trust pool. Mandatory when trust pool is configured.
Example 1:

5A1N;K4;B3;IFE80::2E0:81FF:FE2D:3799;J6088

5 – DHCP type code 5
A – Active feature operation code
1 – Version 1
N – Debug OFF
; - Delimiter
K4 – HTTP transport protocol
B3 – PnP server IP address type is IPv6
IFE80::2E0:81FF:FE2D:3799 – PnP server IP address (non-bold text)
J6088 – Port number 6088

Example 1:

5A1D;K2;B2;I172.19.193.60;J5222;Ppnpserver2.ejabberd.test;Npnpagent2@ejabberd.test;Ocisco

5 – DHCP type code 5
A – Active feature operation code
1 – Version 1
N – Debug ON
; - Delimiter
K2 – XMPP socket transport protocol
B2 – PnP server IP address type is IPv4
I172.19.193.60 – PnP server IP address
J5222 – Port number 5222
Ppnpserver2.ejabberd.test - XMPP server JID (non-bold text)
Npnpagent2@ejabberd.test – XMPP server username (non-bold text)
Ocisco – XMPP password (non-bold text)

The following assumptions are made to use DHCP VSO for PnP server discovery.

  • DHCP server can be used to assign IP addresses for the new networking devices (even if it is temporary and later replaced with a static IP address using configuration)
  • DHCP server is reachable by the DHCP protocol by the new networking device (either directly or with the help of DHCP relay)
  • Network administrator can configure DHCP server to send DHCP vendor specific options

Step 0:   Administrator configures DHCP server to send PnP server IP address in option 43.

The configuration steps depend on the DHCP server deployed in the network. This section shows the steps for Cisco IOS DHCP Server and Linux DHCP server.

Cisco IOS DHCP Server

In configuration mode, create the DHCP pool with necessary configuration such as network address and subnet mask. Add the Option 43 line with the syntax described above. Option 43 for PnP is highlighted below.

ip              dhcp              pool             PNP-POOL
  network            172.19.210.0              255.255.255.0
  default-router                                172.19.210.1
  option 43 ascii  "5A;K4;B2;I172.19.210.215;J80"

Step 1: Networking device is cabled and powered on. Since the startup configuration in NVRAM is empty, PnP agent is triggered and sends “Cisco PnP” in DHCP Option 60 in DHCP DISCOVER message.

Step 2: DHCP server matches “Cisco PnP” in Option 60 and sends the configured string (as shown in Step 0) in Option 43. This string is interpreted by PnP agent and PnP server IP address is decoded.

DHCP Snooping

In case the third party DHCP server cannot be configured to insert any vendor specific options, an existing PnP enabled device can be configured to snoop in to the DHCP response and insert PnP specific option X with the PnP server IP address. Before inserting the option X, the snooping agent will verify the DHCP message is from a Cisco device in the network. The remaining DHCP discovery process is same as described in the previous section.



DHCP snooping can be enabled on any PnP enabled device that is up and running. PnP server sends a work request to the device to enable DHCP snooping. The work request should contain either profile name (that is already configured on the device) or ip address of the PnP server. The other optional field in the work request is Vlan id; Vlan number to enable snooping, if the value is not present in the work request by default snooping will be enabled on all the active Vlan’s. After enabling the snooping, the device sends a work response back to the server and starts listening for DHCP packets. In the same way the server can also send work request to disable snooping.

Whenever there is a new DHCP packet coming from the DHCP server to the client, snooping agent checks for option 150, if the option 150 is not present, it will insert option150 into the packet. Once the client receives the DHCP packet it configures PnP profile and connects to the PnP server.

DNS lookup

DNS lookup is another common mechanism for discovering network controllers and management application servers. Even though DHCP is used in this process, no DHCP Vendor Specific Options need to be configured on DHCP server. DNS lookup will be an ideal approach in cases where DHCP server cannot be modified or customized for networking devices (for example, customized classes for Option 43).

The following assumptions are made to use DNS lookup for PnP server discovery.

  • DHCP server can be used to assign IP addresses for the new networking devices (even if it is temporary and later replaced with a static IP address using configuration)
  • DHCP server is reachable by the DHCP protocol by the new networking device (either directly or with the help of DHCP relay)
  • DHCP server can be configured to send domain name and DNS server IP address in DHCP OFFER message along with the IP address.
  • Network administrator can add a host entry for into DNS server.


Step 0:

DHCP server configuration:

Administrator configures DHCP server to send DNS server IP address and domain name. The configuration steps depend on the DHCP server deployed in the network. This section shows the steps for Cisco IOS DHCP Server and Linux DHCP server.

Cisco IOS DHCP Server

ip dhcp pool test
  network 10.30.30.0 255.255.255.0
  domain-name xyz.com  dns-server 10.30.30.1  lease infinite


DNS server configuration:

Administrator creates and entry for PnP server in DNS server. The configuration steps depend on the DNS server deployed in the network. This section shows the steps for Cisco IOS DNS Server and Linux DNS server.

Cisco IOS DNS Server

ip dns server
ip host pnpserver.xyz.com 10.30.30.10


Step 1: Networking device is cabled and powered on. Since the startup configuration in NVRAM is empty, PnP agent is triggered and sends “Cisco PnP” in DHCP Option 60 in DHCP DISCOVER message.

Step 2: Since DHCP server is not configured to recognize “Cisco PnP” in Option 60, it ignores Option 60. DHCP server assigns an IP address and sends DHCP offer along with configured domain name and DNS server IP address.

Step 3: PnP agent reads domain name and formulates fully qualified PnP server hostname by appending domain name to the string “pnpserver”. If the domain name is “xyz.com”, fully qualified hostname of PnP server would be “pnpserver.xyz.com”. PnP agent resolves “pnpserver.xyz.com” for its IP address with the DNS server received in the DHCP options.

 


Cisco Cloud Redirection

Cisco Cloud Redirection is the third PnP Discovery mechanism. The PnP server is to be hosted as https://devicehelper.cisco.com. NTP clock is synced to the CCO server. The CCO server should also function as an NTP server. The trustpool is downloaded from http://devicehelper.cisco.com/ca/trustpool/ios.p7b. When the trustpool download and installation is successful, HTTPS hello is sent to the devicehelper.cisco.com. If trustpool download is unsuccessful or HTTPS hello to devicehelper.cisco.com fails we move on to the next discovery mechanism ie. NAPP.

 

NAPP (Neighbor Assisted Provisioning Protocol)




 

Mobile App


 


PnP server discoveryPnP Services

 

PnP protocol specification

PnP agent and PnP server exchange various PnP messages to perform various operations. The message semantics, schemas and transport bindings are defined by PnP protocol specification.

PnP transport protocol

PnP supports the following transport protocols.

  • 1) HTTP variants
    • 1a) HTTP
    • 1b) HTTPS

    HTTP as PnP transport protocol offers stateless communication and the communication is always initiated by PnP agent. HTTPS is same as HTTP with additional security and requires a crypto image. With HTTPS, the work flow requires the installation of certificates as a first step.

    During HTTP/HTTPS based workflows, the PnP agent sends the following message types to the server,

    • /pnp/HELLO
      • HTTP Method: GET
      • Description: PnP agent sends this message only during the discovery phase to ensure the discovered server is reachable.
      • Expected Response: 200OK
    • /pnp/WORK-REQUEST
      • HTTP Method: POST
      • Description: Work Request message is initiated by the PnP agent to check with the PnP server for any new work requests. PnP agent sends this message after discovering the server or when a PnP profile is configured and also at the beginning of every retry.
      • Expected Response: 200OK with one of the service methods which are described in the PnP Services chapter
    • /pnp/WORK-RESPONSE
      • HTTP Method: POST
      • Description: Work Response message is sent by the PnP agent to notify the server after completion of each Work Request initiated by the server to notify the status. The schema definitions for responses are defined in the XSD files of every service in the Response section.
      • Expected Response: 200OK with service method ‘Bye’ as defined in the schema pnp_work_info_body.xsd
  • 2) XMPP/Jabber variants
    • 2a) XMPP-starttls
    • 2b) XMPP-socket
    • 2c) XMPP-tls

    XMPP as PnP transport protocol offers stateful communication and the connection is persistent. PnP messages can be initiated by either PnP agent or PnP server.

PnP protocol specification

 

PnP services

PnP agent offers various services to enable PnP server perform various management operations. And these services (PnP Request and PnP Responses) are defined by XML schemas and XML documents are exchanges between PnP agent and PnP server. PnP Requests always originate from PnP server and PnP responses are sent by PnP agent for those requests.

If the transport protocol selected for PnP is either HTTP or HTTPS, PnP agent always initiates the connection by sending a PnP Work Request (message requesting PnP work request). PnP server sends the PnP Request depending on the management operation to be performed. Agent executes the work request and sends the PnP Response back. PnP server marks the end of the transaction by sending a PnP Bye message. This sequence repeats until there are no more work requests pending. Once all the work requests are serviced, PnP agent goes to sleep and calls back the server again after the configured time interval.



If the transport protocol is XMPP/Jabber variant, PnP server initiates the connection and sends the PnP Request. Agent executes the work request and sends the PnP Response back. One PnP Request and corresponding PnP response are treated as one transaction.

Every PnP message has a correlator that helps correlate between PnP Requests and PnP Responses.



PnP message format:

<pnp xmlns="urn:cisco:pnp" version="1.0" udi="UDI" usr="username" pwd="password">
  body
</pnp>

Parameter Description
udi Unique Device Identifier. A built in device id consisting of product id, version id, and the serial number. It is mandatory for all the messages that get exchanged between the PnP agent and the PnP server.
username Login username for the device and is applicable for all the messages that are sent from the PnP server to the agent. The only exception is the initial exchange when there is no configuration present on the new device.
password Login password for the device and is applicable for all the messages that are sent from the PnP server to the agent. The only exception is the initial exchange when there is no configuration present on the new device.
Body Body of the PnP message can be one of Info or request or response messages for various PnP services.
Example:

<pnp xmlns="urn:cisco:pnp" version="1.0" udi="PID:7206VXR,VID:V01,SN:34835437" usr="usr15" pwd="pwd15">
  body
</pnp>

The following sections describe the purpose and the XML attributes for all PnP services. Please see the corresponding XML schema for each service request and response. (add link to schema files here?)

Work Request

Purpose: Work Request message is initiated by the PnP agent to check with the PnP server for any new work requests. PnP agent sends this message after discovering the server or when a PnP profile is configured and also at the beginning of every retry. This is applicable only when the transport protocol is HTTP and HTTPS.

Type: info

URL: pnp/WORK-REQUEST

HTTP method: POST

Parameter Description
Correlator A unique string to match requests and responses between PnP agent and the server.
Udi Unique Device Identifier. A built in device id consisting of product id, version id, and the serial number.
authRequired Indicates whether the server needs to send username and password combination in further communications. Can be true or false.
viaProxy Indicates whether the message is initiated by the PnP agent itself or coming from a proxy. Can be true or false.
securityAdvise Security advisory message if applicable. For example, “Password in clear text in unsecured transport” is sent when HTTP transport is used.
Example:

<pnp xmlns="urn:cisco:pnp" version="1.0" udi="PID:WS-C3750X-24T-E,VID:V04,SN:FDO1703P2EB">
  <info xmlns="urn:cisco:pnp:work-info" correlator="CiscoPnP-1.0-1465-25A1212C">
   <deviceId>
    <udi>PID:WS-C3750X-24T-E,VID:V04,SN:FDO1703P2EB</udi>
    <hostname>Router</hostname>
    <authRequired>true</authRequired>
    <viaProxy>false</viaProxy>
    <securityAdvise>Password in clear text in unsecured transport</securityAdvise>
   </deviceId>
  </info>
</pnp>

Backoff connection

Purpose: Back off message is sent by PnP server to PnP agent to inform the PnP agent to connect back again after certain duration. In scenarios where PnP server is starved for resources (Example: too many devices trying to connect to the server after power outage), PnP sever can decide to throttle the incoming PnP agent connections with back off message. This is applicable only when the transport protocol is HTTP and HTTPS.

Type: request

URL: 200 OK for pnp/WORK-REQUEST

HTTP method: POST

Parameter Description Mandatory?
Correlator A unique string to match requests and responses between PnP agent and the server. Mandatory
Reason Reason for asking to back off Mandatory
Terminate Ask agent to not connect to server ever again. Remove any PnP profile/configuration. The request must contain either terminate or defaultMinutes or callbackAfter
defaultMinutes Change default backoff timer (which is 30 seconds) to this value. The request must contain either terminate or defaultMinutes or callbackAfter
callbackAfter Identifies callback duration parameters. Agent calculates the callback duration by combining the hours, minutes and seconds listed below and this is one time transient callback time. Default value is 15 minutes The request must contain either terminate or defaultMinutes or callbackAfter
Hours Part of callback duration: hours Optional
Minutes Part of callback duration: minutes Optional
Seconds Part of callback duration: seconds Optional

<pnp xmlns="urn:cisco:pnp" version="1.0" udi="PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V" usr="admin" pwd="password" >
  <request xmlns="urn:cisco:pnp:backoff" correlator="CiscoPnP-1.0-40907">
   <backoff>
    <reason>backoffNow</reason>
    <callbackAfter>
     <seconds>20</seconds>
    </callbackAfter>
   </backoff>
  </request>
</pnp>

Device Info

Purpose: Request to retrieve device information from PnP agent.

Request

Type: request

URL: 200 OK for pnp/WORK-REQUEST

HTTP method: POST

Parameter Description Mandatory?
correlator A unique string to match requests and responses between PnP agent and the server. Mandatory
Type Specifies the type of information being requested. Can take the following values
  • image
  • hardware
  • filesystem
  • udi
  • profile
  • all
 Mandatory
Example:

<pnp xmlns="urn:cisco:pnp" version="1.0" udi="PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V" usr="admin" pwd="cisco" >
  <request correlator="CiscoPnP-1.0-40830" xmlns="urn:cisco:pnp:device-info">
   <deviceInfo type="all"/>
  </request>
</pnp>

Response

Type: request

URL: pnp/WORK-RESPONSE

HTTP method: POST

Example:

<pnp udi="PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V" version="1.0" xmlns="urn:cisco:pnp">
  <response correlator="CiscoPnP-1.0-40830" success="1" xmlns="urn:cisco:pnp:device-info">
   <udi>
    <primary-chassis>PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V</primary-chassis>
   </udi>
   <imageInfo>
    <versionString>15.5(20140930:030825)</versionString>
    <imageFile>flash0:c3900-ipbasek9-mz.SSA</imageFile>
    <imageHash/>
    <returnToRomReason>reload</returnToRomReason>
    <bootVariable>flash0:c3900-ipbasek9-mz.SSA,12;</bootVariable>
    <bootLdrVariable/>
    <configVariable/>
    <configReg>0x0</configReg>
    <configRegNext/>
   </imageInfo>
   <hardwareInfo>
    <hostname>WSMA-3945</hostname>
    <vendor>Cisco</vendor>
    <platformName>CISCO3945-CHASSIS</platformName>
    </processorType>
    <hwRevision>1.0</hwRevision>
    <mainMemSize>1010827264</mainMemSize>
    <ioMemSize>0</ioMemSize>
    <boardId>FTX1503AH3V</boardId>
    <boardReworkId/>
    <processorRev/>
    <midplaneVersion/>
    <location/>
   </hardwareInfo>
   <fileSystemList>
    <fileSystem freespace="141590528" name="flash0" readable="true" size="512065536" type="disk" writable="true"/>
    <fileSystem freespace="155774976" name="flash1" readable="true" size="256507904" type="disk" writable="true"/>
    <fileSystem freespace="248779" name="nvram" readable="true" size="262136" type="nvram" writable="true"/>
   </fileSystemList>
  </response>
</pnp>

Image Install

Purpose: Request to install a new image on the network device.

Request

Type: request

URL: 200 OK for pnp/WORK-REQUEST

HTTP method: POST

Parameter Description Mandatory?
correlator A unique string to match requests and responses between PnP agent and the server. Mandatory
location under source Specifies URL of the image to be copied Either location or uri is used.
uri under source Specifies URI of the image to be copied w.r.t. PnP server IP address/hostname with HTTP or HTTPS protocol Either location or uri is used.
checksum Checksum of the image Optional
location under destination URL where the image needs to be copied on the device. If not specified, PnP agent will pick a disk which has enough space to hold the image. Optional
Example:

<pnp udi="PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V" version="1.0" xmlns="urn:cisco:pnp">
  <request correlator="CiscoPnP-1.0-40830" xmlns="urn:cisco:pnp:image-install">
   <image>
    <copy>
     <source>
      <location>http://10.10.10.19/images/isr4400-universalk9.20140420.bin</location>
      <checksum>1eb1e2853f413a76fa7199147b34d324</checksum>
     </source>
     <destination>
      <location>flash0:</location>
     </destination>
    </copy>
   </image>
   <reload>
    <reason>pnp image installation</reason>
    <delayIn>0</delayIn>
    <user>admin</user>
    <saveConfig>true</saveConfig>
   </reload>
  </request>
</pnp>

Response

Type: request

URL: pnp/WORK-RESPONSE

HTTP method: POST

Parameter Description
correlator A unique string to match requests and responses between PnP agent and the server.
Success 1 – success
0 – failure
errorInfo Captures all the error response messages
errorSeverity Severity
errorCode errorCode
errorMessage Error message string
Success Example:

<pnp xmlns="urn:cisco:pnp" version="1.0" udi=" PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V" usr="admin" pwd="cisco" >
  <response correlator="CiscoPnP-1.0-40830" xmlns="urn:cisco:pnp:image-install" success="1"/>
</pnp>

Failure Example:

<pnp xmlns="urn:cisco:pnp" version="1.0" udi=" PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V">
  <pnp xmlns="urn:cisco:pnp" version="1.0" udi=" PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V">
   <errorInfo>
    <errorSeverity>ERROR</errorSeverity>
    <errorCode>PnP Service Error (1804)</errorCode>
    <errorMessage>Config-register cannot be 0x0</errorMessage>
   </errorInfo>
  </response>
</pnp>

Config Upgrade

Purpose: Download and update the configuration on the device with the specified configuration.

Request

Type: request

URL: 200 OK for pnp/WORK-REQUEST

HTTP method: POST

Parameter Description Mandatory?
correlator A unique string to match requests and responses between PnP agent and the server. Mandatory
details Level of error messages expected in the response Optional
location URL of configuration file Mandatory
applyTo Specifies target configuration file on the device
  • startup
  • running
startup is the default 		Optional
abortOnSyntaxFault Presence of this element indicates that the config upgrade process will abort when an error is encountered Optional
Example:

<pnp xmlns="urn:cisco:pnp" version="1.0" udi="PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V" usr="admin" pwd="cisco" >
  <request correlator="CiscoPnP-1.0-40833" xmlns="urn:cisco:pnp:config-upgrade">
   <config details="all">
    <copy>
     <source>
      <location>http://10.10.10.15/c3945_access.cfg</location>
     </source>
    </copy>
   </config>
  </request>
</pnp>

Response

Type: response

URL: pnp/WORK-RESPONSE

HTTP method: POST

Parameter Description
correlator A unique string to match requests and responses between PnP agent and the server.
Success 1 – success
0 – failure
errorInfo Captures all the error response messages
errorSeverity Severity
errorCode Error code
errorMessage Error message string
serviceLog Provides detailed log messages
Success Example:

<pnp xmlns="urn:cisco:pnp" version="1.0" udi="PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V" usr="admin" pwd="cisco" >
  <response correlator="CiscoPnP-1.0-40833" xmlns="urn:cisco:pnp:config-upgrade" success="1"/>
</pnp>

Failure Example:

<pnp udi="PID:CISCO3945-CHASSIS,VID:V02,SN:FTX1503AH3V" version="1.0" xmlns="urn:cisco:pnp">
  <response correlator="CiscoPnPPro-1.0-config_upgrade-40833" success="0" xmlns="urn:cisco:pnp:config-upgrade">
   <errorInfo>
    <errorSeverity>ERROR</errorSeverity>
    <errorCode>PnP Service Error 1402</errorCode>
    <errorMessage>Invalid input detected</errorMessage>
   </errorInfo>
   <serviceLog>
    show arp
    ^
    % Invalid input detected at '^' marker.
   </serviceLog>
  </response>
</pnp>

Bye

Purpose: Bye message is sent by the PnP server to acknowledge the receipt of PnP response and also signal the end of the transaction. This is applicable only when the transport protocol is HTTP and HTTPS.

Type: info

URL: 200 OK for pnp/WORK-RESPONSE

HTTP method: POST

Parameter Description Mandatory?
Info Indicates that the message type is info. Mandatory
workInfo Identifies work info related parameters Mandatory
Bye Indicates to the PnP agent not to come back again until the expiry of polling interval Mandatory
Example:

<pnp xmlns="urn:cisco:pnp" version="1.0" udi="PID:WS-C3750X-24T-E,VID:V04,SN:FDO1703P2EB">
  <info xmlns="urn:cisco:pnp:work-info" correlator="CiscoPnP-1.0-1465-25A1212C">
        <workInfo>
    <bye/>
   </workInfo>
  </info>
</pnp>