In the absence of
DHCP or Domain Name System (DNS) servers, an existing up and running Open
Plug-n-Play (PnP) enabled device in the neighborhood network can be configured
to act as a Cisco Open Plug-n-Play (PnP) Neighbor Assisted Provisioning
Protocol (NAPP) server.
The NAPP server is
part of PnP discovery phase. This server is invoked when the PnP Autonomic
Networking based discovery (AN), DHCP, DNS, Cisco Cloud service (CCO) discovery
mechanisms fail to connect to the PnP server.
This device listens
to a specific port for any incoming PnP messages. The Cisco device which is
trying to come up as a PnP device sends a UDP broadcast message to its network
every 30 min for ten times. Hence, if the device does not receive a response,
the broadcasts stop after 300 min.
Figure 8. DNS Lookup for
Layer 3 and Layer 2 Devices
When the device
hosting the proxy server process receives the incoming broadcasts, it verifies
the version field in the request and forwards the request to the PnP server if
version validation is successful. The proxy server process also caches the
unique device identifier (UDI) of the requesting client coming in via incoming
datagram before forwarding the request to PnP server.
Upon receiving the
configlet datagram from PnP server, the proxy server validates UDI in the
incoming datagram with the entries in the UDI cache. If validation is
successful, proxy server process broadcasts the datagram to a specific port
number reserved for the proxy client processes to receive datagrams.
Upon receiving the
datagrams, devices running proxy client processes, parse the incoming datagram
for the target UDI. If the target UDI in the datagram matches the UDI of the
device, proxy client process proceeds with framing, error control and
configuring the configlet.
If the target UDI in
the datagram fails to match UDI of the device, the packet is dropped.