ipSpace.net blog

Author Archives: ipSpace.net blog

Worth Reading: AI Enthusiasts Against AI Skeptics

Charity Majors wrote an excellent article describing AI enthusiasts in a race against time and AI skeptics in a race against entropy. Fair warning: its very first sentence triggered an acute case of PTSD:

I recently attended a talk where one of the presenters made some pretty…astonishing claims about what they had achieved by the pure, uncut power of vibe coding.

I’ve seen way too many presentations making “astonishing claims” about the unlimited unicorn-driven powers of OpenFlow, SDN, OpenDaylight, or Ansible.

ARP with Anycast Gateways in EVPN Asymmetric IRB

In previous blog posts, I described the ARP issues in EVPN environments, starting with centralized routing, and then asymmetric IRB with unicast (per-leaf-switch) first-hop gateways. Of course, no self-respecting vendor would tell you to do that; anycast gateways are all the rage these days.

As always, anycast gateways could mean different things, depending on which vendor documentation you read ;)

  1. Active-active VRRP (one device is the active VRRP gateway, but all devices listen to the VRRP MAC address).
  2. Shared MAC+IP address beside device-specific unicast MAC and IP addresses.
  3. Shared MAC+IP address with no PE-specific IP address.

AI in Networking with Andrew Yourtchenko

I always wanted to find someone who is more positive about AI than I am, while having solid “can deliver working stuff at scale” credentials. Andrew Yourtchenko definitely fits the bill. I first met him (online) when he was still an engineer in Cisco TAC, and when we finally met in person, he was busy automating the deployment of Cisco Live networking infrastructure. He was also instrumental in bringing us closer to ubiquitous IPv6 deployment with Happy Eyeballs.

Goodbye, Leaf-and-Spine Networks?

A friend of mine sent me links to a new paper published by AWS engineers, and an associated LinkedIn post which claims:

We got lean, resilient, massive aggregation fabrics that provide 33% better throughput with 69% fewer routers, savings 27% of costs, cutting power usage by 40%, and reducing CO2 emissions.

The obvious question one should ask after reading the hyperventilated Radical Network Redesign blog post is thus: is this the end of leaf-and-spine networks? Of course not. Let’s go into the details.

Worth Reading: Genie Tarpit

Following a link in Martin Fowler’s Fragments, I stumbled upon Genie Tarpit by Kent Beck – a perfect summary of my experiences with AI coding (code reviews are OK, new code less so). He also provided a good reason for that behavior:

The “plausible deniability” task orientation of the genie leaves it claiming success even though the code doesn’t work at all.

And the proposed solution?

You probably saw this one coming—nobody knows.

netlab 26.06: OSPFv3 on FortiOS, MPLS/VPN on SR Linux

netlab release 26.06 adds OSPFv3 support on FortiOS (by @a-v-popov) and MPLS/VPN support on SR Linux. We also ensured the installation scripts work on Ubuntu 26.04 (everything else was OK) and updated the installed Vagrant version to 2.4.9 (we’re not using new Vagrant features; you don’t have to upgrade it in an existing installation).

Other than that, we added a few improvements and squashed a number of bugs.

Upgrading or Starting from Scratch?

Lab: Implementing VRF-Lite with VXLAN

Did you know that you can implement a VRF-Lite design with VXLAN? All you need are devices that can run VRF routing protocols over VXLAN-backed VLAN segments.

Compared to the “traditional” VRF-Lite design, in which you need a set of VLANs on every link and every device running the routing protocol for every VRF, the VXLAN-based design needs just IP routing on the core switches, resulting in a design that’s pretty close to what we were building with DMVPN (without IPsec and NHRP complications).

Using netlab to Argue with Vendor TAC

A happy netlab user sent me an unexpected use case: they successfully used its multi-vendor capabilities to argue with a vendor TAC. Here’s the gist of the story (edited/anonymized for obvious reasons):

They deployed a configuration change that resulted in an unexpected outage. The outage partially disrupted the data center network, so they didn’t have the luxury of collecting data and reproducing the issue, as they had to roll back the change as expeditiously as possible.

EVPN Centralized Routing with Arista EOS

A month ago, I described ARP issues in EVPN centralized routing design, and Naveen Kumar Devaraj was kind enough to add some Arista EOS implementation details. Today, let’s explore what EVPN routes Arista EOS generates in that scenario. We’ll use a very simple lab topology with a spine switch acting as a router. The leaf switches are layer-2 switches.

Packet forwarding in centralized routing design

Packet forwarding in centralized routing design

130 Years of Wireless Communications

Here’s a short glimpse into the history of telecommunications: in a building at the top of this mountain (barely noticeable blip across the saddle from the radio tower; search for Capo Figari for more details), Guglielmo Marconi conducted experiments in the ~1930s (after inventing the wireless telegraph system in the late 1890s).

The original radio could “transmit” at most 40-60 words per minute (the limit of a skilled Morse Code operator). 130 years later, I’m writing this blog post using a 200 Mbps Internet connection via a low-earth-orbit satellite with response times low enough that I can run an interactive SSH session with no noticeable delay. It’s almost incomprehensible how far we’ve come in such a short time.

Worth Reading: Ephemeral BGP Leaks

Doug Madory wrote an interesting article (published on APNIC blog) arguing that we shouldn’t worry about ephemeral BGP leaks that can be observed only during the BGP path hunting process that follows a route withdrawal.

I have to disagree with that. It’s never a good idea to ignore a dead canary in the coal mine.

While the ephemeral leaks do not impact the end result (after all, the route is gone), they are an important indicator of the lack of BGP route policy enforcement in the autonomous systems that propagate them. If an autonomous system is propagating a bogus route when no better routes are available, it’s equally likely to propagate a bogus route when an intruder manages to inject it.

1 2 3