• Managing EOS configuration with Puppet and Templates

Print Friendly, PDF & Email

Availability, stability, and effort (time) to complete maintenance are key factors for network management. Taking advantage of automated configuration management tools such as Puppet enable network engineers to ensure consistency in configurations, test changes before applying them to production networks, and multiply their effort when making changes that touch multiple devices. Puppet is a versatile tool which can require a ramp up period. However, there are significant long-term benefits when multiple organizations (server, application, etc.) within your company share the same tool set and knowledge.

The introduction of the eos_switchconfig Puppet resource type to the EOS module eases the transition for teams moving from traditional CLI-based switch management to automation by making use of configuration templates. Many portions of switch configurations within an organization are duplicated from device to device, differing only by a few values, such as interface addresses or BGP peers. By using Embedded Ruby (ERB) templates, a network engineer can take an existing startup-config and embed variables in place of hard-coded values. The data to fill in these values can be stored and retrieved with Hiera, a hierarchical key:value lookup tool included with Puppet or provided by role and profile modules. Puppet can, then, retrieve the data that should be inserted for a given node, replace the variables within the template, and ensure the running-config on the switch is compliant. This creates a data-driven model for your network configuration without the need to understand the intricacies of the Puppet domain-specific language (DSL), letting you go from manual-to-automated configuration management more rapidly.

Getting Started

Puppet uses an agent that runs on each node to check-in with the Puppet server and manage the state and changes on a node. Puppet provides a supported agent installation package specifically for Arista EOS. This is a stock Linux agent with file storage mapped to persistent paths in EOS. To get the Puppet agent installed on a switch and the EOS Puppet module installed on the server, refer to the quickstart guide. Eos_switchconfig is included in the EOS Puppet module that needs to be installed on the Puppet server.

Once the agent and module are installed, you can begin configuring templates and data on the server. We strongly encourage good development and testing practices along with source-code management tools and unit-testing when working with your Puppet configurations. However, to demonstrate the usage of this resource, we focus on the actual Puppet and Hiera code below. The configuration can be broken up into three main components: the Puppet class, the switch configuration template, and Hiera data used to populate the template.


Puppet Classes contain a list of resources that should be applied to a node or group of nodes with the ability to handle additional logic, as well. You can have separate classes applied to different nodes, or a single class may have logic within to determine which resources to apply to a given node based on its name or role. Common node roles for networks include spine, leaf, storage-leaf, and edge-leaf with other possibilities based on your topology. Classes can be applied to nodes through Puppet manifests or the Hiera include_classes directive. A sample network class is below:

# modules/network/init.pp
# Use: include network
class network (
String $hostname,
String $dns_server,
String $dns_domain,
String $ntp_server,
String $portnum,
) {
# Parameters, above, can be looked up from Hiera or passed to
# the class when called from a manifest. They will be used to
# fill in variables in the template.

# What is this node's role?
$template = $facts['role'] ? {
'spine' => 'network-roles/spine.erb',
'leaf' => 'network-roles/leaf.erb',
default => fail "Unknown network role: ${facts['role']}"

# Lookup this variable based on the value of another variable
$vlan = lookup("port${portnum}-vlan", 1)

# Render the template then ensure the
# running-config matches this content
eos_switchconfig { 'running-config':
content => template($template),

Config Templates

Configuration templates can be created using ERB or Puppet template syntax. The ERB syntax is available both within Puppet as well as other tools, while the newer Puppet template syntax has additional integration with the Puppet environment and requires more recent versions of Puppet. Below is a sample using ERB syntax. For simple variable substitution, replace the static data, such as an IP address or hostname, with code that looks like “< %= @domain_name %>“. Then, when the template is rendered, the value of $domain_name in the class (usually looked up from hiera) will be inserted into the output. Templates can include conditionals and loops if needed, and a final template can even be made up by concatenating smaller templates together. For more information on advanced capabilities, see the Puppet ERB syntax.

hostname spine1
ip name-server vrf default < %= @dns_server1 %>
ip domain-name < %= @domain_name %>
ntp source Management1
ntp server < %= @ntp_server %> prefer iburst
! ...
interface Ethernet< %= @portnum %>
description Host < %= @host %> managed by puppet template < %= @template %>
switchport switchport mode access
switchport access vlan < %= @vlan %>
no shutdown

Hiera data

Hiera can use several backends to lookup data, but the most common is a tree of YAML files. The hiera.yaml file defines the tree that will be searched and in what order. Often you will see something like the following:

version: 5
- name: "Per-node data"
path: "nodes/%{trusted.certname}.yaml"
- name: "Per-role data"
path: "roles/%{facts.role}.yaml"
- name: "Per-datacenter / business group data"
path: "location/%{facts.whereami}/%{facts.group}.yaml"
- name: Common
path: common.yaml
data_hash: yaml_data
datadir: data

This means hiera will first look for a file named data/nodes/<node-FQDN>.yaml. If it does not find the desired key there, it will look in data/roles/<role-name>.yaml. Then data/location/<location>/<group>.yaml. And, lastly, data/common.yaml. Within each YAML file, variables are usually prefixed with the class that uses them. In the case of this example: “network::“. For the above scenario, there could be a file ‘data/nodes/spine1.example.com.yaml‘ containing the following:

network::role: spine
network::port2-vlan: 300
network::port5-vlan: 400

And a common file ‘data/common.yaml‘ with contents:

network::domain-name: example.com
network::ntp_server: pool.ntp.org


With this basic example, you can see pieces required to set up your templates and data. By extending the template and data to describe your entire switch configurations, you can achieve a data-driven configuration model and ensure consistency across your environment. This enables you to change the syslog configuration of every device with a single line in a YAML data file or within a template enabling you to roll out changes faster and giving you more time to focus on more interesting tasks. Install the EOS Puppet module or contact EOS+ Consulting Services to get started.


Get every new post on this blog delivered to your Inbox.

Join other followers: