Automation Win: Zero-Touch Provisioning

Listening to the networking vendors it seems that zero-touch provisioning is a no-brainer … until you try to get it working in real life, and the device you want to auto-configure supports only IP address assignment via DHCP, configuration download via TFTP, and a DHCP option that points to the configuration file.

As Hans Verkerk discovered when he tried to implement zero-touch provisioning with Ansible while attending the Building Network Automation Solutions course you have to:

  • Use a DHCP server to assign IP addresses to devices, combined with a TFTP server to push initial configuration to newly-attached devices;
  • Detect a new IP address has been assigned by DHCP server;
  • Find the MAC address associated with the IP address if you want to provision devices based on their MAC address. He used ARP cache to find it;
  • Generate SSH keys on the device and add those keys to known_hosts file (you could also turn off key checking… maybe not such a great idea);
  • Generate the final device configuration;
  • Push the configuration to the device.

All his playbooks are on Github – explore and adapt them, and submit a pull request when you improve them ;)

In October 2020 Hans ported his ZTP solution to Nornir.

Notes:

  • Before doing anything else, go and read the awesome Zero-Touch Provisioning DIY Tutorial by Patrick Ogenstad.
  • Some vendors neatly solved the problem with automated procedures that can do anything from figuring out where their device is in the network to upgrading software and downloading tailored configuration. Similar to network automation RFP requirements, make ease of zero-touch provisioning using a well-documented standards-based approach a mandatory requirement when buying the next batch of hardware;
  • If you have to provision Cisco Catalyst switches, check out the FreeZTP server;
  • I know someone who solved the same problem with Salt – have to persuade him to talk about it one of these days.

This blog post was initially sent to the subscribers of my SDN and Network Automation mailing list. Subscribe here.

8 comments:

  1. What is the progress of the vendors based on your network automation RFP requirements until today?
    Replies
    1. Slightly better, but nothing major. I think Arista made the most progress. Have to update that blog post...
    2. My arista switches are running a python script they download and run on boot that uses Ansible Tower's callback functionality to kick off a job that configures them from zero to hero.

      You need to define a DHCP entry for them first, but after that it gets handled for you.

      It's been a lot cleaner to work with than the nexus POAP setup.
  2. The other problem is non-automatable steps. E.g. Juniper QFX 5100 - ZTP works fine, but if you want a virtual chassis, you need to issue one extra command on the CLI.
  3. Ivan - Check out Big Switches ZTP implementation...I think you'll be impressed
    Replies
    1. Still no public documentation on their web site (yeah, I know I'm supposed to get it when downloading the community edition but nonetheless...) so I'm still not impressed ;)
    2. http://go.bigswitch.com/rs/974-WXR-561/images/Dell%20EMC%20Big%20Cloud%20Fabric%20Guide%20with%20VMware%20vSAN%201.0.pdf

      There is a little information in here...but at least these guys got wise and took out the middle man. They use ipv6 link-local addressing with a combination neighbor discovery to locate the controllers. The caveat being that the controllers need to be L2 adjacent with the switch mgmt ports that they hope to provision. Still...its better than anything dhcp related with all the options and image repos involved.
    3. There's absolutely no useful information there, but fortunately they use ONIE which is well documented. Based on what you told me I'm assuming BCF is doing this:

      https://opencomputeproject.github.io/onie/design-spec/discovery.html#discover-neighbors

      It's definitely in the "how much brute force do you want to apply" category.

Add comment
Sidebar