1. The document introduces Ansible and how it can be used to automate configuration of Arista switches and other network devices. 2. It provides step-by-step instructions for setting up an Ansible environment on Ubuntu, including installing Ansible, creating an inventory file and group variables to connect to switches. 3. Examples are given for using Ansible templates and playbooks to configure eAPI on an Arista switch to enable remote access and management.

1.
and
Made simple (Kind of).
Fernando Garcia
July 2016

2. Introduction
I know what you’re thinking. You heard that DevOps is the talk of the town and everyone in
Silicon Valley are buzzing about it. You’ve also heard people murmur things like ​puppet​ ,
napalm, and ​automagical provisioning​ . You also might’ve heard of a program called Ansible.
Lucky for you, Ansible and Arista go together like peanut butter and jelly. I’m not going to go in
deep on the technical side of Ansible; there are plenty of documents online that you can read if
you’re interested. Instead, I want to show you why Ansible is something you really need to start
playing with on Arista switches and how you can quickly get started.
Why Ansible?
Personally, I’ve yet to use a tool as versatile as Ansible. Keep in mind that when it comes to
networking automation, Arista has the upper hand with CloudVision. Ansible and CloudVision
can be synonymous when it comes to certain aspects of managing your Arista switch (granted,
CloudVision is the much better choice if you’re ONLY managing Arista switches), but Ansible
can also control your servers.
Note:
As you’re starting this journey with Ansible (If you are starting here, that is), please know that
there is so much more you can do with Ansible than only managing Arista switches. Not only
can it configure your Arista devices in any creative way you see fit, but you can also control
multiple nodes in your environment. You can install Apache on 10 servers, start|restart|stop
services, install mysql, and the list goes on. I hope you decide to look ahead of your switch and
figure out how you can automate the rest of your nodes.
​Assumptions
Before we get started, I want to make sure we our environment in sync. I’m going to assume:
1. You’re running through this document on an Ubuntu 15.xx server as an admin.
2. You have basic understanding of how to use Linux.
3. You have a switch that you can run tests on without disrupting someone else’s work.
4. You’ve installed all of the python dependent pieces of software.
5. YOU’RE MINDFUL OF INDENTATIONS. IF INDENTATIONS DON’T ADD UP, IT
WON’T WORK.
6. You’re the kind of person who uses 4 spaces instead of the tab button.

3. Skip this part if you just want to get started.
What is Ansible?
Ansible​ is a free software platform for configuring and managing computers which
combines multi­node software deployment, ad hoc task execution, and configuration
management.
How does Ansible work?
Ansible works by connecting to your nodes and pushing out small programs, called
"Ansible Modules", to them. These programs are written to be resource models of the
desired state of the system. Ansible then executes these modules (over SSH by
default), and removes them when finished.
How do I connect to Arista switches with Ansible?
There are two methods you can use to connect to your switch. You can use Cli or eapi (I’ll get
into that later so that I don’t complicate things too soon. In the meantime, take a look at these
links below that have A LOT of information you’ll need to broaden your horizons.
● eos_command ­ Run arbitrary command on EOS device
● eos_config ­ Manage Arista EOS configuration sections
● eos_eapi ­ Manage and configure EAPI
● eos_template ­ Manage Arista EOS device configurations

4. Let’s get started.
Setting up the environment:
First thing you have to do is install pip and Ansible on your Ubuntu box. These steps are based
off my sandbox. You should be able to run this on any distro. ​Click ​here​ to learn how​.
Install Ansible:
$ sudo apt­get install software­properties­common
$ sudo apt­add­repository ppa:ansible/ansible
$ sudo apt­get update
$ sudo apt­get install ansible
Test out the version you’re running; it should match this:
fernando@spacedocker:~$ ansible ­­version
ansible 2.1.0.0
config file = /home/fernando/spaceDocker/ansible.cfg ​← Except that.
configured module search path = Default w/o overrides
Your “​config file” ​is the path in which all of your ansible files are being interpreted. Let’s
change your default location. By default it’s here → ​/etc/ansible/ansible.cfg​,​ ​so we’re going to
make a new one in your home directory or another folder of your choosing. For simplicity sake,
let’s say a folder called ​lab​: /home/fernando/lab. Then we touch a new file called ansible.cfg:
fernando@spacedocker:~/lab$ ls
ansible.cfg
Then we edit it so that it matches this:
fernando@spacedocker:~/lab$ cat ansible.cfg
[defaults]
host_key_checking = False
inventory = ./hosts ​ ​← We’ll talk about this next.
Next up, let’s create a hosts file. In a nutshell, the hosts​ ​file will be a place where you store ALL
of the nodes in your environment, hence the name “inventory.” the [tors] value is the name of
the group. You can have multiple groups that can indicate different tasks, for example, you can
have [webapps], [openstackservers], etc.

5. Once you’ve created your hosts file, you can then add a switch that you have at your disposal.
In this test, i’m using a vEOS VM with an IP address and username “admin” secret “admin”. The
vEOS version is 4.16.6M
The IP address to this host is 192.168.1.10 so my hosts file will look like this:
fernando@spacedocker:~/lab$ ls
ansible.cfg hosts
fernando@spacedocker:~/lab$
fernando@spacedocker:~/lab$ cat hosts
[tors]
192.168.1.10
Next, you’re going to create a two more directories:
/group_vars
/templates
Let’s start with ​group_vars​. In here, we’ll create a file called ​all​ and edit it with the following:
fernando@spacedocker:~/lab/group_vars$ cat all
­­­
provider:
host: "{{inventory_hostname}}"
transport: cli
username: admin
password: admin
use_ssl: no
authorize: yes
Note: It’s important to understand “​transport​” when working with the networking and Ansible.
For EOS, the two transport value you can use are:
Cli and eapi​. Click ​here​ to learn more.
In the following examples, we will use the “cli” value.
Another important part of your Ansible file is Connection: local. Ansible uses SSH by default,
because usually it’s running tasks on faraway machines in the cloud. “Local” is telling Ansible
not to try to use SSH to contact the hosts, but to run tasks on our local computer instead.
The main reason we do this is because:
1. we have to run local to connect over eAPI
2. it's annoying to create a real bash user on a switch. So instead we use 'cli' which is using
SSH but not in the traditional sense.
Playbooks and templates
Let’s compare a ​template ​to a ​playbook​ that accomplish the same task. ​The goal is to
configure eapi and start it on our Arista switch.

6. Most templates are written in jinja. It’s beautiful and it’s powerful. Here’s a link to read more
about jinja: ​http://jinja.pocoo.org
Playbooks are a set of commands that run within your Ansible environment that execute tasks
for your application.
First, make sure you have the exec privileges enabled by default on your switch. You can do
this by entering these commands:
localhost(config)#aaa authorization exec default local
localhost(config)#username admin privilege 15 secret admin
Let me explain our ​template ​called ​eapi_config.j2​.
fernando@spacedocker:~/lab/templates$ cat eapi_config.j2
management api http­commands
no shutdown
It will configure the eapi on your switch and not shut it down. Keep in mind the indentation of the
“no shutdown” portion. When you’re creating a jinja template for configurations, they NEED to
match exactly as if you were running a “show run” command. If there’s an indent in the show run
command, ​then you need to indent it exactly in your jinja template.
Next, you’ll notice in your ​group_vars ​file the username variables. Again, it’s best that you read
up on what’s going on under the hood, but I’ll keep it as easy as possible for you with a simple
playbook. Your group_vars are a set of variables you want to use when executing a playbook.
You can configure your playbook to call back to your group_vars for specific variables. In this
example, we’re calling back to the group variable that contains usernames. When writing this
playbook, refer to ​assumption 5 & 6.
fernando@spacedocker:~/lab$ cat api_config.yaml
­­­
­ hosts: tors
gather_facts: no
connection: local
tasks:
­ name: configure API
eos_template:
provider: "{{provider}}"
src: eapi_config.j2

7. Look again at your group_vars and see where “{{provider}}” came from:
fernando@spacedocker:~/lab/group_vars$ cat all
­­­
provider: ​ ​←​ Ding ding!
host: "{{inventory_hostname}}"
transport: cli
username: admin
password: admin
use_ssl: no
authorize: yes
Now, I’ll show you the same exact task needed using only a playbook.
fernando@spacedocker:~/lab$ cat eapi_config.yaml
­­­
­ hosts: tors
gather_facts: no
connection: local
tasks:
­ name: Enable EAPI access with default configuration
eos_eapi:
state: started
provider: "{{ provider }}"

8.
Run your first playbook!
Now that your environment is all set up, let’s run this playbook to see what happens. Try this:
have two terminals open. One to your linux host, and the other to your switch. Have them both
up side by side. On one side, run the command to your switch like this:
localhost(config)#watch 1 show run sec api
On the linux terminal, run this command:
fernando@spacedocker:~/lab$ ansible­playbook api_config.yaml
That was easy, right? Let’s get a bit more complicated…
Let’s say you want to have a default user in all of your switches. Here is a jinja template you
should add to your /templates directory. Title it eos_user.j2
username {{item.name}} privilege {{item.privilege}} role {{item.role}} secret
{{item.secret}}
Think of this jinja template as you would a python script. The {{item.name}} calls back to your
group variables file. The jinja template should have the same whitespace as you’d see in the
running­config of your switch. Let’s look at the file “~/group_var/all” and add a section for a user.
We’ll start with an admin account:
admin_users:
­ name: fernando
privilege: 15
role: network­admin
secret: admin
Essentially, your output will be parsed like this:
Username {{fernando}} privilege {{15}} role {{network­admin}} secret {{admin}}
Finally, let’s make a playbook to make it happen. Title this whatever you like.
­­­
­ hosts: tors
gather_facts: no
connection: local
tasks:
­ name: "####adding admin credentials.####"
eos_template:
provider: "{{provider}}"
src: eos_user.j2
with_items:
­ "{{admin_users|default([])}}"

9.
You’ll see a lot of the usual stuff here, but I’ve included “with_items:” and you’ll see why in a bit.
Let’s run this playbook. We can even add fuel to the fire by adding specific variables. Change
your jinja template to look like this:
username {{item.name}} privilege {{item.privilege}} role {{item.role}} secret
{{item.secret_type}} {{item.secret}}
{% if "ssh_key" in item %}
username {{item.name}} sshkey {{item.ssh_key}}
{% endif %}
Then let’s update the ~/group_vars/all to look like this:
admin_users:
­ name: fernando
privilege: 15
role: network­admin
secret_type: sha512
secret:
"$6$w3zgkucAc/t3sv5R$nevGz350gLZa5IaXjTWajvjAYF8NdVeKCpf5UKJxV5X45ZzV9hyRRHLIghb8onR
7KgcSD0NrXh1aTeoxDpnQA."
ssh_key: "ssh­rsa blah blah blah"
The jinja file has an “if statement” which is basically saying, “If you have the ssh_key in your list
of items in the ~/group_vars/all file, then do that.” That being adding an ssh key to your running
config. Also notice that “secret_type” is sha512 and the secret password is encrypted. That’s
because of the normal conditions that need to be met when configuring your switch. If it needs
to be done on the switch, you need to have it in your jinja template. The ssh_key is your RSA
key from which this script is running, so not the one on your laptop, but the one on the ubuntu
server.
Okay, run the script again and you should see the second line which is your username with an
ssh key!
To watch it in real time, run the following command on the switch as you execute the playbook:
localhost(config)#watch 1 show run sec username
Adding Aliases; building your template config:
Here’s a quick and dirty to have an alias template along with a default prompt:
First, we create the jinja file “prompt.j2” and place it in the ~/lab/templates folder.
fernando@spacedocker:~/lab/templates$ cat prompt.j2
{% raw %}
prompt %H.%D{%H:%M:%S}%P
{% endraw %}
{% for cmd in cli_aliases %}
alias {{ cmd }}
{% endfor %}

10.
We then add the following to the ~/group_vars/all file:
cli_aliases:
­ cc clear counters
­ senz show interface counter error | nz
­ snz show interface counter | nz
­ sqnz show interface counter queue | nz
­ srnz show interface counter rate | nz
Finally, we create a playbook:
fernando@spacedocker:~/lab$ cat prompt_and_aliases.yaml
­­­
­ hosts: tors
gather_facts: no
connection: local
tasks:
­ name: change user prompt
eos_template:
provider: "{{provider}}"
src: prompt.j2
By the way, this method of adding aliases is overly complicated for a reason. You can add the
aliases themselves in a separate jinja template like this which will also work:
{% raw %}
prompt %H.%D{%H:%M:%S}%P
{% endraw %}
alias cc clear counters
alias senz show interface counter error | nz
alias snz show interface counter | nz
alias sqnz show interface counter queue | nz
alias srnz show interface counter rate | nz
There are many ways to accomplish one goal; I hope these few gave you a bit more
understanding on how to implement them.