Before I joined the ranks of Arista, my primary focus was technical refreshes and configuration documentation to support a PVST+ and OSPF architecture. Yes – PVST+. Yes – not RSTP. I don’t say that to knock the place, I say that to give you an idea of where I’m coming from. I was completely focused on spanning tree and routing protocols – primarily OSPF. I had blinders on and didn’t want to do anything but routing and switching in a certain vendor’s world.
Needless to say, transitioning from that place to working for Arista Networks was like Charlie stepping into Willie Wonka’s Chocolate Factory.
I never heard of or had to deal with things like “SDN”, “Automation”, “DevOps”, etc. I watched on in amazement as I sat in internal calls and training sessions as these “network wizards” did things that I didn’t even know were possible. It amazed me, but concerned me as well because it almost seemed like you had to have a programming background – at least to my untrained eye. I questioned how I made it past the interview process, and made sure my resume, LinkedIn profile, and professional relationships were all tidied up – you know – just in case. ;)
After spending some time at Arista learning the myriad of awesomeness that EOS had to offer, I quickly latched on to vEOS and began building out a virtual data center on my laptop to start tinkering with things myself such as ZTP, the Splunk Forwarder, and VXLAN – even a little Python scripting. Though don’t get too impressed here – by “Python scripting”, I largely mean downloading other people’s work and tailoring it to my own needs – at least the parts of it I could interpret!
Recently, there was an internal offer to review some new documentation focused on Arista’s integration with Ansible – which is a free IT Automation tool. The documentation was said to be designed so that someone with zero experience could do it. Naturally, I figured I would make the perfect dummy for this and jumped at the chance to learn more about it. After all, you need to work with something to really be able to get into the weeds of it.
So I was given the link to the documentation, found some time between meetings and other tasks, grabbed some coffee and Trap music (Don’t judge), and then off I went. My first stop was http://ansible-eos.readthedocs.org/en/master/index.html
If you want to learn all there is to know here, I advise you to read the documentation yourself, but to give you a little crash course on how this works, you setup an Ansible control node with the Ansible EOS role on a server, and then you have two ways of interacting with an Arista switch – both of which require the pyeapi. Where you run the pyeapi depends on your connection method. You can either run pyeapi directly on the switch, which adds a two-factor mechanism of security by requiring the control node to first SSH to the switch, or you can instead run pyeapi directly from the control node. I utilized the first connection method initially, but then switched to the second when I started working with multiple switches because, well, it’s my virtual lab and it was faster than setting up an additional account for SSH and installing pyeapi on every switch – I didn’t need the added security. So what happens with this connection method is the Ansible control node runs the pyeapi natively, which then interacts with eAPI directly on a given Arista switch to push configuration.
After addressing some knowledge gaps in general Linux server administration, I had my Ansible control node up and running with the Ansible EOS role installed. I then ran a couple commands from the control node CLI to do single-line configurations of my vEOS instances. OK – check – that works. Now on to “playbooks”.
A “playbook” is where the magic really begins to happen. You basically specify a list of nodes, which in my case were my vEOS instances, and configure a set of tasks to run against them. I set up vEOS in GNS3 as below:
I setup basic OSPF as an IGP between my three vEOS instances, and configured the two “dummies” with IP addresses in the same subnet and put them in the same VLAN (VLAN 10). This was to test L2 extension via Virtual eXtensible LAN (VXLAN), provisioned using Ansible. Pretty basic – if DUMMY1 could reach DUMMY2, then viola – success!
So I kicked off a ping from DUMMY1 and started thinking about what I was going to need to get basic VXLAN bridging to work correctly.
To get VXLAN working, I was going to need the following:
- I need a VXLAN Tunnel Interface (VTI) on both veos01 and veos02, and to configure that VTI with a source address of the Loopback0 interface which is already being routed in OSPF – this will be the source of my VXLAN tunnel from either node
- I need to configure the VTI to map VLAN 10 to a Virtual Network Identifier (VNI) – let’s say 1010
- I’m doing Head-End Replication (HER), so I need to configure a flood list on both veos01 and veos02, pointing to each other’s loopback addresses
To do this, I was going to need to utilize three modules provided by the ansible-eos role:
- eos_vxlan to configure my VTI source address
- eos_vxlan_vlan to handle the VLAN-to-VNI mapping
After going through the provided documentation to understand how the modules worked and proper YAML syntax for use in playbooks, I was able to put together a basic playbook pretty quickly. As you can see, YAML is a lot easier to read for those of us with absolutely zero programming background (Ok – to be fair I did manually-build an HTML website back in the day for fun, but really that’s it – even that was a lot of copy/paste).
Of course I didn’t get this all put together so perfectly the first time – there was some trial and error, but nothing earth-shatteringly difficult , and I had a blast doing it! Then there’s that magical moment when you get everything just right, and launch your playbook:
I took a look at the vEOS configs, and…
BAM! I then looked up at the ping I initiated from DUMMY1, and….
DOUBLE BAM! I jumped up from my chair as it fell down behind me feeling like a Spartan and pronounced, “I’m the man!”
… to which my wife promptly put me in check and reminded me the kids were sleeping – keyword, “were”.
In summary, I encourage anyone to jump in and check out Arista’s integration with Ansible – you’ll be pleasantly surprised how easy it can be, and it’ll open your eyes to the wide range of automation possibilities. Once you get the basic stuff down, you’ll want to start playing around with the more advanced stuff – “advanced” for me right now is just figuring out how to use loops, and condensing, like so:
Also keep in mind, I’ve only touched on VXLAN – Ansible with the arista-eos role can provision much more! Thanks for reading.