Recently I was honored to give the keynote presentation at a couple of USNUA's Network User Group events, in Kentucky and Indiana, and I gave a talk titled "8 Networking Hot Takes." I'd like to share one of those here, the last and most controversial, "Never use VLAN trunking between switches and routers on your network." The follow-up statement was, "Use EVPN with VXLAN instead."
Now, please understand that I stated these hot takes in intentionally provocative and overly absolute terms as a method to increase the discussion during and after the presentation. I don't believe this should be an absolute rule you should follow in building your network today without exception. There can be real-world constraints that prevent this, but I argue here that EVPN/VXLAN should be the fundamental building block for network virtualization and network services delivery on modern networks instead of 802.1Q VLAN trunking.
This blog has hosted content about EVPN/VXLAN before, most recently in a post by Max Urmanov, titled “EVPN/VXLAN Network Health Verification: A Comprehensive Guide”, in March about techniques to health check your EVPN/VXLAN network. In the first part of his blog post he states that EVPN/VXLAN is a "technology that addresses many traditional data center networking challenges." And he's not wrong, at all. I think, however, that characterization undersells EVPN/VXLAN and we, as the networking world, should be using EVPN/VXLAN beyond the data center.
My contention in my hot take above is that EVPN/VXLAN is the first set of technologies to give us comprehensive network virtualization capabilities without crippling complexity or fragility in an open standard manner that avoids vendor lock-in. Consequently, it's time to retire VLAN trunking as the predominant network virtualization technology.
It's common to see EVPN/VXLAN positioned as a data center technology, as Urmanov did in March, and EVPN/VXLAN has been an absolute game changer in the data center. But we should be looking at segments beyond the data center for EVPN/VXLAN deployment as well. It is possible to find documentation about using EVPN/VXLAN in the campus, and even WAN, but a shocking number of them notionally advocate for essentially turning your campus into a leaf and spine setup, and then deploying EVPN/VXLAN on that.
EVPN/VXLAN is much more flexible than that. Indeed, it doesn't even strictly require that you configure it contiguously. Because it uses tunnels and BGP, both of which can function in a multi-hop world, you can start out by deploying it only where you need specific services to terminate, and slowly grow it into the rest of your network.
In my presentation, I described EVPN/VXLAN as providing two layers of networking, Infrastructure and Services. Yes, these are different words to describe underlay and overlay, but it emphasizes how this can be used beyond the data center.
The Infrastructure is the network you can touch, and I mean that literally. It's the cables, and devices, and the topology of that network follows the topology of where you have cables and locations to put devices. In the data center, you essentially have no constraints, so you can build whatever topology that you want, and a leaf and spine Clos topology has shown its worth.
Beyond the data center, however, you are frequently constrained by where fiber builds have happened, where cable runs within a building exist, and other similar limitations. But EVPN/VXLAN can still function extremely well in these worlds. Combine it with BGP Unnumbered in the underlay and you can let your Infrastructure layer essentially self-assemble into whatever topology makes sense!
In a campus world, you may have fiber bundles following certain routes across campus, so build your Infrastructure to match! The WAN world is essentially the same, just amping up the pathing constraints to 11.
Once you have your Infrastructure layer built, then you can start providing Services. Services, in this model, are the overlays, they are the networking behaviors that your users - be they customers, tenants, business units, departments, functional teams, or whatever - need the network to provide to them.
The two predominant services here are Layer 2 transport and Layer 3 transport. Do you need to stretch VLAN's between different buildings on campus, or even to the next city over? You can do that with EVPN/VXLAN while still maintaining a good, scalable, efficient, and reliable Infrastructure. Please, though, let's not abuse this and use it more than is really needed. Stretching Layer 2 is inherently problematic, EVPN/VXLAN just makes it suck less.
For Layer 3 Service, we're talking about VRFs here. EVPN/VXLAN lets you extend safe and efficient Layer 3 routing between locations without having to graft it on top of 802.1q tagged links while still retaining tenant separation.
The other common service that EVPN/VXLAN can provide, and do it better than the pre-existing technology, is MLAG. EVPN multi-homing is more scalable than multi-chassis LAG because it can use more than two switches in a distributed LAG, and doesn't require proprietary peer-links between participating switches. It still provides the illusion to downstream connectivity of being connected to a single switch running LACP in the same way MLAG does. It can also support single-active with standby connections, or all-active.
By separating Services from Infrastructure, including in the campus, WAN, and other worlds of networking beyond the data center, you can configure your Service only on the endpoints - PEs - that need them, without needing to touch every single device in between.
The first challenge is just one of perception. Just as Urmanov described EVPN/VXLAN as solving data center challenges back in March, and again, he's not wrong, much of the literature that you find from vendors, blog posts, and in various fora, positions EVPN/VXLAN as a data center technology, not acknowledging its incredible usefulness beyond.
The second is the technology availability. EVPN/VXLAN is, relatively speaking, new on the block of networking technologies, and it has taken some time for support for it to find its way into vendor hardware. This manifests in two aspects. First, vendors locking EVPN/VXLAN functionality behind "premium" licenses, rather than treating the protocols as the table-stakes that they are quickly becoming. The second aspect is hardware support. It has taken some time - though remarkably little in the overall scheme of things - for network hardware to be developed with the capability of forwarding EVPN/VXLAN traffic in its various use cases, and even once networking forwarding ASICs are released with the capabilities, vendors still need to develop new switch versions to support it. Fortunately, this process is happening at a rapid pace.
Lastly, I think the biggest challenge is education. EVPN is an extension of BGP, and many networkers think they only need to know just enough about BGP to be able to connect to multiple upstream transit providers. BGP, particularly when used beyond just connecting to transit providers, does have a learning curve, but the value you get from climbing that curve is worth it, even without EVPN/VXLAN. But, once you have a good grounding in general BGP usage, EVPN is a relatively easy step beyond and even greater possibilities open up to you.
Join me, won't you? In a world where networking is scalable, reliable, responsive, cost-effective, and ultimately simpler. EVPN/VXLAN is a game changer, and not just in the data center.