billgrant.io

Source Code In the last post we covered configuring a single FortiGate named Core-DC. In this post we need to configure two FortiGates that will act as hubs in the SDWAN lab. The current design of the lab looks like this. LAB Design Using Modules Hub1 and Hub1 are what we are going to focus on in this post. The majority of the configuration is the same on the two devices, the main differences are the IP addresses. [Read More]

Source Code Now that FortiOS 7.0 has been out for a bit, I decided it was time to redesign my home SDWAN/ADVPN lab for 7.0.1. I started off building it manually, but then I thought, why not use Terraform to build the infrastructure so that I can easily add or remove devices as needed. I am going write this a multi part series starting with a single FortiGate that I use as a router. [Read More]

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]

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]

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]

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]

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]

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]

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]

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]