Course contents

Unit 5: Onboarding and trustLesson 5.2 (2 of 5 in this unit)22 of 27 in the Cisco SD-WAN course

PnP/ZTP orchestration and prerequisites

How Plug and Play and zero-touch provisioning bring a new WAN Edge online: the order of the chain, what must be prepared first, and where a stalled device is stuck.

Intermediate · 9 min read

You'll learn to describe how a new WAN Edge finds its controllers without anyone typing a configuration, list what has to be prepared first, and say where in the chain a stalled device is stuck.

Technical definition

PnP (Plug and Play) and ZTP (zero-touch provisioning) are automated onboarding methods. A new router is cabled to a network, gets an address, finds a Plug and Play server, is told where its Validator is, and then builds its control connections. PnP is the method used by IOS XE SD-WAN routers. ZTP is the name used for the equivalent process on older Viptela OS routers (vEdge).

A box shipped to a site with nobody who can configure it

A new router for BR-02 is delivered to a small site. Nobody there knows the controller addresses, the organisation name or the system IP, and nobody should have to. PnP is designed for this: the router powers up, finds out who it belongs to and where to connect, and the site team only cables it. The work moves earlier, into preparation: the router's serial number must already be known to the right place, with a profile that says where its Validator is.

The chain, in order

How a new branch router finds its controllers
How a new branch router finds its controllersA new router powers on at the branch with only a WAN address from DHCP. It contacts the Plug and Play service, which points it at the Validator for the organisation. The Validator authenticates the device and hands it the Controller and Manager addresses. The router builds control connections to both, the Manager pushes its template and the router joins the overlay.New edgeDHCP address onlyInternetPnP / VAL-01authenticatesCTRL-01 and Managerafter the Validator1. Find the Validatorvia PnP or manual2. Authenticateserial and certificate3. Learn controllersaddresses returned4. Template pushedrouter joins overlayStalled? Check the authorized list first, then the clock and the certificate.

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Authentication comes before configuration. A router that is not in the authorized list, or whose certificate does not match, never gets past the Validator, so check there when onboarding stalls.
The onboarding chain
The onboarding chainPower on, find the portal, get redirected, get the bootstrap.Power onDHCP addressDNSfind the portalPortalredirectsValidatorand controllers

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Each link must work.
  1. The router starts in controller mode. A device that runs in standalone mode does not look for SD-WAN controllers. Hardware ordered for SD-WAN usually ships ready for this; check your release and model.
  2. It gets an address. Normally from DHCP on its uplink, with a default gateway and a DNS server. Without these, nothing later can happen.
  3. It finds a PnP server. Through a DNS name built into the software, a DHCP option, or an address configured by the administrator. The exact discovery methods are release dependent.
  4. The PnP server recognises its serial number. The serial must have been added to the organisation's account in advance, with a controller profile attached.
  5. It learns the Validator and the organisation name. These come from the profile, so the router does not need a typed configuration.
  6. It builds control connections. First to the Validator, which introduces the Controller and Manager. After that the router joins the fabric and can receive a configuration. See Control Component Workflow.
  7. Configuration is pushed. A template or a configuration group attached to the device in the Manager sets the real settings. See Templates and Configuration Groups.

What has to be prepared first

PrerequisiteWhy it matters
The serial number is registered with the PnP serviceThe server answers only for devices it knows. An unknown serial gets no profile.
A controller profile exists and is attached to the deviceIt carries the Validator address and the organisation name (here LAB-EXAMPLE, for the lab).
The device is on the authorisation list in the ManagerSee PKI and Certificates. Without it the control connection is refused.
The Validator is reachable from the siteIts address must be routable, and any firewall or NAT must allow the control connection. See NAT, DNS and Firewall.
DHCP, a default route and DNS on the site uplinkThe router has no configuration yet, so it relies on what the network hands out.
A template or configuration group is ready to attachOtherwise the router connects and then has nothing to run. See the later part of this unit.

Whether the PnP server is the Cisco cloud service or one run by the organisation, and how the Manager is linked to it, differ by deployment. Treat the table as a checklist of ideas and use your release's guide for the exact screens.

What to prepare first
What to prepare firstPrepare the portal and the Manager before shipping.Device in the portalSerial number addedController profilePoints to the ValidatorTemplate readyAttached when the device joins

On small screens, swipe sideways or focus the diagram and use the arrow keys.

The device needs a plan to join.

PnP on a device

On an IOS XE router that is still discovering, the PnP process can be examined from the console. The command exists on IOS XE devices; its output format depends on the release, so the sample below is a simplified written example, not a capture.

Example output written for this lesson, simplified; real output has more fields and a different layout
BR-02#show pnp status
PnP agent: running
Discovery: in progress
Server: not yet reached
Last error: none recorded
The router is still looking for a PnP server. If it stays here, the usual causes are no address from DHCP, no default route, or DNS that cannot resolve the discovery name. If the line for the server shows a server but there is no profile, the serial number is probably not registered.

If you also have the console log, read it from the top. PnP failures usually print a reason, such as no reply from a server or an authentication failure. The exact wording differs by release.

Where a stalled device is stuck

Where a stalled device is stuck
Where a stalled device is stuckStuck at; Check. No address: The uplink port, the cable, the DHCP scope, and whether the port is in the right VLAN Address but no PnP server: Default route, DNS, a firewall that blocks the outbound request Server reached, no profile: The serial number in the PnP account, and that a controller profile is attached Profile received, no control connection: The Validator address, organisation name, authorisation list, clock Connected, no configuration: A template or configuration group must be attached to this deviceStuck atCheckNo addressThe uplink port, the cable, the DHCP scope, and whether the port is in theright VLANAddress but no PnP serverDefault route, DNS, a firewall that blocks the outbound requestServer reached, no profileThe serial number in the PnP account, and that a controller profile isattachedProfile received, nocontrol connectionThe Validator address, organisation name, authorisation list, clockConnected, no configurationA template or configuration group must be attached to this device

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Each item on the left, with what it means on the right.

In practice, most stalled devices are stuck in the first three rows, which are plain IP problems. Check the site uplink before suspecting the SD-WAN settings.

Where a device stalls
Where a device stallsNetwork, portal or authorisation.Stalled deviceNetworkDHCP or DNS failsPortalnot in the portalAuthorisationnot allowed

On small screens, swipe sideways or focus the diagram and use the arrow keys.

Check in this order.

Learn more: Transport-Side IP and ISP ReachabilityValidatorControl Connections (DTLS and TLS)

Mistakes in automated onboarding

  • Shipping the router before the serial number is registered. The device then has nowhere to go, and the site has no way to fix it.
  • Using one controller profile for every site without checking that each site can reach the Validator address in it.
  • Assuming PnP also configures the router. It gets the router connected; the Manager still has to push the configuration.
  • Mixing up PnP and ZTP in notes. They are for different software trains, and the commands and portals differ.

Test yourself on automated onboarding

Predict · scenario 1

A new IOS XE router at BR-02 is powered on and cabled to an uplink with no DHCP server. It does not reach a PnP server. What is the most likely reason?

Predict · scenario 2

PnP reached the server but the router received no controller profile. Which check fits best?

Predict · scenario 3

Which pairing of terms to platforms is correct?

Predict · scenario 4

A router connected to the Validator and shows control connections up, but it forwards nothing useful and has no site-specific settings. What was probably missed?

FAQ

Is PnP the same as ZTP?
They do the same job on different software. ZTP belongs to the older Viptela OS routers, and PnP to IOS XE routers such as the Catalyst 8000 family. Documents and exams use both words, so read which platform is meant.
Does a virtual router such as the Catalyst 8000V use PnP?
It can in some designs, but a virtual router has no factory serial number to look up, so it is commonly onboarded with a chassis number and token entered by hand, as in the next lesson. What your release supports for virtual routers is release dependent.
What if the site has no DHCP server?
Automated discovery normally starts with an address from DHCP, so a site without DHCP needs the address typed in, which is the manual method. Some designs use a DHCP service on the uplink device for this purpose.