One of the attendees of my Building Next-Generation Data Center course asked this interesting question after listening to my description of differences between Chet/Puppet and Ansible:

For Zero-Touch Provisioning to work, an agent gets installed on the box as a boot up process that would contact the master indicating the box is up and install necessary configuration. How does this work with agent-less approach such as Ansible?

Here’s the first glitch: many network devices don’t ship with Puppet or Chef agent; you have to install it during the provisioning process.

Also, you can start using Puppet or Chef only after the box has been received at least some minimum configuration. For example, even if you’d have a Puppet agent on the box, it wouldn’t know what the IP address of Puppet server would be.

For these (and other) reasons most vendors implement Zero-Touch Provisioning (ZTP) along these lines:

• When a box boots without usable configuration, it sends out DHCP requests.

Whether the DHCP requests are sent only on management interfaces or all interfaces is a minor implementation detail in the scope of this blog post and a very important security consideration in real life.

• DHCP server replies with IP address and whatever other parameters (standard or vendor-specific) have been configured;
• The extra parameters passed in DHCP reply could include a URL to download scripts or configurations from, or boot file (initial configuration) to load;

If the initial switch configuration includes Puppet agent, then it would eventually connect to Puppet server and pull down the desired device state.

If you’re using Ansible then the DHCP reply could trigger a script that would run an Ansible playbook that would eventually push desired configuration to the device.

From Theory to Practice

I sent my reply to David Barroso (he has orders of magnitude more real-life experience in this area than I do) and this is what he told me:

The only problem with the puppet agent is that you need to install it and traditional ZTP implementations don't have a good way of installing extra software. However, what most vendors do nowadays is that rather than pushing a configuration file, they give you an IP and a hostname as always, and then they give you a script that will be executed on the machine.

That way you can "curl" your configuration or generate it on the fly with code, install all necessary software, trigger Ansible via some API, check cabling is correct, register to an inventory database... you get the idea, whatever you want to do as part of your provisioning workflow. Both Cumulus and EOS can do that, not sure about others though.

Want to know more?

• Start with Network Automation 101;
• Register for the Network Automation Tools webinar to get initial orientation;
• We’ll discuss numerous network automation use cases during winter 2016/17;
• Ansible is the go-to tool for many network automation projects, and I’ll be rolling out tons of new content this autumn;

Finally, why don’t you go on a journey that will help you deploy your first network automation solution?