ipSpace.net blog

Author Archives: ipSpace.net blog

Configuring Management IP Addresses to Virtual Network Devices

It goes without saying that if you want to configure (virtual) network devices with any semi-sane configuration mechanism1, the device must have a working IP address. Here’s the time-honored method2 to assign an IP address to a virtual network device:

  • Start the virtual machine (using a GUI)3
  • Open a new window: either a telnet session to the virtual console port or a full-blown virtual console (GUI) session.
  • Manually configure the IP address, the SSH server, and the user credentials on the first interface.

Worth Reading: NatJack

Every time I wrote something along the lines of NAT is not a security feature, I got the expected pushback from people defending their bad suboptimal design choices.

Fortunately, rational1 engineers no longer need to have that discussion: the NatJack website documents2 a half-dozen attacks on typical NAT implementations.

Obvious next step: coping mechanisms like “this is all theoretical”, like the “but the remote host cannot reply” argument made 23 years after the Slammer worm 🤦‍♂️.

Please Help Me Follow Your Content

Finding good content in the swamp of AI slop is hard, and whenever I find a blog post worth reading, I’d like to know when the author publishes the next one.

For stupid reasons (like a day having only 24 hours, and me having a life), I can’t periodically scan all websites I find interesting, but fortunately, I don’t have to. Two well-known mechanisms work reliably: email updates and RSS feeds.

BGP-Free Core with SR-MPLS

The beauty of SR-MPLS is that it’s a drop-in replacement for the traditional (LDP- or RSVP-based) MPLS control plane. For example, you could replace LDP with SR-MPLS in a network using MPLS to implement a BGP-free transport core, and it just keeps working.

This scenario was the first “fun” scenario in the ITNOG10 Segment Routing workshop. The core network uses the same topology as in the previous examples; I added two hosts and BGP routing.

Simplest possible network using a BGP-free core

Simplest possible network using a BGP-free core

Networking Aspects of Running VMs in Containers

The vrnetlab project and its containerlab fork implement a wonderful idea: let’s package virtual machines (primarily network devices that cannot be containerized) as containers to use reliable orchestration tools like containerlab to provision network topologies.

That approach might have a few drawbacks (depending on how the container images are built), but the obvious elephant in the room is: how do you make the virtual network plumbing work?

MUST READ: Git – Going Pro

I sure wish Tony Mattke had started publishing his Git-related blog posts in 2017 when I was still struggling with the basics. In his latest Going Pro article he covers:

  • Using SSH keys with Git and GitHub
  • Pre-commit hooks
  • GitHub Actions and linting
  • GitHub Branch protection
  • PR reviews
  • gh CLI

Absolutely worth every second you’ll spend reading the article!

Using netlab in Software Testing with Dinesh Dutt

I know a few software development companies use netlab to test their network management software (and contribute back to netlab – thanks a million!), and I always wanted to chat about that. As I have known Dinesh Dutt for ages, it wasn’t hard to decide who to invite to have that chat with ;)

As it turns out, it’s dangerous to put Dinesh1 and me in the same (virtual) room – we were all over the place, from the ancient history of Vagrant in networking labs to the recent Ansible woes, but we did manage to cover how netlab helps Stardust Systems test new SuzieQ features.

Yak-Shaving netlab Podman Support

Long, long time ago, in a long-forgotten PR adding support for Cumulus VX Ignite runtime, an off-the-cuff remark was made saying, “and this is how you use netlab with Podman”. That remark was quietly sitting in the documentation for years until someone (A) tried to use Podman and (B) found enough time to report that it doesn’t work with netlab.

I don’t know what that tells us: either very few people use Podman, or nobody (apart from a notable exception) cares enough to spend a few minutes telling us stuff doesn’t work1.

Anyway, based on Joey Buiteweg’s wonderful research, I was able to put together a working solution pretty quickly, but it did involve a lot of yak shaving (more bovine details).

Dear Junos, Tunnels Are Not Virtual Links

In late June, we added GRE tunnels to netlab, including a Junos implementation. It looked great (as in “everything worked”) until I changed the integration tests to have GRE tunnels between a tested device and a pair of FRR containers. All other implementations worked as before, but Junos failed to establish an OSPFv3 adjacency over the GRE tunnel with FRR.

Stefano Sasso quickly identified the culprit: Junos OSPFv3 process thinks it should send the DBD packets over GRE tunnels with MTU set to zero (the behavior reserved for virtual links)1.

Arista cEOS Does Not Apply ACLs to Control-Plane Traffic

When someone starts singing the Use Digital Twins to Test Your Network hymn (or, more recently, tells you how AI agents can do that to validate their ideas), ask them about these minor details. If they persist, point them (not that it would help) to this long list of gotchas.

That list just got longer: Arista cEOS container does not apply inbound ACLs to control-plane traffic (Arista vEOS VM does).

Worth Reading: On AI Coding and Its Discontents

A lot of AI-coding enthusiasts are making claims along the lines of “AI coding tools are like compilers; you supply intent, they translate it into code, and who ever looked at the machine-code output?” Unfortunately, there is a bit of a gap between hope and reality; traditional compilers were always deterministic, and are (after decades of development and bug-fixing) pretty much bug-free. AI coding tools are neither, and no amount of “agentic loops” will solve that.

Exploring the BGP Neighbor CONNECT State

Sakar left an interesting comment on my The Curious Case of the BGP Connect State blog post, claiming that Cisco IOS/XE goes through a CONNECT state when opening an incoming BGP session.

I wanted to double-check this behavior, so I needed a scenario where one router would keep sending TCP SYN requests, the other would not (or we wouldn’t learn anything), and the two routers could not communicate (or they’d quickly go into the OPEN state).

Here’s my first attempt at meeting those requirements:

The Never-Ending IPv6 Loopback Prefix Saga

Remember the sage advice to simplify your life and use the IPv6 /64 prefixes everywhere? Not only does it make your life simpler (and wastes immesuarably less address space than the crazy “let’s assign /64 to every device” stupidity), it also reduces the hardware requirements in your high-speed routers layer-3 switches. You see, doing lookups on 64 bits uses half the silicon it takes to do lookups on 128 bits.

Alas, some people never got the memo. OSPFv3 standard clearly states in one of the bullets in section 4.4.3.9 that the loopback prefixes should always be advertised as /128s regardless of what’s configured on the interface.

Compress netlab Lab Topologies with Dot Notation

netlab is using the Python Box library to make the code easier to read1. When I started the project, I hated the way you fetch values from Python dictionaries with stuff like node['ospf']['area']; Python Box lets you write node.ospf.area. Even better2, you can tell Python Box to create intermediate dictionaries as needed. node.ospf.area = 1 will automatically create the node.ospf dictionary.

But wait, there’s more (yes, we’re getting to the topic of today’s blog post): Box lets you use the same dotted notation in YAML files.

On ACLs and AI-Generated Device Configurations

Last Friday, I had a lovely chat with Steinn Bjarnarson and Urs Baumann, resulting in the NetworkAutoMagic episode 11. We couldn’t avoid mentioning netlab, the seven layers of ACL hell (which is still balmy compared to the QoS hell), and the gotchas of AI-generated device configurations.

Fortunately, I don’t have to go into more details; Steinn published extensive notes, and if you don’t feel like listening to us while driving, you can waste time watching us on YouTube.