Here’s an interesting tidbit from the what took them so long department: Cloudflare One Client continuously measures end-to-end MTU and adjusts the local tunnel interface MTU size accordingly (warning: there’s a fair amount of dubious handwaving over the interesting details), generating ICMP packet-too-big messages as close to the source as possible.

I managed to avoid VPN clients most of my life, so I have no idea whether this is a “finally someone figured that out 🎉” moment or a late catch-up to what other VPN clients have been doing for ages. Feedback (in comments or otherwise) would be most welcome!

netlab release 26.03 is out. Here are the highlights:

• New Cisco IOS XR features: SR-MPLS, MPLS/VPN, MPLS 6PE, EVPN over MPLS, VRRP, BGP session parameters, routing policies, prefix filters, AS-path filters, community filters, and static routes
• Juniper cRPD support (mostly by @leec-666)
• EVPN/VXLAN on Juniper vPTX and vJunos-router by @rickycraft
• OpenBSD BGP support by @remilocherer
• SR-MPLS support for OSPFv2 on EOS, FRR, IOS XE, IOS XR
• EVPN/MPLS improvements, including using SR-MPLS transport

For even more details, check the release notes.

We haven’t implemented support for Cisco SD-WAN in netlab yet, and we might never do so; after all, netlab isn’t meant to be a kitchen sink of vendor-specific features. However, having an open-source tool that uses input and output files with standardized encoding (JSON or YAML) makes it easy to develop an independent solution that adds functionality.

That’s exactly what Sebastien d’Argoeuves did: he developed a solution that automates Cisco SD-WAN deployment after the corresponding netlab lab is started, and published it in a GitHub repo. If you’re an SD-WAN fan, you must give it a try ;)

Yesterday, I had a short presentation on netlab use cases during the NetBCN event. It covered a dozen examples, from rapid prototyping to testing network automation software and arguing with vendor TAC. I added the “use cases” part of the presentation to the standard netlab presentation; you can view the results on ipSpace.net (no account or registration required).

I decided it was high time to create EVPN/MPLS netlab integration tests and wanted to use the same approach I used for the EVPN/VXLAN ones:

• One of the PE-devices is the device we want to test
• The other PE-device is a device that is known to work (ideally, an FRRouting container).
• Bonus points if the other PE-device can generate operational data in JSON format. Using a device for which we already have a validation plugin is close to perfection.
• Add a P-router in the middle because MPLS.
• Attach some hosts to the two PE-devices (we’re testing two MAC-VRFs in the final version of the test)
• After validating everything that can reasonably be validated (OSPF session, IBGP session, EVPN AF on IBGP session), do the end-to-end pings and hope for the best.

This is the graph netlab created from the lab topology:

Bruce Davie published a nice article explaining why it makes little sense to use an algorithm that’s supposedly faster than Dijkstra’s in link-state routing protocols.

Other interesting data points from the article (and linked presentations):

• People are running (a few) thousands of routers in a single area
• Running Dijkstra’s algorithm on an emulated network with 2000 nodes took 100 msec… in 2003 (page 18 of this NANOG presentation).

It turns out (as I expected) that all the noise about the need for new routing protocols we were experiencing a few years ago was either due to bad implementations or coming from nerds looking for new toys to play with.

Someone recently asked me whether it’s possible to use netlab to build an MPLS/VPN (technically, BGP/MPLS IP VPN) lab with SR-MPLS core. Of course, let’s build a simple lab using Arista EOS and Linux containers to implement this topology:

Here’s the lab topology we’ll use (also available on GitHub):

In the first EVPN/VXLAN lab, we added the EVPN control plane to bridging over VXLAN. Now, let’s try out a more complex scenario: several EVPN MAC-VRFs mapped to different VLAN segments on individual PE-devices.

You can run the lab on your own netlab-enabled infrastructure (more details), but also within a free GitHub Codespace or even on your Apple-silicon Mac (installation, using Arista cEOS container, using VXLAN/EVPN labs).

Imagine you want to deploy a BGP route reflector for MPLS 6PE or L3VPN service. Both services run over MPLS LSPs, use IPv4 BGP sessions, and use IPv4 next hops for BGP routes. There’s absolutely no reason to need IPv6 routing on a node that handles solely the control-plane activity (it never appears as a BGP next hop anywhere), right? Cisco IOS disagrees, as I discovered when running route reflector integration tests for netlab 6PE and (MPLS) L3VPN functionality.

Most platforms failed those tests because we forgot to configure route-reflector-clients in labeled IPv6 and VPNv4/VPNv6 address families¹. That was easy to fix, but the IOS-based devices were still failing the tests, with nothing in the toolchain ever complaining about configuration problems.

I guess your LinkedIn feed is as full of AI nonsense as mine is, so I usually just skip all that posturing. However, every now and then, I stumble upon an idea that makes sense… until you start to dig deeper into it.

There was this post about AI agents speaking BGP with an associated GitHub repo, so I could go take a look at what it’s all about.

The proof-of-concept (so the post author) has two components: