One of the hottest technologies in networking right now is Software Defined WAN (SD WAN), and pretty much every solution touts Zero Touch Deployment (ZTD) as a key feature. ZTD for SD WAN involves connecting a new device to the LAN and WAN at a site and it will magically become part of the corporate WAN without any need to have pre-configured the device, shipped a flash drive to site, or have smart hands on site configuring it.


It seems then that SD WAN has pretty much nailed the concept of “plug and play” configuration; but what does this have to do with Network Management?

 

Managing New Devices

 

We have plenty of ways to manage the addition of new devices to our networks. Perhaps the most obvious example is DHCP, which alleviates the need to manually configure IP addresses, masks, gateways, and DNS servers on new end points. Server administrators have largely addressed the wider issue of initializing new hosts; DHCP and PXE can bring up an uninitialized server (or VM) on the network and have it automatically install a specified OS image. Beyond that, tools like Puppet and Chef pre-installed on the base image can then allow the automatic installation and configuration of services OS, and can be used for configuration management and validation from then on.

 

It would be nice if adding a new device to the network were that easy. Can our management systems do that for us? Sure, we can use DHCP to give a device a management IP address, but what about taking it to the next step by installing software and configuring it?

 

Some Existing Technologies

TFTPBOOT

 

You could argue that Cisco is the granddaddy of automatic installation, as they have supported tftpboot for software images and configuration files for many years now, but even ignoring the unreliability of TFTP for data transfers, it has been a distinctly flaky system, and requires configuration on the end system to get the desired results.

 

DHCP

 

IP phones have in general addressed this issue a little bit more intelligently, using DHCP options to provide them with important information. Cisco use DHCP Option 150 to tell the phone where to download its configuration file, which for a new phone will mean starting the registration process with Call Manager. This is a little odd, because DHCP already has Option 66 to define a TFTP server, but Cisco is not alone. Avaya, for example, can use Option 176 to override Option 66 and provide a list of information to the client, including the Media Gateway server IP and port. ShoreTel avoid TFTP, and provides the ShoreTel Director IP along with other information via DHCP Options 155 and 156.

 

Looking at this, I see two clear –but common– elements at play:

 

  1. DHCP is incredibly flexible. Information can be delivered to end clients giving them a wide range of information which could help them determine where to boot from, what image to run, and what configuration file to load.
  2. DHCP is incredibly flexible. This means that vendors have used that flexibility to deploy their applications in the way that best suited them, and do not seem to share a common approach. Equally interesting, some of the DHCP options being used are in conflict with the existing formally assigned definitions.

 

Network Device Management

ONIE

 

I’d argue that the reason PXE has been so successful in the server world is because it’s a single standard that’s implemented consistently regardless of vendor. The Open Network Install Environment (ONIE) –contributed to the Open Source community by Cumulus Networks– is trying to do the same thing for network devices, with a typical use case being the deployment of an uninitialized bare metal switch triggering the download of the customer’s chosen network operating system. Once the switch boots the new OS though, we’re typically back to vendor-specific mechanisms by which to obtain configuration.

 

Puppet and Chef

 

Puppet and Chef are a great concept for initial configurations, and Juniper’s inclusion of a Puppet Agent in Junos on some of their platforms is certainly a nice touch, but it becomes rapidly obvious both from the perspective of limited feature support and the concept of periodic polling by the agent (the default is every 30 minutes) that Puppet really may not be the best “real time” device management solution.

 

One DHCP to Rule Them All

 

So here’s a straw man that you can set fire to as needed. What if –stop laughing at the back– we decided to use DHCP to provision a new device with everything it needed to get on the network and be manageable? Let’s set up DHCP options to send:

 

  • IP / Mask / Default Gateway
  • Optional directive to make the IP your permanent IP (and not use DHCP on the next boot)
  • Management network host routes as needed
  • Device hostname and domain
  • Name servers (DNS)
  • SNMP RO strings
  • SNMP ACLS
  • A directive (sounds like Puppet here) to enable SSH and generate keys, if needed.
  • A URL to register itself with network management system

 

This much would get the device on the network and make it manageable using the NMS. Maybe we take it that a step further:

 

  • Like PXE, a host to ask for your boot image (include logic to say “if it differs from what you already have”), so that a new device will load the standard image for that platform automatically.
  • A path to a configuration file perhaps?

 

If this was supported across multiple vendors, in theory a device could be connected, would add itself to the NMS (and have the right ACLs to allow it), would have the correct code that we wanted running on it, would load a specific or default configuration from a path we pointed to. Configuration from this point onwards would have to be using some other mechanism, but at least we achieve the goal of ZTD without using an entirely new protocol. All we need on our side, is a script that maps device properties to a management MAC address (ideally), or that automatically provisions devices based on the vendor/device type and location.

 

Genius or Crazy?

 

Would this help? Would it be good if a device could register itself automatically in NMS? What else would you need? Let’s either build this up or tear it down; is this the best idea in the world or the most stupid?

 

I look forward to your opinions. And hey, if this turns out to be a world-changing idea and takes off, I’m going to call it TugBoot or something like that. It’s only fair.

 

Please let me know.