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.

Here’s a short breakdown of MELT, which stands for metrics, events, logs, and traces. These are the four most basic data types used for network and system telemetry. There are other data types that are widely used and very useful in a robust observability solution, though I would argue some are just another form of one of these general data types.

These data types are used in system monitoring in general, but are very valuable in observability. Metrics, events, logs, and traces have most commonly been the cornerstone of application and system observability, but today they also form key components of the telelemtry used for network observability.