Templates vs. Policies

Templates vs. Policies

Are configuration templates still needed with an automation framework? Or does the automation policy make them a relic of the past?

Traditional Configuration Management: Templates

We’ve all been there. We always keep a backup copy of a device’s configuration, not just for recovery, but to use as a baseline for configuring similar devices in the future. We usually strip out all of the device-specific information and create a generic template so that we’re not wasting time removing the previous device’s details. Sometimes we’ll go so far as to embed variables so that we can use a script to create new configurations from the template and speed things up, but the principle remains the same: We have a configuration file for each device, based on the template of the day. The principle has worked for years, only complicated by that last bit. When we change the template, it’s a fair bit of work to regenerate the initial configurations to comply, especially if changes have been made that aren’t covered by the template. Which almost always happens because we’re manually making changes to devices as new requirements surface.

Modern Configuration Management: Automation Frameworks

Automation (ideally) moves us away from manual changes to devices. There’s no more making ad hoc changes to individual devices and hoping that someone documents it sufficiently to incorporate it into the templates. We incorporate new requirements into the automation policy and let the framework handle it. One of those requirements is usually going to be a periodic backup of device configurations so that a current copy is available to provision new devices, which amounts to using automation to create static configurations.

One Foot Forward and One Foot Behind

Templates and the custom configuration files built from them are almost always meant to serve as initial configurations. Once they’re deployed and the device is running, their role is finished until the device is replaced or otherwise needs to be configured from scratch.

The automation framework, on the other hand, plays an active role in the operation of the network while each device is running. Until the devices are online and participating in the network, automation can’t really touch them directly.

This has led to common practice where both approaches are in play. Templates are built for initial configuration and automation is used for ongoing application of policy.

Basic Templates via Automation Framework

Most organizations I’ve worked with keep their templates and initial device configurations managed via some sort of version control system. Some will even go so far as to have their device configurations populated to a TFTP server for new systems to be able to boot directly from the network. No matter how far we take it, this is an ideal application for automation, too.

We can use automation to apply policies to templates or configuration files in a version control system or TFTP repository just as easily (possibly even more so) as we can to a live device. This doesn’t need to be complex. Creating initial configuration files using the automation framework so that new devices are reachable and identifiable is sufficient. Once the device is up and running, the policy is going to be applied immediately, so there’s no need to have more than the basics in the initial configuration.

The Whisper in the Wires

The more I work with automation frameworks, the more I’m convinced that all configuration management should be incorporated into the policy. Yes, some basic configurations may need to be pre-loaded to make the device accessible, but why maintain two separate mechanisms? The basic configurations can be managed just as easily as the functional devices can, so it’s just an extra step.

Network Greasemonkey, Packet Macrame Specialist, Virtual Pneumatic Tube Transport Designer, and Connectivity Nerfherder. The possible titles are too many to count, but they don’t really mean much when he's essentially a hired gun in the wild west that is modern networking. Jody Lemoine is based in the Niagara region of Ontario, Canada, and operates tishco networks, a consulting firm specializing in the wholesale provisioning of networking services to IT firms for resale to their respective clientele. Over his career, he has developed a track record designing and deploying a wide variety of successful networking solutions in areas of routing, switching, data security, unified communications, and wireless networking. These range from simple networks for small-to-medium business clients with limited budgets to large infrastructure VPN deployments with over 450 endpoints. His broad experience with converged networks throughout Canada and the world have helped answer many complex requirements with elegant, sustainable, and scalable solutions. In addition, Jody maintains current Cisco CCDP and CCIE R&S (41436) certifications. Outside of the realm of IT, he is both a husband and father. In what meagre time remains, he contributes to the community by serving as an RCAF Reserve Officer, supporting his local squadron of the Royal Canadian Air Cadets as their Commanding Officer.