One of the last things I did before starting the 2022 summer break was to push out the next release of netsim-tools.

It includes support for routed VLAN subinterfaces (needed to implement router-on-a-stick) and routed VLANs (needed to implement multi-hop VRF lite), completing the lengthy (and painful) development of the VLAN configuration module. Stefano Sasso added VLAN support for Mikrotik RouterOS and VyOS, and Jeroen van Bemmel completed VLAN implementation for Nokia SR Linux. Want to see VLANs on other platforms? Read the contributor guidelines and VLAN developer docs, and submit a PR.

I’ll be back in September with more blog posts, webinars, and cool netsim-tools features. In the meantime, automate everything, get away from work, turn off the Internet, and enjoy a few days in your favorite spot with your loved ones!

There are (at least) two steps to get new functionality (like VLANs) implemented in netsim-tools:

• We have to develop a data transformation module that takes high-level lab-, node-, link- or interface attributes and transforms them into device data.
• Someone has to create Jinja2 templates for each supported device that transform per-device netsim-tools data into device configurations.

I usually implement new features on Cisco IOSv and Arista EOS¹, Stefano Sasso adds support for VyOS, Dell OS10, and Mikrotik RouterOS, and Jeroen van Bemmel adds Nokia SR Linux and/or SR OS support. That’s less than half of the platforms supported by netsim-tools, and anything you could do to help us increase the coverage would be highly appreciated.

Last two weeks we focused on access VLANs and VLAN trunk implementation in netsim-tools. Can we combine them with VRFs? Of course.

The trick is very simple: attributes within a VLAN definition become attributes of VLAN interfaces. Add vrf attribute to a VLAN and you get all VLAN interfaces created for that VLAN in the corresponding VRF. Can’t get any easier, can it?

How about extending our VLAN trunk lab topology with VRFs? We’ll put red VLAN in red VRF and blue VLAN in blue VRF.

A friend of mine started using Vagrant with libvirt years ago (it was his enthusiasm that piqued my interest in this particular setup, eventually resulting in netsim-tools). Not surprisingly, he’s built Vagrant boxes for any device he ever encountered, created quite a collection that way, and would like to use them with netsim-tools.

While I didn’t think about this particular use case when programming the netsim-tools virtualization provider interface, I decided very early on that:

• Everything worth changing will be specified in the system defaults
• You will be able to change system defaults in topology file or user defaults.

Last week I described how easy it is to use access VLANs in netsim-tools. Next step: VLAN trunks.

We’ll add two Linux hosts to the lab topology used in the previous blog post, resulting in two switches, two Linux hosts in red VLAN and two Linux hosts in blue VLAN.

I had no idea how convoluted VLANs could get until I tried to implement them in netsim-tools. We’re not done yet – we have access VLANs, VLAN trunks (including native VLAN support), and VLAN (SVI) interfaces, but we’re still missing routed VLAN subinterfaces – but we have enough functionality to show you a few VLAN examples.

We’ll start with the simplest option: a single VLAN stretched across two bridges switches with two Linux hosts connected to it. netsim-tools can configure VLANs on Arista EOS, Cisco IOSv, VyOS, Dell OS10, and Nokia SR Linux. We’ll use the quickest (deployment-wise) option: Arista EOS on containerlab.

Using Terraform to deploy networking elements with an SDN controller that cannot replace the current state of a tenant with the desired state specified in a text file (because nobody ever wants to do that, right) sounds like a great idea… until you try to do it at scale.

Noël Boulene hit interesting scalability limits when trying to provision VLANs on Cisco ACI with Terraform. If you’re thinking about doing something similar, you REALLY SHOULD read his article.

Are you afraid the network automation will eat your job? You might have to worry if you’re a VLAN-provisioning CLI jockey, but then you’re not alone. Textile workers faces the same challenges in 19th century and automation report from 1958 the clerical workers were facing the same dilemma when the first computers were introduced.

Guess what: unemployment rate has been going up and down in the meantime (US data), but mostly due to various crisis. Automation had little impact.

I’m usually telling networking engineers seriously considering whether to automate their networks to cleanup their design and simplify the network services first.

The only reasonable way forward is to simplify your processes – get rid of all corner cases, all special deals that are probably costing you more than you earned on them, all one-off kludges to support badly-designed applications – and once you get that done, you might realize you don’t need a magic platform anymore, because you can run your simpler network using traditional tools.

While seasoned automation practitioners agree with me, a lot of enterprise engineers face a different reality. Straight from a source that wished to remain anonymous…

I stumbled upon a blog post by Diptanshu Singh discussing whether IS-IS flooding in highly meshed fabric is as much of a problem as some people would like to make it. I won’t spoil the fun, read his blog post ;)

The really interesting part (for me) was the topology he built with netsim-tools and containerlab: seven leaf-and-spine fabrics connected with WAN links and superspines for a total of 68 instances of Arista cEOS. I hope he automated building the topology file (I’m a bit sorry we haven’t implemented composite topologies yet); after that all he had to do was to execute netlab up to get a fully-configured lab running IS-IS.

Here’s a short list of major goodies included in netsim-tools release 1.2.2:

• Access VLANs, VLAN trunks and native VLANs implemented on Cisco IOS, Arista EOS, VyOS, and Dell OS10 (VyOS and OS10 support contributed by Stefano Sasso)
• Hardware labs implemented with external topology provider (contributed by Stefano Sasso)
• VRF loopback interfaces (contributed by Stefano Sasso)

More details in the release notes.

To upgrade netsim-tools, use pip3 install --upgrade netsim-tools; if you’re starting from scratch, read the installation instructions.

netsim-tools started as a simple tool to create virtual lab topologies (I hated creating Vagrantfiles describing complex topologies), but when it morphed into an ever-growing “configure all the boring stuff in your lab from a high-level description” thingie, it gave creative networking engineers an interesting idea: could we use this tool to do all the stuff we always hated doing in our physical labs?

My answer was always “of course, please feel free to submit a PR”, and Stefano Sasso did just that: he implemented external orchestration provider that allows you to use netsim-tools to configure IPv4, IPv6, VLANs, VRFs, LLDP, BFD, OSPFv2, OSPFv3, EIGRP, IS-IS, BGP, MPLS, BGP-LU, L3VPN (VPNv4 + VPNv6), SR-MPLS, or SRv6 on supported hardware devices.

In the Building a BGP Anycast Lab I described how you could use custom configuration templates to extend the functionality of netsim-tools.

That example used Cisco IOS… but what if you want to test the same functionality on multiple platforms? netsim-tools provides a nice trick: the custom configuration template could point to a directory with platform-specific templates. Let me show you how that works…

I already mentioned the netsim-tools Easter Egg, here are the other cool features shipping in release 1.2.1:

• Dell OS10 on libvirt (including BGP, OSPFv2, OSPFv3 and VRF Lite) by Stefano Sasso
• VRFs, MPLS, and MPLS/VPN support on Mikrotik RouterOS and VyOS by Stefano Sasso
• Containerlab support for Cumulus 5.0 with NVUE including Simple VRF-Lite by Julien Dhaille

To upgrade netsim-tools, use pip3 install --upgrade netsim-tools; if you’re starting from scratch, read the installation instructions.

A friend of mine sent me the following question a few months ago:

I thought you might know the best way (currently) to create a digital clone of parts of a production network? The objective is to test changes against a test network as part of a CI/CD process. Ideally, there would be an automation that could replicate selected parts of a production network in a test network.

TL&DR: Sounds great, but you might be solving the wrong problem.