In the previous blog post, I described how ARP works in an EVPN asymmetric IRB environment where the PE devices share an anycast MAC/IP address in addition to a unicast MAC/IP address. Today, let’s see how well things work if the PE devices have only the anycast MAC/IP address:

Claudia de Luna published a step-by-step description of how you can use SuzieQ data with an AI agent.

That’s definitely interesting, but I found the list of MCP resources at the end of her blog post even more valuable; that’s a keeper even if you never looked at SuzieQ (in which case you REALLY SHOULD).

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.

Ali Bahadır Coşkun wrote a nice article describing how he mastered extending a VLAN with static VXLAN with the help of free netlab-powered VXLAN labs.

The same set of lab exercises includes six VXLAN labs, almost a dozen EVPN labs, and a few EVPN designs. I might add a lab or two during the summer break.

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.

Chris Grundemann wrote an interesting article arguing that you should structure your network operations around teams, not heroes.

Even if you feel you’re perfectly OK with your network being held together by exhausted heroes (and duct tape), it could be a bit harder to deploy network automation in an always-busy hero culture. However, the choice, as they say, is yours.

I started my part of the Segment Routing workshop @ ITNOG10 exploring SR-MPLS with IS-IS (simple SR-MPLS, dual-stack SR-MPLS, SR-MPLS over unnumbered IPv4 interfaces). Next step: let’s change the routing protocol to OSPF while using the same network topology:

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.

Leo Fleskes sent me an interesting question after reading my Generate Partial Device Configurations with netlab blog post:

What is stopping us from eventually, given enough usage and coverage, using netlab to configure devices in the live network?

In theory, nothing. In practice, you might hit a few hurdles:

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.