On Tuesday, July 9th, 2024 I will be presenting a talk at NetUK1.

Blurb

Design-Driven Infrastructure Automation

Abstract

Building and managing Infrastructure has always been driven by architecture and design but surprisingly these concepts aren’t easy to integrate into the toolset that makes it possible to manage networks and infrastructure in general with automation.

In this presentation we’ll discuss how to manage a network with a Design first approach, based on Infrahub a new open-source Infrastructure management platform.

On Thursday, October 26th, 2023 I co-presented a talk at NetDevOps Days NYC along with Jerrod Gerth at Nokia.

Blurb

Test it first! Taking a DevOps approach to network labs.

Abstract

This joint talk from IP Fabric and Nokia will cover the “why” and “how” of building software-based network labs suitable for learning, testing, and validating changes. It will include discussion of:

• Theory: Why are network labs needed? A discussion of network simulation options and the use cases it can solve
• Real world: How to use Containerlab for network labs

Presentation

Presentation-as-code generated via marp and stored in GitLab: netdevops-days-2023-10

On Friday, June 30th, 2023 I gave a talk at NetDevOps Days London on Explaining the business value of network automation - Or why I succeeded the second time around. The YouTube video recording is embedded below:

This post is part two of two, where I’ll cover how you can use network simulation and emulation tools to validate changes, and the limits of each approach. Please read the previous post covering network simulation concepts for further context before reading the rest of this post.

Ok, What Can Be Tested?

As a reminder, the goal is pre-change network validation. What are examples of things that a network engineer might want to test? Here’s a few of the most common scenarios:

Every few weeks I’m asked about why we¹ can’t do pre-change network validation. Most network engineers don’t understand the nuances and details around this topic, and there’s very few words published on this, so it’s time for me to discuss what constitutes network simulation, network emulation, and what the challenges are around trying to validate network changes before they’re put in to production.

This is part one of two, where I’ll dive in to defining network simulation and some example tools. Then in the next post, I’ll cover how you can use these building blocks to validate changes, and the limits of each approach.

I needed to do some testing of Juniper Contrail API calls, and for that I could use some Juniper switches controlled by Contrail. As Juniper has recently launched a virtual vEX image, I figured I’d give it a go. Below are build instructions for creating a vagrant box for Juniper vEX.

Tools

• Vagrant: Vagrant from Hashicorp. Vagrant is a tool for building and managing virtual machine environments in a single workflow.
• vEX: The Juniper vEX VM images. Note I’m using a KVM (qcow2) image, and that a support login is required to download the images.

Workflow

1. Download a qcow2 version of the Juniper vEX VM

I am using version 23.1R1.8 for this example. The filename I downloaded was named vjunos-switch-23.1R1.8.qcow2.

On Friday, June 30th, 2023 I’ll be giving a talk at NetDevOps Days London.

Blurb

Explaining the business value of network automation - Or why I succeeded the second time around.

Abstract

At a previous $dayjob I was brought on board a network engineering team to bring in some expertise in network automation. Along the way, I built a greenfield DC in the UK fully automated, just to watch manual config changes happen on day 2, and the code abandoned. I’ll discuss what I learned about making sure leaders are aligned on the business value of automation, and how I succeeded at the next major project, including why we chose Ansible and netbox as the core of the solution.

I have created a simplified version of the Opengear ansible role I’m using in my production DC deployment. See link to the repo below. Opengear’s configuration is a mix of unix and it’s own internal database. To make matters more challenging, the Opengear config format is not really idempotent so you have to watch out when doing tasks like creating new users. So my hack is to essentially overwrite existing users every time I do an ansible playbook run. May this hack of a role help you figure out how to config your console servers more quickly.

I needed to replicate a Juniper SRX firewall to create and test a BGP config for a customer. I could have done this in GNS3/EVE-NG or some other virtual enviornment, but I find that Vagrant/Libvirt gives me the most usability when trying to reuse a setup over time, such as for automated testing.

So with that goal in mind, I needed to create a vagrant box of Juniper’s vSRX firewall, but specifically for use with libvirt. Multiple times I’ve drawn from Brad’s blog which has a great Juniper vMX example. So I’ll take a similar approach.

I’ve been using 1password as my password manager for many years. They’ve recently released 1password for Linux. I created a quick ansible role to deploy it. It’s not pretty since I couldn’t figure out the cleanest way to deal with gpg, so improvements would be appreciated!

ansible_role_1password_linux

Requirements

• Tested on Ubuntu 20.04

Role Variables

None

I’ve been keeping an email archive in an SQL database for years, and using MailSteward Pro to make easy work of adding to the archive. I recently had to re-setup my servers, and created an ansible role to make setup of mysql easier. MailSteward wants some non-standard sql password settings, and by default SQL connections are allowed only from localhost, so that needs to be changed.

ansible_role_mailsteward_mysql

Requirements

• Tested on Ubuntu 20.04

Role Variables

Available variables are listed below:

Great things are done by a series of small things brought together – Vincent van Gogh

I recently finished the networking deployment for a £35m greenfield DC in the UK. One of the enjoyable parts of this DC build was starting the entire deployment and automation stack from a Raspberry Pi:

Nice example of going from one extreme in ARM CPU computing to the other.

I needed to replicate a production Fortinet firewall environment to do some testing. I could have done this in GNS3/EVE-NG or some other virtual enviornment, but I find that Vagrant/Libvirt gives me the most usability when trying to reuse a setup over time, such as for automated testing.

So with that goal in mind, I needed to create a vagrant box of Fortinet’s FortiVM firewall, but specifically for use with libvirt. Multiple times I’ve drawn from Brad’s blog which has great Arista vEOS and Juniper vMX examples. So I’ll take a similar approach.

My home router is a Ubiquiti EdgeMAX router running EdgeOS 2.0.6. I chose it because wanted a router that could run sflow for testing purposes. I recently came across someone successfully installing Prometheus node_exporter on EdgeOS, so I gave it a try. Since I’d already ansible-automated the install of node_exporter on a switch running Cumulus Linux, I wrote a new playbook with only minor modifications for EdgeOS and it worked perfectly.

Example code used here can be found on Gitlab

I’ve decided to try and document the useful workflows and code I’ll generate during my upcoming new job. Here’s how I went about automating the creation of these blog pages and publishing of this blog to a directory on my web server. I’ll first focus on the process and code, then at the bottom of this page will be descriptions about why I’ve chosen these tools and specific workflow.

Tools

• Hugo: A open-source static site generator
• Ananke: The Hugo theme used for the blog
• GitLab: SCM (Source Code Management) tool/site including CI pipelines
• VS Code: My preferred code editing platform
• GitKraken: A GUI for git because I’m lazy sometimes

Workflow

1. Init a repo It’s easiest to setup a git repository first, then proceed with all the remaining steps by creating the files in the repo directory. To do this manually:

git-init blog

I’m lazy, so I use GitKraken to both create and init my repo on Gitlab:

I needed to do some testing of Juniper Contrail API calls, and for that I could use some Juniper switches controlled by Contrail. As Juniper has recently launched a virtual vEX image, I figured I’d give it a go. Below are build instructions for creating a vagrant box for Juniper vEX.

Tools

• Vagrant: Vagrant from Hashicorp. Vagrant is a tool for building and managing virtual machine environments in a single workflow.
• vEX: The Juniper vEX VM images. Note I’m using a KVM (qcow2) image, and that a support login is required to download the images.

Workflow

1. Download a qcow2 version of the Juniper vEX VM

I am using version 23.1R1.8 for this example. The filename I downloaded was named vjunos-switch-23.1R1.8.qcow2.

I needed to replicate a Juniper SRX firewall to create and test a BGP config for a customer. I could have done this in GNS3/EVE-NG or some other virtual enviornment, but I find that Vagrant/Libvirt gives me the most usability when trying to reuse a setup over time, such as for automated testing.

So with that goal in mind, I needed to create a vagrant box of Juniper’s vSRX firewall, but specifically for use with libvirt. Multiple times I’ve drawn from Brad’s blog which has a great Juniper vMX example. So I’ll take a similar approach.

I needed to replicate a production Fortinet firewall environment to do some testing. I could have done this in GNS3/EVE-NG or some other virtual enviornment, but I find that Vagrant/Libvirt gives me the most usability when trying to reuse a setup over time, such as for automated testing.

So with that goal in mind, I needed to create a vagrant box of Fortinet’s FortiVM firewall, but specifically for use with libvirt. Multiple times I’ve drawn from Brad’s blog which has great Arista vEOS and Juniper vMX examples. So I’ll take a similar approach.

I’ve decided to try and document the useful workflows and code I’ll generate during my upcoming new job. Here’s how I went about automating the creation of these blog pages and publishing of this blog to a directory on my web server. I’ll first focus on the process and code, then at the bottom of this page will be descriptions about why I’ve chosen these tools and specific workflow.

Tools

• Hugo: A open-source static site generator
• Ananke: The Hugo theme used for the blog
• GitLab: SCM (Source Code Management) tool/site including CI pipelines
• VS Code: My preferred code editing platform
• GitKraken: A GUI for git because I’m lazy sometimes

Workflow

1. Init a repo It’s easiest to setup a git repository first, then proceed with all the remaining steps by creating the files in the repo directory. To do this manually:

git-init blog

I’m lazy, so I use GitKraken to both create and init my repo on Gitlab:

One of my kids is an early riser. And for the last year, that meant we’re all early risers, regardless of if we’ve gotten enough sleep. So in an effort to have everyone well rested, I’ve put a small 3.5" TFT screen on an unused Raspberry Pi and coded up a simple HTML page, CSS stylesheet and javascript to display a fullscreen clock on boot. In addition, the background of the clock is green when it’s between 7am and 7pm, and red during the night. Coding was the easy part. Getting my child to pay attention to it is now the tough part!

My home router is a Ubiquiti EdgeMAX router running EdgeOS 2.0.6. I chose it because wanted a router that could run sflow for testing purposes. I recently came across someone successfully installing Prometheus node_exporter on EdgeOS, so I gave it a try. Since I’d already ansible-automated the install of node_exporter on a switch running Cumulus Linux, I wrote a new playbook with only minor modifications for EdgeOS and it worked perfectly.

Example code used here can be found on Gitlab