Here we’ll talk about three noteworthy tools for automatically managing the configurations of many devices on a network.
They are listed in order of popularity for network configuration.
Note
None of these tools was actually developed specifically for use in network configuration management. Instead, they can along with the rise of virtual machines to help administrators automate the creation, configuration, and deletion of VMs. However, today they are commonly used to manage network configurations.
These tools can be used to automate tasks such as:
- Generating configurations for new devices on a large scale
- Perform configuration changes on devices (all devices or a subset of devices)
- Check device configurations for compliance with standard configs
- Compare configurations between devices, and between different versions of configurations on the same device
Configuration Provisioning
Configuration management tools are useful for configuration provisioning, i.e. applying configurations and changes to configurations to devices.
Traditionally, configuration provisioning is performed via CLI over SSH (or similar protocol) or by the device’s console port. This is effective for a small number of devices, but does not scale well in large networks. Configuration tools, like those covered in this article, can make changes to devices on a mass scale in a small fraction of the time.
Two important concepts for configuration management tools are templates and variables:
- A template defines the overall layout of the configuration file, with certain values replaced with tags to denote where variables should be inserted.
- A separate variables file contains a list of variable definitions.
The idea is that all devices can share the template file, and engineers only need to specify a small number of variables for each device (though even these can usually be automated).
Configuration Drift
They are also good at preventing and correcting configuration drift, which is when individual changes made over time to a device’s configuration cause it to deviate from the standard configurations defined by company policy.
- Although every device will have unique parts of its configuration (IP addresses, host names, etc.), most of any given device’s config will actually be defined in standard template configs created by the company’s network architects/engineers.
- Sometimes, it may be necessary for an engineer to make a change to a device’s configuration for a variety of reasons. While these should be reverted as possible, people make errors and the configuration of the device(s) can drift away from the standard.
- These kinds of minor changes usually aren’t recorded, nor their reasoning. This can cause issues down the line.
Ansible
Owned and developed by Red Hat, known for their self-named Linux distribution which is commonly used on enterprise servers.
Ansible is written in Python, a common scripting language in the networking industry, but apparently not often used to write fully-fledged configuration management applications.
It is agentless, meaning that it does not require any special software to be running on the managed devices. Rather, Ansible uses SSH to connect to the devices remotely to make any necessary changes or extract information. This makes it simpler to deploy and, in some ways, more versatile than other management solutions.
As there are no agents, Ansible uses a push model for deploying changes. A single Ansible server, called a control node, uses SSH to connect to managed devices and push configuration changes to them. This is compared to a pull model, like the other solutions (discussed later) use in which the managed devices themselves connect to a server to request updated configurations.
After installing Ansible, an engineer must create several text files:
- Playbooks: These are a sort of ‘blueprint of automation tasks’. They outline the logic and actions of the tasks that Ansible should perform. Written in YAML.
- Inventory: These list the devices that will be managed by Ansible, as well as some characteristics of each, such as their role (access/core switch, WAN router, firewall, etc.). Several supported formats including INI, YAML, and others.
- Templates: These represent a device’s configuration file, but specific values for variables are not provided. Written in Jinja2.
- Variables: These files list variables and their values. These values are substituted into the templates to create complete configuration files. Written in YAML.
Puppet
Puppet is written in Ruby.
It is agent-based, meaning that all managed devices must be running special software to connect to a Puppet server, called the ‘Puppet Master’, and receive changes to their configurations. This is a limitation in some cases, as not all devices (including some Cisco devices) can support a Puppet agent.
It can be run agentless, in which a proxy agent runs on an external host, and the proxy agent uses SSH to connect to the managed devices to communicate with them, however this is somewhat more complicated to configure than a normal Puppet agent or, for the sake of comparison, Ansible.
Puppet uses a pull model, i.e. clients ‘pull’ their configurations from the Puppet Master, rather than the server itself connecting to the client and directly making the changes. Clients use TCP port 8140 to communicate with the Puppet Master.
Instead of YAML, or any other open data-serialization standard, it uses a proprietary language for its files.
Like Ansible, the Puppet master requires some text files:
- Manifest: defines to desired configuration state of a network device.
- Templates: Similar to Ansible’s templates. Used to generate manifests.
Chef
Chef, like Puppet, is an agent-based configuration management tool written in Ruby, which uses a pull model for updating clients. Not all devices support a Chef agent (in fact, most Cisco devices don’t), which is one reason it the least popular of the three solutions listed on this page.
Chef server uses TCP port 10002 (among others) to send configuration files to clients.
Files use a DSL (Domain Specific Language) based on Ruby. Files used include:
- Resources: The ‘ingredients’ in a recipe. Configuration objects managed by Chef.
- Recipes: The ‘recipes’ in a cookbook. Outline the logic and actions of the tasks performed on the resources.
- Cookbooks: A set of related recipes grouped together.
- Run-list: An ordered list of recipes that are run to bring a device to the desired configuration state.