Cisco Modeling Labs and Infrastructure-as-Code

Dalton Ortega, Cisco Modeling Labs Product Manager, sent me the following email as a response to my Configuring IP Addresses Won't Make You an Expert blog post:

First, your statement on Autonetkit is indeed correct. We had removed that from the product due to lack of popularity. That being said, in our roadmap we are looking at methods to reintroduce on-the-fly configuration as well as enhancing our sample labs library to make getting started with CML easier.

Secondly, CML can be run in full IaC mode because of the API-first build. In fact, many of our customers are using CML as an automated test/validation bed for their CI/CD pipelines. Tools like Ansible and Terraform are available to facilitate this inside CML too. For more details, read:

• Get Started With Terraform and Cisco Modeling Labs
• How to Use Ansible with CML

Worth Reading: Drunken Plagiarists

George V. Neville-Neil published a fantastic, must-read summary of the various code copilots’ usefulness on ACM Queue: The Drunken Plagiarists.

It pretty much mirrors my experience (plus, I got annoyed when the semi-relevant suggestions kept kicking me out of the flow) and reminds me of the early days of OpenFlow, when nobody wanted to listen to old grunts like myself telling the world it was all hype and little substance.

Cisco VRRPv3 IPv6 Configuration Sucks

I spent way too much time ironing out the VRRPv3 quirks on the dozen (or so) platforms supported by netlab. This is the second blog post describing some of the ridiculous stuff I had to deal with.

This is how you configure the basic VRRPv3 parameters for IPv4 on a Cisco IOS/XE device:

interface GigabitEthernet0/1
  vrrp 217 address-family ipv4
    address 172.16.33.42

You would expect something similar for IPv6, right? You’d be right if you were working with Arista EOS:

Use BGP Outbound Route Filters (ORF) for IP Prefixes

When a BGP router cannot fit the whole BGP table into its forwarding table (FIB), we often use inbound filters to limit the amount of information the device keeps in its BGP table. That’s usually a waste of resources:

• The BGP neighbor has to send information about all prefixes in its BGP table
• The device with an inbound filter wastes additional CPU cycles to drop many incoming updates.

Wouldn’t it be better for the device with an inbound filter to push that filter to its BGP neighbors?

Sturgeon’s Law, VRRPv3 Edition

I just wasted several days trying to figure out how to make the dozen (or so) platforms for which we implemented VRRPv3 in netlab work together. This is the first in a series of blog posts describing the ridiculous stuff we discovered during that journey

The idea was pretty simple:

• Create a lab with the tested device and a well-known probe connected to the same subnet.
• Disable VRRP (or interface) on the probe and check IPv4 and IPv6 connectivity through the tested device (verifying it takes over ownership of VRRP MAC and IP addresses).
• Reenable VRRP on the probe and change its VRRP priority several times to check the state transitions through INIT/BACKUP(lower priority)/MASTER(change in priority)/BACKUP(preempting after a change in priority).

The Ethernet/802.1 Protocol Stack

The believers in the There Be Four Layers religion think everything below IP is just a blob of stuff dealing with physical things:

People steeped in a slightly more nuanced view of the world in which IP is not the centerpiece of the universe might tell you that the blob of stuff we need is two things:

IBGP Is the Better EBGP

Whenever I was explaining how one could build EBGP-only data center fabrics, someone would inevitably ask, “But could you do that with IBGP?”

TL&DR: Of course, but that does not mean you should.

Anyway, leaving behind the land of sane designs, let’s trot down the rabbit trail of IBGP-only networks.

Concise Link Descriptions in netlab Topologies (Part 1)

One of the goals we’re always trying to achieve when developing netlab features is to make the lab topologies as concise as possible¹. Among other things, netlab supports numerous ways of describing links between lab devices, allowing you to be as succinct as possible.

A bit of a background first:

• In the end, netlab collects all links in the links list before starting the data transformation process.
• Every entry in the links list is a dictionary. That dictionary can contain link attributes and must contain a list of interfaces connected to the link.
• Every interface must have a node (specifying the lab device it belongs to) and could contain additional interface attributes.

Public Videos: Leaf-and-Spine Fabric Design

The initial videos of the Leaf-and-Spine Fabric Architectures webinar are now public. You can watch the Leaf-and-Spine Fabric Basics, Physical Fabric Design, and Layer-3 Fabrics sections without an ipSpace.net account.

Lab: Level-1 and Level-2 IS-IS Routing

One of the recipes for easy IS-IS deployments claims that you should use only level-2 routing (although most vendors enable level-1 and level-2 routing by default).

What does that mean, and why does it matter? You’ll find the answers in the Optimize Simple IS-IS Deployments lab exercise.

Comparing IGP and BGP Data Center Convergence

A Thought Leader¹ recently published a LinkedIn article comparing IGP and BGP convergence in data center fabrics². In it, they³ claimed that:

iBGP designs would require route reflectors and additional processing, which could result in slightly slower convergence.

Let’s see whether that claim makes any sense.

TL&DR: No. If you’re building a simple leaf-and-spine fabric, the choice of the routing protocol does not matter (but you already knew that if you read this blog).

Weird Junos IS-IS Metrics

As part of the netlab development process, I run almost 200 integration tests on more than 20 platforms (over a dozen operating systems), and the amount of weirdness I discover is unbelievable.

Today’s special: Junos is failing the IS-IS metrics test.

The test is trivial:

• The device under test is connected to two IS-IS routers (X1 and X2)
• It has a low metric configured on the link with X1 and a high metric configured on the link with X2

The validation process is equally trivial:

netlab: Multi-Site VLANs

Imagine you want to create a simple multi-site network with netlab:

• The lab should have two sites (A and B).
• Each site has a layer-3 switch, a single VLAN (VLAN 100), and two hosts connected to that VLAN.
• As you don’t believe in the magic powers of stretched VLANs, you have a layer-3 (IPv4) link between sites.

New IPv6 Documentation Prefix

After three and a half years of haggling (the IETF draft that became the RFC was written in May 2021; the original discussions go back to 2013), Nick Buraglio & co managed to persuade pontificators bikeshedding in the v6ops working group that we might need an IPv6 documentation prefix larger than the existing 2001:db8::/32.

With the new documentation prefix (3fff::/20) (defined in RFC 9637), there’s absolutely no excuse to use public IPv6 address space in examples anymore.

netlab 1.9.3: MLAG, Static Routes, Node Cloning

netlab release 1.9.3 brings these new features:

• Multi-chassis Link Aggregation (MLAG) on Arista EOS, Aruba CX, Cumulus NVUE, and Dell OS10
• VRF and VLAN groups
• Additional OSPF interface parameters (hello and dead timers, cleartext passwords, and DR priority) implemented on Arista EOS, Aruba CX, Cisco IOS/IOS-XE, Cisco Nexus OS, Cumulus Linux, Dell OS10, and FRRouting
• Static routes with direct or indirect next hops implemented on Arista EOS, Cisco IOS/IOS-XE, FRRouting, and Linux
• Node cloning plugin for users who want to build detailed digital twins of their networks.
• Consistent selection of default address pools based on the number of nodes attached to a link (this could change addressing in multi-provider topologies)
• Support for vjunos-router and Cisco NSO tool.

Other new features include:

Configuring IP Addresses Won’t Make You an Expert

A friend of mine recently wrote a nice post explaining how netlab helped him set up a large network topology in a reasonably short timeframe. As expected, his post attracted a wide variety of comments, from “netlab is a gamechanger” (thank you 😎) to “I prefer traditional labs.” Instead of writing a bunch of replies into a walled-garden ecosystem, I decided to address some of those concerns in a public place.

Let’s start with:

OSPFv3 on Bird Needs IPv6 LLA on the Loopback Interface

Wanted to share this “too weird to believe” SNAFU I found when running integration tests with the Bird routing daemon. It’s irrelevant unless you want Bird to advertise the IPv6 prefix configured on the main loopback interface (lo) with OSPFv3.

Late last year, I decided to run netlab integration tests with the Bird routing daemon. It passed most baseline netlab OSPFv3 integration tests but failed those that checked the loopback IPv6 prefix advertised by the tested device (test results).

Happy Holidays and All the Best in 2025!

Another year is almost gone, and it’s time for my traditional “I will disappear until mid-January” retreat (also, don’t expect me to read my email until I’m back).

I hope you’ll also be able to disconnect from the crazy pace of the networking world, forget the “AI will make networking engineers obsolete” shenanigans (hint: SDN did not), and focus on your loved ones. I would also like to wish you all the best in 2025!

I will probably get bored sometime in late December, so expect a few new netlab features in early January.

Worth Reading: Hard Truths about AI-assisted Coding

Addy Osmani published an excellent overview of the challenges of AI-assisted coding. They apply equally well to the “AI will generate device configurations for me” or “AI will troubleshoot my network” ideas (ignoring for the moment the impact of the orders-of-magnitude smaller training set), so it’s definitely worth reading.

I particularly liked the “‌AI is like having a very eager junior developer on your team” take, as well as the description of the “70% problem” (AI will get you 70% there, but the last 30% will be frustrating) – a phenomenon perfectly illustrated by the following diagram by Forrest Brazeal:

Use Disaggregated BGP Prefixes to Influence Inbound Internet Traffic

As much as I love explaining how to use BGP in an optimal way, sometimes we have to do what we know is bad to get the job done. For example, if you have to deal with clueless ISPs who cannot figure out how to use BGP communities, you might be forced to use the Big Hammer of disaggregated prefixes. You can practice how that works in the next BGP lab exercise.

Click here to start the lab in your browser using GitHub Codespaces (or set up your own lab infrastructure). After starting the lab environment, change the directory to policy/b-disaggregate and execute netlab up.