Hello my friend,

In one of the previous articles we have introduced new vendor to our interoperability tests, which is Arista. Its virtual router vEOS has shown good capabilities for data center activities, especially in context EVPN/VXLAN. In this article we’ll take a look on how to automate its deployment.

Disclaimer

In this article we’ll review solely automation of Arista EOS configuration using Ansible. Automation of network deployment for other vendors, like Nokia (Alcatel-Lucent) SR OS, Cisco IOS XR and Cumulus Linux, have been provided recently in separated article.

Brief description

Frankly speaking. there are several options, how Arista EOS can be automated. Arista EOS can be configured in total using these 3 main approaches:

• JSON scripts through HTTP
• CLI using SSH
• OpenConfig using NETCONF or RESTCONF.

It means any of these interfaces can be used to automate Arista EOS products. In this article we’ll focus on the 2^nd option, which is CLI using SSH. For that we’ll use Ansible with corresponding templates, which add this necessary degree of automation.

OpenConfig seems to be the most advanced and future proof, therefore we’ll cover it in separate article for all the vendors

Regarding Ansible and Arista, there are plenty of modules developed to configure various aspects of Arista EOS and they can be good, especially if you deploy single new customers. But in this article I’ll use single module, which in nutshell accepts all the configuration commands. In conjunction with proper jinja2 templates, I believe, it’s the best way for deploying infrastructure.

What we are going to test?

Following the same approach, we did for automation of Cumulus Linux, we’ll deploy playbooks for:

• Configuration of network interfaces to interconnect routers within data centre IP fabric
• Configuration of BGP both for undelay and overlay

Software version

The following infrastructure is used in my lab:

• CentOS 7 with python 2.7.
• Ansible 2.6 (NEW!)
• Arista EOS 4.20.5F

See the previous article to get details how to build the lab

I have auto updates turned on in my CentOS Linux, that’s why somewhere recently Ansible has been updated from 2.4.2 to 2.6. I don’t when it happened as it was done automatically. So, be aware of the changes.

Topology

Following the same approach, we’ve done recently for Cumulus Linux, we add new node to our automation lab:

The logical topology comes from the previous lab about joint data center operation of Nokia (Alcatel-Lucent) SR OS and Arista EOS:

As we mentioned previously, we deal only with automation of Arista EOS in this lab, therefore we provide the final configuration files for the rest vendors from the previous lab, and for the Arista we provide just simple pre-configuration with configured management interface and user for remote access:

Preparing environment for Ansible playbooks

As a basis for this article we take the Ansible structure with roles and templates we shared with you some time ago, that’s why we’ll omit description of role’s structure.

The structure of the interrelated folders and files are just the same as in the case of Cumulus’s automation:

Knowing how the structure looks like, we need to create it and update some other information:

#1. Update of Ansible host

#2. Update of Linux hosts

#3. Test connectivity

#4. Create file with authentication data for Arista EOS

If you are following my series (link), you can see some more commands comparing to file for Cumulus Linux (link). Here, for Arista EOS, it’s more extended I believe, so I’ll update it for Cumulus Linux later on as well to fix some authentication workarounds:

As we use Ansible 2.6, we don’t create separated file for providers. Since 2.5 it’s deprecated and we follow new guidelines.

#5. Create new role and sub-structure for Arista EOS

#6. Create Ansible playbook to launch the role

As proposed in the module description, we put here connection type “network_cli”. Though it might be not necessary, as we mentioned it initially in group variables.

Let’s start filling in our jinja2 templates and Ansible playbooks with life.

General approach for automation for Arista (and not only)

We have used such approach earlier in different articles, so here we’ll just recap all the pieces together:

• Creating files with per-node variables
• Creating appropriate templates
• Creating files with tasks

As we follow the same approach both for configuration of interfaces and BGP, we won’t split them here and we’ll show together.

#1. Creating files with per-node variables

Such structure was used many times (earlier and recent examples). We focus here on interfaces and BGP part mainly, as virtual Arista EOS router doesn’t have cards, models and so on:

The BGP part is tailored for our deployment, in terms of defined address families, but it’s quite easy to extended it to any other one.

#2. Creating appropriate templates

As we have two major tasks, we create two templates: for interfaces and for BGP.

The first one is for creation of interfaces:

Jinja2 is awesome, isn’t it? We don’t define any exact number of ports; the template automatically multiplies configuration to the number of interfaces defined in the files with variables. There are also some additional tweaks, like putting “switchport” on interfaces besides loopback or “encapsulation” only if VLAN besides 0 is configured.

These things are very simple and useful, to make deployment really automated and makes script “thinking instead of you”.

The second one is for the BGP configuration:

In the BGP template we define some basic parameters (like ASN and router id) and then, based on the neighbour parameters, we configure them and activate for corresponding address families. One tweak I added for future, the whole this part configured only if BGP is configured, otherwise the whole template will be skipped. If we’d like to have any other underlay routing protocol, we can easily extend the template.

#3. Creating files with tasks

When the variables and templates are defined, we just need to put them together for execution it tasks’ files. To make things more manageable, I will create configuration-specific files in addition to “main.yml”. But first of all, let’s start with “main.yml” itself:

In the main file with tasks we only import variable and call the specific configuration sub tasks. These configuration subtasks are almost identical:

Frankly speaking, they are absolutely identical. What differs is the template now and name of the temporary file to store config. They logic is very straightforward:

• Create temporary configuration file based on template and variables
• Update the configuration of the network element
• Delete temporary file

Let’s review how our automation works

Verification

There is the single way to verify if your automation is working: test it. So, we just launch this Ansible role and check the vEOS2 data centre leaf based on Arista EOS afterwards:

Don’t pay attention to vEOS1 failures, as it isn’t launched

After the configuration is applied, we review the configuration file from vEOS2 (in the Ansible playbook, we have mentioned that config should we saved if modified, that’s why we check the startup-config):

Ansible playbook have been executed successfully, so our automation works!

Ansible roles and all other files we have created during this lab you will wind here: 122_lab.tar

Lessons learned

User guide for Arista EOS for Ansible has pointed me some possible solutions for problem with authentication in Cumulus Linux, which I have encountered and haven’t solves still. So, you never know which synergy effect we can achieve during troubleshooting of small things. It can be really big.

Another lesson learned is that we need to play with parameters of the Ansible modules. Used “eos_config” have failed many times, until I have added “match: none”. Though it was a best guess, it worked. So, try, try and try.

Conclusion

If you have seen some previous articles you might notice that I’m following more or less the same model all the time. I’m not saying it’s perfect, as I just don’t know that. But it’s actually the advantage of automation: we can just change the template from vendor A to vendor B and deploy new network element without changing the data model. For sure YANG gives even mode advantages (link), and we will try to step into really vendor-agnostic configuration model in the next article, when we’ll talk about OpenConfig. Take care and good bye!

Support us

Support new interop and automation articles at karneliuk.com
EUR

I want to support with:
9.99 EUR4.99 EUR24.99 EUR49.99 EUR99.99 EUR199.99 EUR

P.S.

If you have further questions or you need help with your networks, I’m happy to assist you, just send me message. Also don’t forget to share the article on your social media, if you like it.

BR,

Anton Karneliuk