VSCode Remote Development

Source Code Visual Studio Code Remote Development is a new feature that allows for developing in a remote OS or a container. The reason I have stayed away from writing my code inside a Docker container was because I like to run things and debug them as I write them in VSCode. devcontainer The devcontainer.json file will reside in the project folder inside a folder called .devcontainer. This file tells VSCode the information it needs to run the container. [Read More]

Ansible VXLAN Lab Part 1

Building the underlay

Source code I wanted to give myself a refresher on VXLAN. I have worked with a bit on and off, however, most of my day to day is usually enterprise networking outside of the data center. I was going to just stand up a lab and mess around, but I figured why not create the lab with Ansible so I can spin it up again at anytime. It is going to be a standard flood and learn design. [Read More]

Ansible VXLAN Lab Part 2

Building the Overlay

Source code In the last post we built the underlay for the VXLAN topology below. Topology IP Addresses Device Interface IP <> Device Interface IP spine01 eth1 172.16.0.1/30 <> leaf01 eth1 172.16.0.2/30 spine01 eth2 172.16.0.5/30 <> leaf02 eth1 172.16.0.6/30 spine01 eth3 172.16.0.9/30 <> leaf03 eth1 172.16.0.10/30 spine01 eth4 172.16.0.13/30 <> leaf04 eth1 172.16.0.14/30 spine01 lo0 192. [Read More]

Cumulus Management with Ansible

Manage Cumulus switches with Ansible

As I mentioned in my last few posts, in the past I have used Ansible only when I needed it. I think part of the reason for this was because I felt like all of the things I wanted to do that were built into Ansible’s modules were for linux systems. So instead of coding my own Ansible module, I would just write my own Python script. I recently tried out Cumulus VX, which is a free VM download for learning purposes. [Read More]

Ansible for BGP Configuration

Manage multi-vendor BGP configurations

In the last post we built an Ansible playbook to manage interfaces on EOS and NX-OS switches. In this post we are going to add BGP configuration to advertise the loopbacks we created early. Updated Topology The only change in the drawing is the addition of the AS numbers. Update host_vars We will start with the files created in the last post. . ├── ansible.cfg ├── backup ├── group_vars │ ├── eos. [Read More]

Ansible for Network Configuration

Manage multi-vendor interface configurations

I have noticed lately that when other network engineers talk about automation they always bring Ansible into the conversation. I tend to prefer using Python with Napalm or Netmiko to write my network automation scripts. However, it was actually attempting to fix/maintain someone elses Ansible script that started me on my path of learning Python. I recently decided to try and rewrite some of my scripts using Ansible to see if maybe it is time to start using Ansible again. [Read More]

L3LS Automation Part 5

In this post we are going to modify the configuration that was pushed to the devices in part four. we are going to add a new VLAN and subnet to the each of the leaf switches. We do not have to update the python code. We just have to add the data to our yaml files, which in a production environment could be a database, an IPAM server for example. [Read More]

L3LS Automation Part 4

We made it to the part where we are going to actually configure something using python. In this post we are going to add a function called deployconfig that will check for diffs in the the running config against our templates. If any are found the configuration will be updated. To accomplish this we are going to use Napalm. Topology Here are the changes to configureleafspine.py configureleafspine.py #!/usr/bin/env python3 from jinja2 import Environment, FileSystemLoader import yaml from napalm import get_network_driver class ConfigureLeafSpine(): """Class to configure and maintain leaf spine switches""" --snip-- def deployconfig(self): """Checks for diffs and deploys configs using NAPALM""" driver = get_network_driver('eos') for key, value in self. [Read More]

L3LS Automation Part 3

Generating Spine Configuration

This part is going to be very similar to part two. The only difference is we are going to generate the leaf configuration this time. Topology The first step is to update ‘hosts.yaml` hosts.yaml Leaf-1 leaf-1: managementip: 198.51.100.252/24 managementgw: 198.51.100.1 site: ny role: leaf interfaces: - number: 1 ip: 172.16.0.2/30 description: P2P Link to Spine-1 - number: 2 ip: 172.16.0.10/30 description: P2P Link to Spine-2 loopbacks: - number: 0 ip: 192. [Read More]

L3LS Automation Part 2

Generating Leaf Configuration

In part two of this series we are going to extend the data files and templates created in part one. We will also be adding a function to the previously created class ConfigureLeafSpine. Part 1 can be found here. We are going to be adding the IP and BGP parameters for the spine switches. Then we will generate the configs. Topology The first step is to update hosts.yaml. hosts.yaml Spine-1 spine-1: managementip: 198. [Read More]