After the release of the Ubuntu 24.04 edition of Linux For Network Engineers (LFNE) I’ve got some questions from the community. Here are two new flavors of LFNE based on your requests.
LFNE AlmaLinux 10 OS
For Red Hat fans who prefer a RHEL-style environment. Since CentOS is no longer maintained, AlmaLinux is the closest drop-in replacement and offers the same look and feel many engineers are used to.
docker pull ipnetxyz/lfne:almalinux-10
LFNE Alpine 3.22 OS
A lightweight edition designed for speed and efficiency. Alpine has a very small footprint, making it ideal for environments where resources are tight or for users who prefer a minimal base to build upon.
docker pull ipnetxyz/lfne:alpine-3.22
Same Tools, Different Base
All editions come with the same curated toolset of networking utilities, Python libraries, and automation tools. The main difference is the base operating system:
Edition
Base OS
Best For
Notes
Ubuntu 24.04
Ubuntu LTS
General use, widest compatibility
Easiest to get started with
AlmaLinux 10
RHEL-style OS
Red Hat fans, enterprise-like environments
Drop-in CentOS successor
Alpine 3.22
Alpine Linux
Lightweight setups, minimal footprint
Very small and fast
If you’re new to LFNE, check out the Ubuntu 24.04 post for the full list of included tools and usage details.
Arista AVD (Architect, Validate, Deploy) – https://avd.arista.com – is a powerful tool that brings network architecture into the world of Infrastructure-as-Code. I wanted to try it out in a lab setting and see how it works in a non-standard environment.
Since my go-to lab tool is GNS3 with Arista cEOS images — while the AVD documentation is primarily built around vEOS — I ran into a few issues. After some troubleshooting, I got it working, and I’d like to share the process here.
This is not a full deployment guide for AVD. Instead, I’ll walk you through the setup I used to make it work in a test environment using GNS3 and cEOS images.
Prerequisites
Make sure your Ansible host has at least 2048MB of memory — I encountered memory-related errors that were otherwise unrelated to the steps below.
Environment Setup
Make sure you’re in your user’s home directory. In my case, the user is debian on the Ansible host.
The above will activate a virtual environment for pip use and install the needed packages. The Ansible collections will under .ansible in the home directory.
Copy the AVD example configurations to a work directory (I chose avd)
mkdir avd
cd avd
ansible-playbook arista.avd.install_examples
Make sure you are now be in the ~/avd/ directory to avoid future errors.
My GNS3 topology follows exactly the scenario above in terms of switch number, naming, connections, etc…
Tweak Ansible Config
By default, Ansible only warns when encountering duplicate keys in YAML files. Arista recommends treating this as an error to ensure cleaner configurations.
Update the ansible.cfg in the project folder:
sed -i '/^jinja2_extensions/a\duplicate_dict_key=error' single-dc-l3ls/ansible.cfg
Make sure unreachable, failed, and skipped are all 0 — that’s your confirmation that everything went smoothly.
Summary
While AVD examples are designed around vEOS, it’s perfectly possible to adapt it for cEOS in GNS3 with a few changes. The most important steps involve:
Updating interface names
Ensuring management connectivity stays up
Modifying inventory and config files accordingly
This lab-friendly workflow lets you explore AVD’s potential without dedicated hardware or CVP.
I would like to start by saying Merry Christmas and Happy Holidays season to all. In between spending time with my family, decorating the Christmas three and opening presents, I did find some time to play around with my hobby and testing something in the lab.
Lately I wanted to get a feeling how F5 BIG-IP works, you know, just to get familiar with its interfaces, rules and being capable of setting up a basic LTM or APM. Far from me the idea of becoming an expert on the first touch, but it’s nice to discover new technologies.
Beside getting the F5 BIG-IP VE (Virtual Edition), running up VMware (ESXi, Player, Fusion or Workstation) and starting the virtual machine I also wanted to emulate some kind of real environment to test. So, I did build the below topology in GNS3:
Some explanation:
Client WIN7 is a VM in VirtualBox and integrated in GNS3
WWW Servers are VMs in VirtualBox and integrated in GNS3
WIN2008 AD DC is a VM in VirtualBox and integrated in GNS3
Routers are emulated in GNS3
F5 BIG-IP VE is a VM in VMware Workstation and integrated as a Cloud in GNS3
GNS3 is version 1.2.1 which works perfect. Why VirtualBox and VMware Workstation? Usually I have no problem to have my VMs in VirtualBox, but I could not successfully import the F5 BIG-IP VE OVA image in VirtualBox. I had to download a trial version of VMware Workstation to install the OVA image.
Download the BIG-IP VE OVA image, get a trial license (valid for 90 days) and install it in VMware Workstation. It may work with other VMware products, but in this article I’m using only VMware Workstation.
The part that gave me some headache was the how to have a successfully network communication between VMware Workstation and GNS3.
Before GNS3 1.2.1, when I had to use a “cloud” to integrate VirtualBox VMs in GNS3, I was configuring a TAP interface and use Bridge mode for the VM NIC to the TAP interface. Then on the GNS3 Cloud, I was adding the TAP as a Generic Ethernet NIO on the NIO Ethernet. If you want to refresh more deeply the above information please read my article about How to integrate GNS3 with VirtualBox.
Unfortunately, in VMware Workstation, I cannot just bridge a VMnet interface to a TAP and use that specific VMnet in a VM. I just could not make it work.
To cut it short, here are the steps that I had to follow to have this working. I assume that you have VMware Workstation installed already. Another detail is that I’m using Ubuntu 14.04 to test the entire scenario.
1. Add two VMnet interfaces in VMware Workstation Virtual Network Editor
Use the image below to have an idea what I mean.
2. Configure the BIG-IP VE NIC as follow in VMware Workstation
I assume that you have the BIG-IP VE OVA imported in VMware Workstation
I had 4 NICs originally, but I only need three:
VMnet0 is bridge to my real LAN interface so I can manage the F5 BIG-IP VE over Web / CLI interfaces
VMnet11 – one “internal” interface facing LAN (server side)
VMnet22 – one “external” interface facing WAN (client side)
3. Configure two tap interfaces for F5 BIG-IP VE to be used in GNS3
11 – internal, 22 – external
sudo tunctl -u user -t tap11
sudo tunctl -u user -t tap22
*user = the non-root user which you use on Ubuntu host.
If you are having problems to find tunctl command please do the following:
sudo apt-get install uml-utilities bridge-utils
Bring the interfaces up
sudo ifconfig tap11 up
sudo ifconfig tap22 up
4. Remove the IP addresses on both TAP and VMnet interfaces
sudo ifconfig tap11 0.0.0.0 promisc up
sudo ifconfig tap22 0.0.0.0 promisc up
sudo ifconfig vmnet11 0.0.0.0 promisc up
sudo ifconfig vmnet22 0.0.0.0 promisc up
If with GNS3 1.2.1 you can add the VirtualBox VMs directly, for the VMware Workstation (Player, Fusion, etc…) VMs you still need to you the Cloud part.
My GNS3 for F5 topology looks like this:
And the GNS3 Cloud (representing the F5 BIG-IP VE) settings are the following:
6. Connect the GNS3 Cloud interfaces to R1 and R2
Like shown in the image above, connect the TAP interface of the Cloud to the peer routers.
I’m running all applications (GNS3, VMware Workstation, VirtualBox) as non-root user. If you’re doing the same an error may occur in GNS3. Something like:
Server error [-3200] from x.x.x.x:8000: R1: unable to create TAP NIO
If this is the case, please run the following command on Ubuntu host:
This will help you setup the environment to test F5 BIG-IP VE in a lab environment totally virtualized. I’m not going to cover here how to configure the F5 BIG-IP VE. Maybe in one of my next articles.
If you encounter problems, please let me know in Comments.
It appears that there are some significant changes ongoing with GNS3.
As mentioned by the GNS3 CEO and co-founder Stephen Guppy on 11th of August 2014, the new GNS3 will be more polished and will migrate to a multi-vendor emulation platform. For those using this tool, it’s a well known fact that GNS3 was mainly focused to emulate Cisco platform, evolving to support vPC and VirtualBox virtual machines.
They have a new very polished website accessible at new.gns3.net where you can also download the GNS3 1.0 Beta 1 software.
I did grab a copy of the Beta 1 and installed on a Windows system (the only one which had right now on hands). You can see a screenshot below.
To be honest, first impression is that not much did change, except some buttons / icons here and there. Of course this just after a quick look from my side. I will test the software in the next days and come back with an update.
If interested, you can check the press release from 26th of August 2014 for more details about upcoming changes in the GNS3 organisation.