Ivan Pepelnjak

Author Archives: Ivan Pepelnjak

Arista EOS Spooky Action at a Distance

This blog post describes yet another bizarre behavior discovered during the netlab integration testing.

It started innocently enough: I was working on the VRRP integration test and wanted to use Arista EOS as the second (probe) device in the VRRP cluster because it produces nice JSON-formatted results that are easy to use in validation tests.

Everything looked great until I ran the test on all platforms on which netlab configures VRRP, and all of them passed apart from Arista EOS (that was before we figured out how Sturgeon’s Law applies to VRRPv3) – a “That’s funny” moment that was directly responsible for me wasting a few hours chasing white rabbits down this trail.

The Linux Bridge MTU Hell

It all started with an innocuous article describing the MTU basics. As the real purpose of the MTU is to prevent packet drops due to fixed-size receiver buffers, and I waste spend most of my time in virtual labs, I wanted to check how various virtual network devices react to incoming oversized packets.

As the first step, I created a simple netlab topology in which a single link had a slightly larger than usual MTU… and then all hell broke loose.

Worth Reading: Traffic Steering into LSPs

You can use SR-MPLS, MPLS-TE, or an SDN controller to build virtual circuits (label-switched paths) across the network core. The controller can push the LSPs into network devices with PCEP, BGP-LU, or some sort of NETCONF/RESTCONF trickery.

Unfortunately, you’re only half done once you have installed the LSPs. You still have to persuade the network devices to use them. Welcome to the confusing world of traffic steering explored in the Loopback as a Service blog post by Dmytro Shypovalov.

Capturing Traffic in Virtual Networking Labs

When I announced the Stub Networks in Virtual Labs blog post on LinkedIn, I claimed it was the last chapter in the “links in virtual labs” saga. I was wrong; here comes the fourth part of the virtual links trilogy – capturing “on the wire” traffic in virtual networking labs.

While network devices provide traffic capture capabilities (usually tcpdump in disguise generating a .pcap file), it’s often better to capture the traffic outside of the device to see what the root cause of the problems you’re experiencing might be.

Stub Networks in Virtual Labs

The previous blog posts described how virtualization products create LAN segments and point-to-point links.

However, sometimes we need stub segments – segments connected to a single router or switch – because we don’t want to waste resources creating hosts attached to a network device, but would still prefer a more realistic mechanism than static routes to inject IP subnets into routing protocols.

Worth Reading: Network Traffic Telemetry Protocols

Pavel Odintsov published a series of introductory blog posts describing protocols we can use to collect network traffic telemetry:

  • Part 1 covers the ancient Netflow v5, Netflow v9, and IPFIX. It also mentions sampling and flow aggregation.
  • Part 2 describes sFlow, port mirroring and sampled mirroring, and the use of IPFIX/Netflow v9 to transport mirrored traffic.

These blog posts will not make you an expert but will give you an excellent overview of the telemetry landscape1.


  1. Hint: more than enough to turn you into an instant AI-assisted LinkedIn garbage generator Thought Leader™ 😜 ↩︎

Run BGP Across a Firewall

When I asked my readers what they would consider a good use case for EBGP multihop (thanks again to everyone who answered!), many suggested running BGP across a layer-3 firewall (Running BGP across a “transparent” (bump-in-the-wire) firewall is trivial). I turned that suggestion into a lab exercise in which you have to establish an EBGP multihop session across a “firewall” simulated by a Linux host.

If you haven’t set up your own lab infrastructure, click here to start the lab in your browser using GitHub Codespaces. After starting your codespace, change the directory to basic/e-ebgp-multihop and execute netlab up.

Goodbye, Cumulus Community Vagrant Boxes

Last Monday, I decided to review and merge the “VXLAN on Cumulus Linux 5.x with NVUE” pull request. I usually run integration tests on the modified code to catch any remaining gremlins, but this time, all the integration tests started failing during the VM creation phase. I was completely weirded out, considering everything worked a week ago.

Fortunately, Vagrant debugging is pretty good1 and I was quickly able to pinpoint the issue (full printout):

BalticNOG Meeting (September 2025)

Donatas Abraitis asked me to spread the word about the first ever Baltic NOG meeting in the second half of September 2025 (more details)

If you were looking for a nice excuse to visit that part of Europe (it’s been on my wish list for a very long time), this might be a perfect opportunity to do it 😎.

On a tangential topic of fascinating destinations 😉, there’s also ITNOG in Bologna (May 19th-20th, 2025), Autocon in Prague (May 26th-30th, 2025), and SWINOG in Bern (late June 2025).

Projects to Work On – the AI Recommendations

Vini Motta decided to use AI on ipSpace.net content to find what it would recommend as the projects to work on in order to become employable in 2025. Here are the results he sent me; my comments are inline on a gray background.

Network Automation with Python
Project: Automate basic network tasks like device configuration, backup, or monitoring using Python scripts.