
Pytest is a Python testing framework. It is primarily used by developers to test their code and make sure it behaves as expected. For example, if you write a function that adds two numbers, you can write a test to verify that the function returns the correct result. If it does, the test passes. If not, the test fails, and pytest tells you exactly where things went wrong.
That is the traditional use case, but pytest is not limited to testing code. You can use it to test anything that can be scripted in Python, and that includes testing your network.
In this series, we will use pytest to write tests that connect to network devices and verify their state. For example, we can write a test that connects to a router and checks whether BGP is up. If BGP is up, the test passes. If not, the test fails. We can also check things like interface states, routing table entries, OSPF neighbours, or really anything else you can pull from a device.
Here is what nobody putting together the business case for a VM migration to Kubernetes will tell you upfront: the compute is the easy part.
Moving workloads off vSphere and onto Kubernetes is conceptually straightforward. The tooling has matured. The architecture is proven. Compute moves, storage remaps, and the platform team has a plan.
The network is where projects quietly stall.
Not because the technology does not work. Because nobody scoped the network properly before the project started. A platform migration turned into a multi-team coordination exercise. The firewall team needed a change window. The security team needed to review a network placement that changed when it should not have needed to. The application team discovered hardcoded IPs that nobody documented.
Six months later, half the VMs are still on vSphere and the project is technically “in progress.”
This is not a skills gap. It happens at the most mature organisations with capable teams. It is a scoping problem, and it has a specific cause: the gap between how VM networking works and how Kubernetes networking works is wider than it looks on a migration plan.
This post is for the people who approve these projects. Here is what Continue reading
This chapter explains how to build
a SONiC virtual test environment on a Windows computer. First, we enable the
required Windows features for WSL 2 and update and verify the WSL installation.
Next, we install an Ubuntu distribution and validate that the Linux environment
is working correctly, including basic resource checks (CPU, memory, and disk).
After the Linux environment is ready, we install Docker Engine from Docker’s
official repository and complete the required post-installation steps to run
containers. We then install Containerlab, download the SONiC virtual switch
image (docker-sonic-vs.gz), copy it into WSL, and load it into Docker.
Finally, we install Visual Studio Code on Windows and connect it to WSL to make
creating and editing the YAML topology files easier. The next chapter uses this
environment to define and deploy a simple SONiC-based topology.
WSL 2 requires two Windows
features to be enabled. The first feature, Microsoft-Windows-Subsystem-Linux
(Example 1-1), enables WSL. The second feature, VirtualMachinePlatform
(Example 1-2), is required to run WSL 2.
In this
example, both features are enabled using Microsoft PowerShell (Run as
Administrator) with the dism.exe command. The options used are:
In the first quarter of 2026, government-directed shutdowns figured prominently, with prolonged Internet blackouts in both Uganda and Iran, a stark contrast to the lack of observed government-directed shutdowns in the same quarter a year prior. This quarter, we also observed a number of Internet disruptions caused by power outages, including three separate collapses of Cuba's national electrical grid. Military action continued to disrupt connectivity in Ukraine and also impacted hyperscaler cloud infrastructure in the Middle East. Severe weather knocked out Internet connectivity in Portugal, while cable damage disrupted connectivity in the Republic of Congo. A technical problem hit Verizon Wireless in the United States, and unknown issues briefly disrupted connectivity for customers of providers in Guinea and the United Kingdom.
This post is intended as a summary overview of observed and confirmed disruptions and is not an exhaustive or complete list of issues that have occurred during the quarter. A larger list of detected traffic anomalies is available in the Cloudflare Radar Outage Center. Note that both bytes-based and request-based traffic graphs are used within this post to illustrate the impact of the observed disruptions, with the choice of metric generally made based on which better illustrates the Continue reading
@sjhloco wrote an excellent in-depth description of how you can use containerlab and netlab to manage your labs as code.
He also documented a few netlab shortcomings (one of which caused a crash); fortunately, I found his blog post (admittedly over a year later) and fixed most of them in release 26.04:

One of the things I’ve noticed when it comes to IT is how quickly we’re willing to use software to solve people problems. Over my career I’ve seen all manner of crazy solutions to get around people being lazy or uneducated. Remember vMotion? Or OTV for stretched layer 2? Why do you think those solutions came about? I posit that it’s because it’s faster to write software than to patch people.
I see this most often in cybersecurity. Developers love to create software solutions that prevent things from happening. Phishing and all its various forms are some of the top priorities for solutions that prevent leaking of information. While we have invested a lot in phishing tests and education it’s also very likely that there are controls in place that prevent users from accidentally giving out information to threat actors.
Why are we so willing to write software to fix problems instead of teaching people to avoid those issues? I think in part it’s because software is predictable. If I create an app or write some controls into a platform it’s going to behave the same way every time. That’s the definition of deterministic. Every time the software Continue reading
I stopped tracking the (lack of) progress in network automation years ago, when I realized I had nothing new to say. As an eternal optimist, I hoped I was just missing something, but Urs Baumann (the guest of Software Gone Wild Episode 206) destroyed my hopes when he said, “I can still use the same slides I created 10 years ago”. On a more positive note, he recently completed his Master’s thesis on AI in network engineering, so we ended with a nice chat on its potential impact.
In this roundtable episode of the Hedge, Eyvonne, Tom, and Russ hang out and talk about data centers–why are we building all these things again? Our second topic is the FCC’s ban on non-US made home routers. Was this the right thing to do? Was it the wrong thing to do? Were there any other policy options?
download