Skip to content 
In recent years, we’ve seen the rise of a concept known as “zero-touch” network provisioning (ZTP). The idea behind ZTP is to enable network engineers to deploy and configure network devices in a large-scale environment without human intervention by automating most of the repetitive manual tasks.
In the past, devices were typically deployed in multiple steps, including powering up the device, OS checks, and upgrades, all of which were done manually by a technician, followed by configuration using CLI. In large-scale environments, these deployments would take weeks and months, exposing significant provisioning errors. Instead, with ZTP, the managed device now learns the required information from the network and provisions itself automatically – all with the correct settings, configurations, and images.
Anuta Networks ATOM, the Vendor Agnostic Platform, facilitates individual device configurations within an easy-to-use graphical environment that leverages the power of Zero Touch Provisioning. Once you have created your customized configuration file with the required parameters, connecting new devices to the network is a breeze. Equipped with a highly scalable architecture rooted in microservices, it speeds up the deployment of thousands of devices, enabling organizations to focus on their use cases without having to worry about deployment specifications. Want to learn more: https://www.anutanetworks.com/features/zero-touch-provisioning/.
So, what exactly is ZTP?
ZTP might mean different things to different customers. In my experience, for the majority, ZTP is a blueprint to provision golden configurations automatically on a brand-new device just out of the factory. Once the device is unboxed and plugged into the network, it gets an IP address from the DHCP server, the bootstrap config and image from the file server, and finally, the golden configuration is pushed onto the device. All of these steps are executed without any human intervention.
For some customers, the ZTP process goes beyond this and includes configuration compliance checks and remediation, software compliance checks and remediation, the creation of DNS entries for the device in the IPAM system, and finally, adding the device to the inventory and monitoring systems. Once again, all of these steps are executed without any human intervention.
For a few other customers, ZTP can be as simple as shipping devices to a site location with some base configurations that enable remote access to the device, after which a network automation system like ATOM would manage the device and push the golden configurations for end-to-end service management.
Using ZTP the right way- with ATOM
As with any other labor-saving mechanism, ZTP, too, can lead to roadblocks if not used correctly.
Some of the most common issues include:
- Network connectivity issues between the device, DHCP Server, Image Server, and external systems could be caused to due to several reasons–
- Missing configurations on network ports
- Firewall ports to be opened
- Missing DHCP relay configuration
- Additional routing configurations to be enabled
- The DHCP server is not configured correctly with option 150, and the file server IP address
- Appropriate configuration files and OS images are not available on the File Server
- The device does not have sufficient memory to support an OS upgrade
- Inability to log into the device due to incorrect login credentials
- A particular stage in the ZTP process takes too long to complete and times out
- A device might not come up and is unreachable after a reboot
A complete ZTP platform needs to keep track of these issues during provisioning. ATOM does this by supporting custom-built workflow automation. It includes sufficient error checks at every stage of the ZTP process in order to monitor various provisioning actions with the added flexibility to retry or skip any stage. Finally, these workflows are consolidated into a centralized dashboard to minimize manual efforts and accelerate deployments.
What are some of the most common zero-touch provisioning use cases?
Let’s start with the basics to understand how Anuta ATOM workflows support different flavors of ZTP use cases.
As the DHCP servers are configured, the ATOM file server is loaded with the appropriate device boot config and image files. The ZTP-enabled device gets a DHCP IP address once powered on and plugged into the network.
The DHCP server also provides information about the ATOM file server to fetch the device boot config and image. Depending on the vendor and the device model, the boot config file is requested first, followed by the image file or the other way around. For specific device models, additional software patches might have to be deployed on the device. ATOM workflows are designed to handle all of these different scenarios across a vast multi-vendor environment.
When the device requests the ATOM file server for a config file or the image file, the ATOM workflow engine gets notified and triggers a workflow instance for that particular device. This workflow instance monitors for the successful completion of config download and image upgrade on the device.
Figure 1: A Typical ZTP Call Flow using ATOM
Figure 2: Example of ATOM ZTP Workflow
In this scenario, ATOM performs a few checks before the device is onboarded. These checks include ensuring that the device has an IP address from a valid range and is not a rogue device requesting access. Additionally, the device’s serial number can be checked against the inventory list.
ATOM facilitates the golden or the day-0 configuration generation in a few ways–
- A base configuration snippet for each device supported by its serial number can be pre-loaded into the ATOM file server. This configuration snippet is picked and pushed once the device is onboarded into ATOM.
- Another approach is to define parameterized command templates in ATOM and reference them in the workflow. Some device-specific parameters, like hostname, can either be a user input or derived based on a predefined logic or fetched from an inventory database. ATOM workflows are flexible to accommodate all these different options.
Figure 3: Example of Command Templates in ATOM
Anuta ATOM’s ZTP can go beyond pushing golden configurations. Here is one example where a device is added to Infoblox IPAM, Aruba ClearPass Security Policy Management System, and BMC inventory management system, in addition to Configuration and Software Compliance checks.
Figure 4: Example of an Extended ZTP Use Case
ATOM predefines configuration compliance policies that can be referenced in the workflows during the ZTP process. When a device is onboarded, it retrieves the configurations automatically. The compliance policies can either be executed off of the latest archived copy or fetched from the device’s current configuration. ATOM raises an alert in the event of any violations, with added flexibility to raise a trouble ticket in an external system like ServiceNow. The remediation of the detected configuration violations can also be automated if required.
Figure 5: Example of a Configuration Compliance Policy
ATOM also predefines software compliance policies based on vendor, device family, and model. IT operators can specify three compliant versions of software concurrently; the current, previous, and future versions. These policies can be referenced in the workflow, and in case of any violations, the device can be upgraded or downgraded per policy definition to ensure compliance.
Figure 6: Example of a Software Compliance Policy
Following compliance checks, ATOM creates DNS records for the device in infoblox. In this example, the device is then added to the device group in Aruba ClearPass and the BMC Inventory system. While few systems use simple password authentication to initiate the transaction, an authentication token is required in others, like BMC. ATOM uses vendor-published APIs to interact with these external systems.
ATOM also incorporates checks to ensure that the device or the DNS records are not present in these systems by fetching the data using GET calls before placing the POST, PATCH, or PUT calls to these systems. It performs sufficient error checks at every stage in the workflow, with an option to retry or skip any workflow stage if required.
All of the information required for the ZTP workflow to provision the device is pre-populated in ATOM for easy reuse. This information includes device login credentials, device drivers, configuration and software compliance policies, external systems like Infoblox, BMC, Aruba endpoints, authentication details, etc. This makes the ZTP process a true zero-touch without any human interaction till the end unless in case of any errors where an operator review might be required.
Figure 7: Information required during the ZTP Process
As illustrated in this use case, ATOM Workflow is quite powerful in integrating a typical ZTP process with configuration and software compliance, 3rd party integrations, all with minimal human intervention
Summary
While ZTP can significantly improve deployments by reducing costs, errors, and time– having the right toolset can be a competitive advantage. Anuta Networks ATOM takes ZTP to the next level with its comprehensive device onboarding and compliance checks. Incorporating a graphical interface, it empowers operators to set up a new network from anywhere and leverage massive scalability with microservices and extensible architecture– all in a cloud-ready platform.
With these features supporting a variety of use cases, ATOM offers a true multi-vendor Zero-Touch Provisioning solution that transforms how teams onboard network devices.
Additional Contributors: Manisha Dhan
