Like OSPF, IS-IS needs a router to originate the pseudo-node for a LAN segment. IS-IS standards call that router a Designated Intermediate System (DIS), and since it is not responsible for flooding, it does not need a backup.

Want to know more? The Influence the Designated IS Election lab exercise provides the details (and some hands-on work).

If you’ve ever had to manage and configure more than a few routers in a production environment, there probably was a moment when you had to figure out what changes were made to a device configuration.

Answering that question seems to be an easy task; after all, device configurations are just text files:

• Periodically collect device configurations and store them somewhere (shared disk, database, or source code repository like Git)
• Whenever you have to figure out what changed, run a utility like diff to identify changes in text files.

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.

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.

Jeroen van Bemmel and Stefano Sasso contributed tons of new device features for the netlab release 1.9.5:

Cumulus Linux (NVUE):

• VXLAN and EVPN
• VLAN-aware router (VLAN subinterfaces) functionality
• VRF route leaking
• VRF-aware BGP and full RFC 8950 support (IPv4 BGP AF over regular IPv6 BGP session)
• BGP allowas_in and EBGP multihop

The previous blog post in this series discussed how TCP/IP and CLNP reach adjacent nodes and build ARP/ND/ES caches. Now let’s move one step further: how do nodes running IPv4/IPv6 or CLNP discover the first-hop router that could forward their traffic to off-subnet nodes they want to communicate with?

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.

When Ned Bellavance asked me to be a guest on the Chaos Lever podcast talking about NAT, I replied, “and why do you hate me so much?”

However, it turned out one can have a fun conversation about a controversial topic. For more details, listen to The Rise of NAT on Chaos Lever. I hope you’ll enjoy it ;)

I love good steamy rants, and The Generative AI Con from Edward Zitron is as good as they come. Pour yourself a glass of wine (or a cup of tea or whatever else you prefer) and have some fun ;)

Ole Troan, an excellent networking engineer working on IPv6 for decades, has decided to comment on the color of the IPv6 kettle, starting with:

• Is the transition to IPv6 inevitable? (hint: Betteridge’s law of headlines)
• The mistakes and missed opportunities in the design of IPv6 - episode 1 (aka Second System Effect¹)

I’m pretty sure Ole won’t stop there, so stay tuned.