Sidebar

Zero Touch Provisioning

Articles » Automation for Cisco NetDevOps » Zero Touch Provisioning

This article was written by Andrea Dainese, senior network and security architect, and author of UNetLab (now EVE-NG and Route Reflector Labs.

ZTP, or Zero Touch Provisioning, is a feature that allows you to provision and configure devices automatically. In other words, ZTP is the process that moves a device from an out-of-the-box state to a fully configured state.

Some devices include this feature as the primary means of deployment (like Cisco Meraki or Cisco SD-WAN solution), others offer it as a secondary way of installation and configuration (Nexus, IOS-XE...).

Overview

The installation of new (unconfigured) devices is part of a process that should be well defined and documented. For example, consider how will a newly-employed technician learn how to provision a new switch?

Keep in mind that the installation part is only the first step of device lifecycle management. Next steps are related to maintenance, operation, upgrades, decommission...

Which steps should be included in a ZTP process? We can include:

  • making the device reachable;
  • firmware upgrade;
  • base configuration (DNS, NTP, RADIUS...)
  • specific configuration (VLANs, interfaces, routing protocols...)

Let's move now to the maintenance and operation phases. Which previous tasks are included?

  • Firmware upgrade
  • Configuration management (changes, audit, backup)

The only step unique to ZTP is initial device reachability... and because we must develop a process for the entire lifecycle management of the device anyway, we should avoid duplicate effort and focus only on the first step: once a device is online and reachable, we can start the regular lifecycle management process.

If we use ZTP to upgrade devices during the first boot, we have to manage two different pipeline:

  • upgrading the firmware during the provisioning;
  • upgrading the firmware after the initial provisioning (operation).

What if we just make the device reachable during the provisioning phase and we leave everything else to the operation phase? We should, at least, evaluate pros and cons of both approaches within our team.

Again, before starting with a technology, be sure you understand the big picture.

More on Zero-Touch Provisioning

ZTP on Cisco Nexus switches

To illustrate the above concepts, let's see how ZTP works in Cisco Nexus switches. When a NX-OS switch boots, the POAP (PowerOn Auto Provisioning) process tries to download a Python script via TFTP. The script can be used to automatically install the right NX-OS version and configure the whole switch. Cisco provides an official customizable script, but as always there are many alternatives.

However:

  • At the moment POAP supports Python 2 scripts, and Python 2 will be in EOL in less than 1 year (January 1, 2020);
  • Developing and maintaining POAP scripts can be flexible but complex;
  • POAP works only for Cisco Nexus switches.

Reviewing a simple POAP script we realize that's not so simple and it's valid only for NX-OS switches.

Using POAP just to make the device reachable simplifies the development and the maintenance of the auto provisioning script... and as discussed above you have deploy tools to deal with device configurations and firmware upgrade anyway, so don't cram those operations into POAP script.

References

ZTP on Cisco IOS-XE (AutoInstall)

Cisco IOS-XE (and Cisco IOS) based devices try to automatically download a configuration file during the first boot. This feature is called AutoInstall and it's simple: when a IOS device boots, the AutoInstall process tries to download a the configuration via TFTP. This behavior can be disabled with: no service config.

If a custom TFTP server is used, the configuration provided to the device can be built with information gathered from DHCP Server (looking up the MAC address from the IP address) and from CMDB/IPAM (looking up the static management address for the device).

Latest releases of Cisco Catalyst 9k implements a ZTP process using Python 3.0 . The idea is similar to POAP scripts on Cisco Nexus, but the implementation is different, so you can't reuse your POAP scripts on Catalyst 9k.

References

When Andrea is not writing about network automation tools he's busy automating Cisco ACI environments. To learn more about what he's doing, and whether he might be able to help you doing something similar, contact him through email, LinkedIn or on Twitter.