In the previous blog post, I described how to build a lab to explore the layer-3-only EVPN design and asked you to do that and figure out what’s going on behind the scenes. If you didn’t find time for that, let’s do it together in this blog post. To keep it reasonably short, we’ll focus on the EVPN control plane and leave the exploration of the data-plane data structures for another blog post.

The most important thing to understand when analyzing a layer-3-only EVPN/VXLAN network is that the data plane looks like a VRF-lite design: each VRF uses a hidden VLAN (implemented with VXLAN) as the transport VLAN between the PE devices.

Wes made an interesting comment to the Migrating a Data Center Fabric to VXLAN blog post:

The benefit of VXLAN is mostly scalability, so if your enterprise network is not scaling… just don’t. The migration path from VLANs is to just keep using VLANs. The (vendor-driven) networking industry has a huge blind spot about this.

Paraphrasing the famous Dinesh Dutt’s Autocon1 remark: I couldn’t disagree with you more.

A few weeks ago, Roman Dodin mentioned layer-3-only EVPNs: a layer-3 VPN design with no stretched VLANs in which EVPN is used to transport VRF IP prefixes.

The reality is a bit muddier (in the VXLAN world) as we still need transit VLANs and router MAC addresses; the best way to explore what’s going on behind the scenes is to build a simple lab.

Darko Petrovic made an excellent remark on one of my LinkedIn posts:

The majority of the networks running now in the Enterprise are on traditional VLANs, and the migration paths are limited. Really limited. How will a business transition from traditional to whatever is next?

The only sane choice I found so far in the data center environment (and I know it has been embraced by many organizations facing that conundrum) is to build a parallel fabric (preferably when the organization is doing a server refresh) and connect the new fabric with the old one with a layer-3 link (in the ideal world) or an MLAG link bundle.

Vincent Bernat documented a quirk I hope you’ll never see outside of a CCIE lab: combining BGP confederations with AS-override can generate endless AS paths.

I agree entirely with his conclusions (avoid both features). However, I still think that replacing an AS within the confederation part of an AS path (which should belong to a single well-managed AS) is not exactly the most brilliant idea I’ve seen.

I never mastered the fine art of polite diplomatic sarcasm. Brad Casemore is a virtuoso – you’ll love his take on Google’s Quarterly Results: Investors Begin Questioning Efficacy of GenAI Investments.

Did you know you can use netlab to generate reports describing your lab topology, IP addressing, BGP details, or OSPF areas? The magic command (netlab report) was introduced in August 2023, followed by netlab show reports to display the available reports a few months later.

You can generate the reports in text, Markdown, or HTML format. The desired format is selected with the report name suffix. For example, the bgp-asn.md report will create Markdown text.

Let’s see how that works.

Daniel Dib asked an interesting question on LinkedIn when considering an RT5-only EVPN design:

I’m curious what EVPN provides if all you need is L3. For example, you could run pure L3 BGP fabric if you don’t need VRFs or a limited amount of them. If many VRFs are needed, there is MPLS/VPN, SR-MPLS, and SRv6.

I received a similar question numerous times in my previous life as a consultant. It’s usually caused by vendor marketing polluting PowerPoint slide decks with acronyms without explaining the fundamentals¹. Let’s fix that.

Dmytro Shypovalov wrote a fantastic article explaining the basics of MPLS-based Segment Routing. It’s pretty much equivalent to everything I ever wrote about SR-MPLS but in a much nicer package. Definitely a must-read.

Ben asked an interesting question:

Do you think, realistically in 2024, netlab would suffice to prepare the CCIE lab exam? Particulary for the SP flavor, since netlab supports a lot of routing protocols. Thanks!

TL&DR: No.

netlab would be a great tool to streamline your CCIE preparation studies. You could:

Here’s another AI rant to spice your summer: AI Is Still a Delusion, including an excellent example of how the latest LLMs flunk simple logical reasoning. I particularly liked this one-line summary:

The real danger today is not that computers are smarter than us but that we think computers are smarter than us and consequently trust them to make decisions they should not be trusted to make.

It might be worth remembering that quote when an AI-powered management appliance messes up your network because of a false positive ;)

The first BGP load balancing lab exercise described the basics of EBGP equal-cost load balancing. Now for the fun part: what if you want to spread traffic across multiple links in an unequal ratio? There’s a nerd knob for that: the BGP Link Bandwidth extended community that you can test-drive in this lab exercise.

In Matt Duggan’s blog post, you’ll find a scathing review of another attempt to throw AI spaghetti at the wall to see if they stick: the GitHub Copilot Workspace.

He also succinctly summarized everything I ever wanted to say about the idea of using AI tools to generate networking configurations:

Having a tool that makes stuff that looks right but ends up broken is worse than not having the tool at all.

Daniel Dib went on another deep dive: Why Do We Have Native VLANs? What I loved most was that he went through the whole 802.1 standard (quite an undertaking) and explained the reasoning that VLAN-aware switches behave the way they do.

You should also read the follow-up post: what happens if a VLAN-unaware switch receives an 802.1Q-tagged frame?

Brad Casemore published an interesting analysis explaining why Cisco should accept being a mature company with mature products (yeah, you have to subscribe to view it). I always loved reading his articles, but unfortunately, this time, he briefly ventured into the “I don’t think this word means what you think it means” territory:

MPLS worked – and it still works – but it provided optimal value in an earlier time when the center of gravity was not the cloud. The cloud challenged the efficacy of MPLS, and it wasn’t long before SD-WAN, cloud connects, and interconnects […] represented an implacable threat to a status quo that had once seemed unassailable.

The second part of the paragraph is (almost) true, but it had nothing to do with MPLS.