Cisco Nexus EVPN VXLAN Fabric Ansible Automation

This is a post that takes the previous Nexus EVPN VXLAN Fabric post, and uses Ansible to build the topology. This is based off this Cisco developer document.

General Info

This project is located in my GitLab. In order to run the Ansible playbook navigate to the nexus_evpn, and run ansible-playbook -i inventory/DC_inv.ini site.yml

Setup

I have used a Python virtual environment and installed Ansible inside the virtual environment.

I have created a directory for this project named nexus_evpn.

I have created two more directories that are for; group_vars, host_vars and roles

According to the Cisco document, Ansible Galaxy can be used to create the spine and leaf directories inside the roles directory. This isn’t exactly needed as it creates a lot of extra files that are not required for this lab, but it faster than creating the structure manually.

The only important directories and files in this are the tasks, vars directories, and the main.yml inside each of these. The rest of these directories/files inside the tree output is not used.

Ansible Configuration

First, the configuration of Ansible needs to be taken care of. Without this, the playbook may not run at all. Below is the output for the complete structure of this project. There is a .ansible.cfg file that contains important parameters for Ansible when running the playbook.

The inventory file is also important and referenced in the .ansible.cfg file. This example is a .ini file, this is just for simplicity. If the inventory file was a .yml there is more flexibility.

Group and Host Vars

The files inside these directories are for all the hosts or the individual hosts (switches). If it is not clear, anything in the group_vars/all.yml file contains variable for all the hosts, and anything in host_vars/ are for the hosts defined in the inventory. These file names reference the names in the inventory file.

For all the files, please see the GitLab project.

group_vars/all.yml

host_vars/172.16.1.101.yml

Roles

Inside the roles directory are the spine/leaf vars and tasks directories. The files nexusansible/nexus_evpn/roles/spine/vars/main.yml and nexusansible/nexus_evpn/roles/leaf/vars/main.yml contain all the variables that are shared for the switch type.

Spine Vars

Leaf Vars

The tasks files define the tasks that will be in each play of the playbook. There are two plays, one is the spine and the other is the leaf.
nexusansible/nexus_evpn/roles/spine/tasks/main.yml
nexusansible/nexus_evpn/roles/leaf/tasks/main.yml

Spine Tasks

Leaf Tasks

Playbook – site.yml

This file is the main playbook file. It will call the role tasks which intern call all the variables from the various files.

Verification – Show Commands

These show commands are all lifted from the show commands from the previous post

Show Commands

As there are multiple stages to this configuration, there are lots of show commands. Some of them overlap by showing the same information.

OSPF

OSPF is configured as point to point networks between each physical interface. All Ethernet and loopback interfaces are taking part in OSPF.

Spine1
Leaf1

PIM

PIM is active on all interfaces on the fabric, and each switch will have two PIM neighbours.

Spine1
Leaf1

Tenant

The tenant is the single business unit, organisation or customer that will reside in this single overlay. There can be multiple overlay networks for multiple tenants. All of them can have overlapping networks, but no communication between them.
The tenants will only be on the leaf switches.

Leaf1

NVE

The NVE will only be on the leaf switches. It is the virtual interface that is responsible for the VXLAN encaps/decaps. The idea of BGP EVPN is that when the leaf switch that is connected to the endpoints learns of the client, it will forward that over to the other leaf switches, Leaf2 in this case.

The output below shows the MAC addresses for the endpoint that have been learnt on the network. This will only work if traffic has been received by the leaf switch the endpoints are connected to.

The next command is similar to the previous, but contains the IP and MAC of the endpoints.

BGP

BGP or iBGP to be precise is the overlay network. It is responsible for the leaf switches to be able to form the VXLAN tunnels between one another, which allows the endpoints learnt on each leaf switch to be shared.

Leave a Comment

Your email address will not be published. Required fields are marked *