Automating Labs...Now With YAML and Multi-Threading!
The automation described in my [last post] (/posts/2018-04-19-automating-labs-with-python-jinja2-and-netmiko/) had a couple of glaring flaws. I quickly discovered the inflexibility of using a CSV file for the data source as I started to add more variables to each device. The second flaw was that for approximately 30 devices, it took about 20 minutes to generate and push the device configurations, because each device was processed serially.
I solved the first issue by using a YAML file for the data source. I initially went with a CSV file because I had not yet developed an IP addressing scheme, and I found it easier to do that in a row-and-column format. However, as I was developing the Jinja2 template, it became apparent that the CSV file wasn’t going to cut it since each device has (or will have) customizations that won’t apply to all (or even a good portion) of the devices.
For example, I am configuring basic IS-IS routing for the service provider IGP, but the CE devices will not be running that protocol. The CE devices represent nearly half of my lab, so having IS-IS options within the CSV file seemed like a waste. This led me to think a little deeper about the information I wanted to represent for each device, and YAML’s immense flexibility seemed like the perfect fit. I would also consider using a SQLite database if I were dealing with hundreds or more devices.
The most time-consuming part of learning to work with YAML files in Python is discovering how to access your data. It’s very easy to write a YAML file, but it takes some thought and testing to get the data back out (which, like most things in life, I’m sure gets easier with more experience and exposure).
Here is an example device from my YAML file:
---
PE1:
hostip: 192.168.196.22
port: 32795
interfaces:
# Interface, IP, Mask, MPLS Enabled?
- ['lo1', '10.255.1.1', '255.255.255.255', True]
- ['g0/0', '10.1.81.1', '255.255.255.254', True]
- ['g0/1', '10.3.11.1', '255.255.255.254', True]
- ['g0/2', '10.3.12.1', '255.255.255.254', True]
- ['g0/3', '10.3.13.1', '255.255.255.254', True]
- ['g0/4', '10.1.71.1', '255.255.255.254', True]
- ['g0/5', '10.1.11.1', '255.255.255.254']
isis:
net: 49.0001.0000.0000.0010.00
interfaces: ['lo1', 'g0/0', 'g0/4', 'g0/5']
bgpasn: 65000
bgp_peers:
# Peer IP, Peer ASN, Update Source, Next-Hop-Self
- ['10.255.1.2', '65000', 'lo1', True]
- ['10.255.1.3', '65000', 'lo1', True]
- ['10.255.1.4', '65000', 'lo1', True]
- ['10.255.1.5', '65000', 'lo1', True]
- ['10.255.1.6', '65001']
This device is described by its management IP and port, IP interfaces, IS-IS and BGP options. If I were to configure another device and it was not going to run IS-IS, I would merely leave the isis: section out.
After the YAML file is imported, it is processed by my Jinja2 template. Here is an example:
hostname {{ host }}
no ip domain-lookup
{%- if isis %}
router isis
net {{ isis['net'] }}
{%- endif %}
{%- for iface in interfaces %}
interface {{ iface[0] }}
ip address {{ iface[1] }} {{ iface[2] }}
{%- if isis %}
{%- if iface[0] in isis['interfaces'] %}
ip router isis
{%- endif %}
{%- endif %}
{%- if iface[3] %}
mpls ip
{%- endif %}
no shutdown
{%- endfor %}
{%- if bgpasn %}
router bgp {{ bgpasn }}
{%- for peer in bgp_peers %}
neighbor {{ peer[0] }} remote-as {{ peer[1] }}
{%- if peer[2] %}
neighbor {{ peer[0] }} update-source {{ peer[2] }}
{%- endif %}
{%- if peer[3] %}
neighbor {{ peer[0] }} next-hop-self
{%- endif %}
{%- endfor %}
{%- endif %}
end
All devices will be configured with a hostname and the no ip domain-lookup option. If the device is going to run IS-IS, that is configured, and if not, that section is skipped. Each specified interface is then configured with its IP address and mask. If the interface will participate in IS-IS or MPLS, that is configured. If the router will participate in BGP, that is configured as well. This Jinja2 template shows a generic device, but as I displayed in my last post, this can easily be modified for individual devices as well (if device == ‘Whatever’). This template also demonstrates examples of nested looping, which takes a little bit of time to test and work out the logic. Once it clicks, though, it is a thing of beauty!
I solved the timing issue with the discovery of the multi-threading library for Python. In my lab configuration script, the YAML file is read into a Python dictionary. Then, for each device represented in the YAML file, I pass its variables into the multithreading function, which then calls my function to generate and push the configuration. Each device is effectively processed simultaneously, which cut the lab configuration generation and deployment from 20 minutes to less than one.
Here is my Python script to glue the YAML and Jinja2 files together:
#!/usr/bin/env python3
import yaml
import jinja2
import time
from netmiko import Netmiko
import threading
yaml_file = 'hosts.yml'
jinja_template = 'jtemp.j2'
# Generate the configurations and send it to the devices
def confgen(vars):
# Generate configuration lines with Jinja2
with open(jinja_template) as f:
tfile = f.read()
template = jinja2.Template(tfile)
cfg_list = template.render(vars)
# Connect directly to host via telnet on the specified port
conn = Netmiko(host=vars['hostip'], device_type='cisco_ios_telnet',\
port=vars['port'])
# Check if host is in initial config state
conn.write_channel("\n")
time.sleep(1)
output = conn.read_channel()
if 'initial configuration dialog' in output:
conn.write_channel('no\n')
time.sleep(1)
# Send generated commands to host
output = conn.enable()
output = conn.send_config_set(cfg_list)
# Display results
print('-' * 80)
print('\nConfiguration applied on ' + vars['host'] + ': \n\n' + output)
print('-' * 80)
# Probably a good idea
conn.disconnect()
# Parse the YAML file
with open(yaml_file) as f:
read_yaml = yaml.load(f) # Converts YAML file to dictionary
# Take imported YAML dictionary and start multi-threaded configuration
# generation
for hosts, vars in read_yaml.items():
# Add host to vars dictionary
host = {'host': hosts}
vars.update(host)
# Send vars dictionary to confgen function using multi-threading,
# one thread per-host
threads = threading.Thread(target=confgen, args=(vars,))
threads.start()
Threads = threading.Thread. I love it!