Network Automation has been an interest of mine for a few years, but I never quite had the opportunity to dive right in and do some of the cool stuff I had been reading about, mostly due to time limitations and deadlines.
Why spend two days automating something that takes four hours to build manually?
A lot of people
This question was asked many times, and whilst I knew the time taken to automate these tasks would eventually be beneficial, the tasks generally needed to be finished quicker than the time it would take to convince others that we needed to automate. And here we are, a few years later, writing a blog post about network automation, specifically automating my home network.
A quick primer on Network Automation
Traditionally network engineers have manually built, maintained and operated the physical network devices that connect the devices in our IT environments. As technology improves and people expect more out of the environments, these networks become increasingly more difficult to manage and much more relied upon. Therefore, the traditional methods are no longer cutting it.
Network automation solves a lot of the problems traditional network management causes, for example:
📜 Configuration drift – where the intended configuration of a device morphs over time and becomes inconsistent throughout the environment
📊 Limited monitoring
😬 Lack of standardisation
😩 Reactive Management
⚠️ Manually updating firmware, causing unintended outages.
With the advent of Software-Defined Networking (SDN), most networking companies now provide an interface that facilitates network automation.
Automating my Home Network
When I first began thinking about automating my network, I realised that it was probably not a good idea to start automating my current network, which I use daily! So, I needed an environment I could use as a sandbox, so I figured I could build a lab using my preexisting virtual infrastructure.
I work with enterprise environments in my day job, so I want to get as close as possible to what I typically see in enterprise networks.
Like any engineer, I start with a design. 😉
The Infrastructure Design
So, the design is something that I think needs to happen first. OK, I know that I have a home network already, so the design should already be there, but I wanted to pretend this was brand new! And for most of it, it will be.
What better way to share a design than with a network diagram!
OK, so let’s break this down into all the components.
The Physical Infrastructure
My physical infrastructure is super simple. I have a physical firewall running at the very edge of the network, which currently performs all of the security functions. I then have a layer 2 switch which connects my home and powers my access point.
Two physical hosts running a Proxmox hypervisor in a cluster are connected to this switch.
👉 Just to put it out there, the Proxmox hosts are preloved Lenovo ThinkCentre machines with an i5 processor and some RAM—not exactly jacked up. I don’t want anybody to think this was a full-blown rack server setup
That is it for the physical infrastructure; I have not gotten around to adding storage to the mix, so the Proxmox cluster currently uses local storage for those wondering where this guy’s storage is.
Stepping into the Virtual Infrastructure
Aren’t VMs cool? I know it’s old technology, and there’s much more out there now, but I still think they’re awesome. Anyway, inside my Proxmox cluster, I plan to deploy three new Ubuntu servers, each with docker installed.
The first server, let’s call it my network services VM, will run my common services, such as DNS, DHCP, and RADIUS. The second will run my automation stack, which I will discuss in more detail later. The third and final server will be dedicated to ContainerLab.
What is ContainerLabs, you ask? Well, I am glad you asked! Even though I was going to tell you anyway 😀
ContainerLabs
Until recently, I have mostly learned about networking on the job. When studying for certifications, I could access the physical hardware from the companies I worked for, so I didn’t really have to have a home lab. But when it comes to learning about automation, I am doing this solely in my spare time, so I need something to automate.
There are options, such as Cisco DevNet Sandboxes and Cisco Cloud Modelling Labs (CML), which would probably be easier as I start this journey. Still, I like to make things more difficult and, like I said earlier, closer to what the real world looks like, and the reality is that most companies run many different networking vendors, not just Cisco. So I need to learn how to automate across multiple vendors.
So I came across ContainerLab, and well, I was super intrigued. The official website says: “Containerlab provides a CLI for orchestrating and managing container-based networking labs. It starts the containers, builds a virtual wiring between them to create lab topologies of users choice and manages labs lifecycle.”
In summary, it’s a tool that lets you easily create Containerised Network Labs!
It potentially allows me to create a version of my home network running purely in ContainerLab to test my automation!
👉 Now, a bit of a caveat… I have not done this yet! This is purely theory at the moment. I have not yet worked out the resources required to run ContainerLab in the capacity to create an exact digital twin of my physical network. I may not be able to achieve this with my available resources. Still, I will have tried and hopefully learn much along the way.
Bridging the Virtual to the Physical
To provide connectivity from the Lab environment to the outside world, I will use a Linux Bridge to bridge my VMs to my physical network, utilising VLANs and my firewall to provide security.
The Labs within ContainerLab will have a single container using MACVLAN to bridge from the container to the VM, and the inception continues.
Infrastructure as Code
I can’t write a post about automation without mentioning Infrastructure as Code (IaC). Oh yes!
So as I was designing this lab environment, I thought to myself, why not automate the creation of the lab? So I began looking into how I could build this lab using some form of automation, and this is where I am starting. I will use Ansible to define this design as code and use a tool to deploy it.
Planning the workflow
I am not in a position to implement a full CI/CD pipeline now; I don’t even know if my plan will work. So, I am taking this slow and taking baby steps—again, I am taking the steps I would take if I were trying to automate an enterprise network. I will document each of these steps in future posts.
- Deploy Ubuntu VMs and Install Docker.
- Deploy/configure DNS, DHCP.
- Deploy a quick test topology in ContainerLab to ensure connectivity works as I expect it to.
- Build lab network topology based on existing home network.
Once I have the lab network set up, I can begin automating the network functions; I will not write about that quite yet, as I plan to build that into a full pipeline.
In my next post, I will go into what my automation stack is going to look like and show how I use Ansible to deploy the Ubuntu virtual machines in my Proxmox Cluster, Configure the network services and spin up a test topology using ContainerLab!