One of the most interesting capabilities introduced by EVPN is native active-active multihoming. If you’ve spent time designing data center networks over the last decade, you’ve most likely used or at least encountered technologies like vPC, MLAG, MC-LAG, Virtual Chassis, StackWise Virtual, or other similar vendor-specific ways to dual-home servers and access switches.

These technologies solved a real problem. We wanted to connect a device to multiple switches simultaneously while still allowing all available links to forward traffic. Traditional Layer 2 protocols such as STP prevented loops, but they also left redundant links sitting idle which is a big waste of resources. 

The challenge is that most MLAG implementations are proprietary. They use special peer links and synchronization mechanisms, and usually that means you’ll be locked into a particular vendor architecture.

EVPN Active-Active Multihoming (EVPN-MH) takes a different approach. Instead of relying on proprietary control planes between switches, EVPN uses BGP EVPN itself to advertise multihoming information throughout the fabric. The result is a standards-based solution that provides redundancy, load balancing, faster convergence, and better scalability for modern VXLAN fabrics.

Many modern enterprise and cloud data center networks have standardized on a combination of BGP, EVPN, and VXLAN to build scalable Layer 2 and Layer 3 fabrics. Whether the environment is only a few dozen switches or thousands of leaf and spine devices, EVPN has become the preferred control plane for distributing endpoint reachability information across the fabric.

An important concept to understand when first learning EVPN are the route types used within the EVPN address family. Unlike traditional BGP, which primarily exchanges IP prefixes, EVPN distributes a variety of information. Each route type serves a specific purpose and helps the fabric build a complete picture of where endpoints, gateways, and services exist.

For decades, network architects designed data center networks primarily around application and storage traffic. Whether supporting enterprise applications, web services, virtualization platforms, or cloud-native workloads, the network was the transport mechanism connecting users, applications, and data.

Traffic patterns were characterized by north-south communication flows, predictable east-west application exchanges, and a relatively loose coupling between compute and network performance. High-performance computing environments differed somewhat by emphasizing ultra-high bandwidth, low latency, and efficient inter-node communication for distributed workloads. However, modern AI infrastructure introduces a fundamentally different model.

A good friend of mine is an electrical engineer for a well-known passenger train company in the United States, and we recently talked about how his job, his entire career, has taken a turn from traditional electrical engineering to computer systems integrations and building telemetry pipelines. In other words, as the industry progressed, he wasn’t replaced. Instead, his role evolved.

That probably isn’t a groundbreaking revelation considering almost every industry has been impacted by some form of digitization. Things change, and people adapt. However, what really intrigued me was the new initiative to use AI to augment the train management system.

Hey networking community!

To get you through another week of cutovers, pcaps, and folks blaming the network when it’s yet another DNS issue, I made this song parody just for you 🙂

It’s called Packets, based on one of the best songs to hit the airwaves in February 1996, and in my humblest of opinions, it’s the perfect soundtrack for your next 2am change window…

Enjoy!

(the lyrics are in the post for your viewing convenience)

You can split New York State into several regions, though the exact areas are often hotly debated depending on if you say soda, pop, or know all too well what time the last train leaves Penn Station. When Zig Zsiga and I started the New York Networking Users Group, the idea was to continue with the existing (NY)NUG which had one successful event in Manhattan. But after thinking about it, I thought it would be great to start multiple chapters around the state to accommodate all those crazy different accents (seriously – every region in New York State has a different accent and I love it).

And thus began a brand new chapter of the (US)NUA: the Upstate (NY)NUG.

In the context of BGP, a valley-free violation is when routing policy governing BGP path selection and advertisement breaks the valley-free policy. The valley-free routing policy basically ensures traffic doesn’t traverse unintended autonomous systems, usually a customer AS downstream from a service provider, and therefore an unintentional transit network.

I love the networking community, and I attribute much of my success as a network engineer, network architect, and now a technical marketer, to the interactions I’ve had with other network pros over the years. That’s meant interaction on Twitter, Reddit, the big conferences, and the small events like Tech Field Day. From those sprang up private Slack and Discord groups, the occasional iMessage or Google Hangouts group, and so on.

That changed significantly during the pandemic. Both the large and small conferences, meetups, and even company events stopped altogether and didn’t come back for a few years. And when they did, they were different. I noticed the large events weren’t as large (although I’m always shocked by how many people are at re:Invent), and the hybrid conference idea didn’t work for me. I missed the days of attending sessions, chatting with people over coffee in between keynotes, grabbing drinks in the evening with old nerd-friends, and getting to interact in person, engineer-to-engineer.

We needed a new networking community.