
We all write code, but how do we know the changes we make in the future won’t break something that used to work? That’s where testing becomes important.
The idea is to catch problems early, ideally before they reach production. In the Python world, one of the most common ways to do this is with a tool called pytest. It lets you write tests to check that your code behaves the way you expect and helps you catch issues before they become a bigger problem.
Originally published under - https://www.opsmill.com/pytest-plugin-infrahub/
When working with Infrahub, testing is just as important. You might want to make sure your GraphQL queries are valid, your Jinja2 templates render correctly, or your transformations behave as expected.
Infrahub simplifies this by offering a pytest plugin that doesn’t require Python code; you define tests using plain YAML. This makes testing more accessible to teams across roles and speeds up the feedback loop during development.
These kinds of unit tests aren’t just about convenience, they help establish a production-ready automation system. With automated checks built into your process, every change is validated consistently, reducing the chance of something breaking unexpectedly. That consistency builds trust when your Continue reading
I got an interesting question from a reader. He listened to my podcast with Eric Chou and decided to try to learn in public:
Currently, I’m studying for the CCNP ENARSI exam, and would like to start posting my labs to LinkedIn, and perhaps even upload my lab topologies and configs to Git.
That’s a great idea. I would minimize the LinkedIn part1 and focus on Git:
This guide walks you through installing and configuring the ELK Stack (Elasticsearch, Logstash, Kibana, and Filebeat) using Docker Compose. It is fully updated for Elasticsearch 9.0.2 and explains the necessary changes for versions 8+ and above, including the required security setup and user permissions. Prerequisites Ensure you have the following installed on your system: The […]
<p>The post Deploying ELK Stack with Docker Compose (2025 Edition) first appeared on IPNET.</p>

TL;DR - For anyone who doesn’t want to go through the full post, here’s the short version. I bought the UGreen NASync DXP2800 (2 bay) from Amazon for £249 and paired it with two Seagate Ironwolf 8TB HDDs, around £180 each.
The unit comes with an Intel N100 CPU, 8GB of RAM (upgradeable to 16GB, but there’s only one RAM slot), and a 2.5Gb/s LAN port. It has a solid build, was easy to set up, and I actually like the UI. Sure, it lacks a lot of features compared to Synology or QNAP, but since I’m mainly using it for file storage, I’m happy with the purchase.

The short answer is, this is the best bang for the buck. For £249, I’m getting a 2-bay NAS with an N100 CPU, 8GB of RAM, a 2.5Gb/s LAN port, and two NVMe slots.
I’ve been wanting to buy a NAS for over Continue reading
Password hygiene drives IT professionals crazy–people forget their passwords, will not change them often enough, and choose weak ones. But are IT folks immune to these problems? What is the psychology behind passwords, and how do we do better? Karl Buhl joins Tom and Russ to talk about passwords.
download
We know there are three main ways to move packets across a network. However, before we can start forwarding packets, someone has to populate the forwarding tables in the intermediate devices or build the sequence of nodes to traverse in source routing.
Usually, whoever is responsible for the contents of the forwarding tables must first discover the network topology. Let’s start there, using the following network diagram to illustrate the discussion.

If you follow me or read my blog, you probably know I'm a big advocate of Containerlab. I've been using it for over two years now and I absolutely love it. Why? Because it's open source, it has an amazing community behind it (thank you again, Roman), and labs are defined using simple YAML files that are easy to share and reuse.
So far, I've used Cisco IOL, Arista EOS, and Palo Alto VM in Containerlab. And finally, the time came to try Juniper. I decided to test the Juniper vJunos-router, which is a virtualized MX router. It's a single-VM version of vMX that doesn't require any feature licenses and is meant for lab or testing purposes. You can even download the image directly from Juniper's website without needing an account. Thank you, Juniper and Cisco, please take note. In this post, I'll show you how to run Juniper vJunos-router in Containerlab.
This post assumes you're somewhat familiar with Containerlab and already have it installed. If you're new, feel free to check out my introductory blog below. Containerlab also has great documentation on how to use vJunos-router, so be sure to check that out as well.
If the device you are reading this on has an IPv4 address, it is very likely not a publicly routeable one. This is because the wide scale dep
Just when you thought you got used to the weirdnesses in the networking implementations, you get a curveball like this one. Life is never dull if you test network devices.
Before releasing netlab release 2.0, I ran the full suite of integration tests for all devices for which I have the images. Interestingly, most VXLAN tests failed for Cumulus Linux 4.x even though we haven’t touched that code for ages.
Next step: trying to figure out what changed. The configuration changes were minimal. Even worse, the failure was non-deterministic. Somehow, we managed to transform a Cumulus Linux 4.x VM into a Heisenberg switch.
If you’ve managed traffic in Kubernetes, you’ve likely worked with Ingress controllers. For years, Ingress has been the standard way to expose HTTP and HTTPS services. But in practice, it often came with trade-offs. Controller-specific annotations were required to unlock critical features, the line between infrastructure and application responsibilities was unclear, and configurations often became tied to the implementation rather than the intent.
Recently, the Kubernetes community announced that Ingress NGINX will be formally retired, with only best-effort maintenance provided until March 2026. After that point, there will be no bug fixes, no security updates, and the project will move to read-only archival status. Any cluster still relying on Ingress NGINX after that date will be running an unsupported controller, which increases maintenance overhead and security risk.
For many organizations, now is the time to treat this as a high-priority project: inventory all clusters using Ingress NGINX, create a migration plan (test, convert, cut over), and avoid ending up in a reactive scramble as the March 2026 deadline approaches.
If the move from Ingress to the Gateway API once felt optional, this new timeline changes the situation. Depending on an aging data-plane component without Continue reading
Jo attempted to follow the vendor Kool-Aid recommendations and use NETCONF/YANG to configure network devices. Here’s what he found (slightly edited):
IMHO, the whole NETCONF ecosystem primarily suffers from a tooling problem. Or I haven’t found the right tools yet.
ncclient is (as you mentioned somewhere else) an underdocumented mess. And that undocumented part is not even up to date. The commit hash at the bottom of the docs page is from 2020… I am amazed how so many people got it working well enough to depend on it in their applications.