Why network configuration templates are useful in automation

The Value of Templates in Network Automation

At this point you might be wondering why we're talking about web development and how that could possibly help us on our network automation journey. It's very important to understand the value behind templates in general, whether they're used for the web or not. Templates get us consistency—instead of hand-crafting text files full of HTML tags or entering CLI commands, with templates we can declare which parts of our files need to remain static, and which parts should be dynamic.

Click here to learn more
about this book.

Every network engineer that's worked on a network long enough has had to prepare a configuration file for a new piece of network gear, like a switch or router. Maybe this has to be done for many switches—perhaps for a new data center build. In order to make the best use of time, it's useful to build these configurations ahead of time, so that when the switch is physically racked and cabled, the network engineer needs only to paste the configuration into a terminal.

Let's say you're in charge of a rollout like this—it's your job to come up with configurations for all switches going into the new data center being built for your organization. Obviously each switch will need its own unique configuration file, but there's also a large portion of the configuration that will be similar between devices. For instance, you might have the same SNMP community strings, the same admin password, and the same VLAN configuration (at least for similar device types like TOR switches). Then again, there are also probably some parts of the configuration that are unique to a single device; things like management IPs and hostnames are a simple example, but what if it's a Layer 3 switch? You'll need a unique subnet configuration for that device, and probably some fairly unique routing protocol configurations, depending on where that device exists in the topology. Deciding what parameters go to which switches can be fairly time-consuming, and very likely to result in errors. Templates allow us to standardize on a common base configuration, and help ensure that the right values get filled in for each device. Separating the template from the data that populates it is one of the best ways to simplify this process.

The primary value of templates for network engineers is achieving configuration consistency. Appropriately implemented, templates can actually reduce the likelihood that a human error can cause issues while making changes to production network configurations. There seems to be a lot of fear that making complex changes in an automated way in production is a bad idea, but if you follow good discipline and properly test your templates, you really can improve network operations. Templates don't automatically remove human error, but when used properly, they can greatly reduce it, resulting in fewer outages.

Using templates to aid the rollout of new network devices is a simple example of the value of templates, since it has the added benefit of saving a lot of time for the network engineer. However, don't think that this is the only place where templates can be used. In many network automation projects, templates are not even used by humans, but by automation software like Ansible to push configuration changes to network devices—live, in production.

We'll show concrete examples of using Jinja templates through the remainder of this chapter.

Jinja for Network Configuration Templates

The rest of this chapter will focus on one template language in particular—Jinja. We'll start with some basics, and ramp up to more advanced topics, all while showing how these concepts can be used to generate consistent network device configurations.

Why Jinja?

We've mentioned Jinja in the introduction to this chapter, but we also mentioned several other template languages. Why are we only looking at Jinja for network template automation? In addition to keeping this chapter from growing out of control, we chose Jinja because it is closely aligned with many of the other technologies mentioned in this book, including Python (Chapter 4). In fact, Jinja is a template language built for Python. Jinja is also aligned and used heavily by Ansible and Salt, two automation tools written in Python, both of which we cover in Chapter 9. So, if you're familiar with Python by now, Jinja will look and feel very similar.

Could you build network templates with other template languages? Sure. However, if you're new to template languages, and especially if you're following this book's advice and picking up some Python skills, you will find Jinja a very powerful tool on your network automation journey.

Dynamically Inserting Data into a Basic Jinja Template

Let's start with a basic example and write a template to configure a single switch interface. Here's an actual switchport (using industry-standard CLI syntax) configuration that we want to convert to a template (so we can configure the hundreds of other switchports in our environment):

interface GigabitEthernet0/1

description Server Port

switchport access vlan 10

switchport mode access

This kind of snippet is fairly easy to write a template for—we need only decide which parts of this configuration need to stay the same, and which need to be dynamic. In this next example, we've removed the specific interface name ("GigabitEthernet0/1") and converted it into a variable that we'll populate when we render the template into an actual configuration:

interface {{ interface_name }}

description Server Port

switchport access vlan 10

switchport mode access

This means we can pass in the variable interface_name when rendering this template, and that spot will get filled in with the value associated with interface_name. However, the previous example assumes that each network interface has an identical configuration. What if we wanted a different VLAN, or a different interface description on some of the interfaces? In that case, we should also convert some of the other parts of the configuration into their own variables:

interface {{ interface_name }}

description {{ interface_description }}

switchport access vlan {{ interface_vlan }}

switchport mode access

These are simple examples, but they're not very namespace-friendly. It's common to leverage concepts like classes and dictionaries in a language like Python when rendering a template. This allows us to store multiple instances of data like this, that we can loop over and write multiple times in our resulting configuration. We'll look at loops in a future section, but for now, here's that same template rewritten, and saved as template.j2, to take advantage of something like a Python class or dictionary:

interface {{ interface.name }}

description {{ interface.description }}

switchport access vlan {{ interface.vlan }}

switchport mode access

This was a minor change, but an important one. The object interface is passed to the template as a whole. If interface was a Python class, then name, description, and vlan are all properties of that class. The same is true if interface was a dictionary—the only difference is that they are all keys of this dictionary, and not properties, so the rendering engine would automatically place the corresponding values for those keys when rendering this template.

https://www.oreilly.com/library/view/network-programmability-and/9781491931240/?utm_medium=content+synd&utm_source=general+ad&utm_campaign=na&utm_content=org+techtarget