Many organizations are migrating away from traditional three-tier, spanning-tree datacenter and campus LANs to the newer EVPN-VXLAN architecture. This architecture is very flexible and allows for numerous implementation design options, however, the most common deployment is a leaf-spine, or Clos, design – so much so that leaf-spine EVPN-VXLAN LANs are the new de facto standard for datacenter and campus LANs alike.
There are many benefits to EVPN-VXLAN designs, including scalability, optimization for east-west traffic, virtual machine mobility, easier segmentation, simpler automation, all links are active, etc. (This article is not a tutorial on EVPN-VXLAN, but here is a link to a good overview.) Many of these benefits are related to the fact that EVPN-VXLAN is an overlay on top of a standard, generic, though typically Clos, Layer 3 underlay. Much like MPLS, the underlay and overlay networks are completely logically separate: What is under the hood, so to speak, is independent from the production traffic flowing over the top.
Therefore, since the overlay and underlay are separate, the network architect has many options on how to design and deploy the underlying fabric. With this being the case, why not use an IPv6-only “underlay” to carry your production traffic in the overlay, whether IPv6, IPv4 or dual stack? When EVPN-VXLAN first came out, this may not have been an option. But today, most leading network vendors support (possibly with some limitations) IPv6-only underlay EVPN-VXLAN fabrics.
First, some terminology
When discussing EVPN-VXLAN, it is common to hear the terms “overlay” and “underlay” tossed around. Before discussing the benefits of IPv6-only, first let’s get on the same page with respect to general terminology and what constitutes IPv6-only. My preferred view breaks EVPN and VXLAN into multiple parts.
The EVPN-VXLAN underlay is the underlying transport network. Underlay addressing is “infrastructure” addressing and consists of all fabric switch loopbacks and point-to-point interfaces. A routing protocol is used in the underlay to facilitate the reachability required by overlay protocols. (There are multiple options and combinations for the underlay and overlay routing protocols, e.g., OSPF(v3), iBGP, eBGP, etc., but protocol selection is outside of the scope of this blog.) In summary, the underlay is a base Layer 3 infrastructure.
The overlay can be split up into three distinct functional planes.
- 1) VXLAN – the overlay data plane
- 2) EVPN – the overlay control plane
- 3) Production Traffic – network applications for end-user/business use such as VLANs, VRFs, and routing protocols to fabric-external devices (firewalls, WAN, Internet, etc.)
When people say “underlay,” in my experience, they typically mean the underlay, as defined above, as well as parts 1) and 2) of the overlay. And the general term “overlay” typically refers to 3) above – production traffic to support applications and the overall business. If that’s still a bit confusing, perhaps another way to think of it is that the general term “overlay” is the production traffic and the EVPN-VXLAN “fabric” is everything else below. Got it?
Now, back to running IPv6-only in an EVPN-VXLAN fabric. This means the underlay/infrastructure is IPv6-only – with loopbacks, point-to-point links, and the routing protocol running for reachability. In addition, VXLAN, the overlay data plane, must be IPv6-only. This means VXLAN source-interfaces (typically loopbacks) on the VTEPs are configured IPv6-only, and VXLAN encapsulation set to IPv6. Finally, EVPN, the overlay control plane, is IPv6-only with MP-BGP EVPN peering exclusively with IPv6 addresses.
These three components of the fabric being IPv6-only would amount to an IPv6-only underlay – so to speak. Now, the production traffic tunneled on top of this can be IPv6-only, IPv4-only, or dual stack on a VLAN (VXLAN) by VLAN basis to support varying protocol requirements in your network.
Benefits of an IPv6-only underlay
Most organizations must still support a mix of production traffic – IPv6-only, IPv4-only, and dual stack. For example, some business-critical tools or applications may never support IPv6. Therefore, there may be separate segments, or even VRFs, that are IPv4-only, while new networks may be deployed as IPv6-only, and networks in transition may be dual stacked for migrations. Luckily, the EVPN-VXLAN fabric can support these various options in the Production Traffic overlay.
Since the overlay and underlay are independent, what drivers are there to implement an IPv6-only fabric? Below is a list I compiled. (Can you think of other drivers for your environment? I’m interested in hearing them.)
- § Scalability: IPv6 offers almost limitless address space to work with. Where IPv4 deployments commonly re-use addresses in various parts of the network, this can lead to unforeseen issues. It is not recommended to re-use addresses, and with IPv6 you don’t need to. With IPv4, this practice has bitten many organizations time and time again.
- § Futureproof: IPv6 is already the majority protocol in many parts of the Internet, and IPv4 will continue to languish. So why implement anything else? And don’t make the mistake of saying, “We’ll deploy IPv4 first and go back and migrate to IPv6 later.” How often does the network team return after a deployment to update temporary network artifacts? IPv6 circumvents the creation of more technical debt.
- § Simplicity: A single protocol IPv6 EVPN-VXLAN fabric – yet it can support various production workloads.
- § Mandates: Your organization may have a mandate to be IPv6-only and eliminate all IPv4 from the network.
- § A natural steppingstone: For those organizations that have limited experience with IPv6, they can start with their EVPN-VXLAN fabric. Then the overlay production traffic, possibly today being IPv4, can evolve over time to dual-stack and eventually IPv6-only.
Test functionality for Your Environment
Most leading network vendors support IPv6-only EVPN-VXLAN fabrics to one extent or another. But like any new network deployment, it is highly recommended to test and verify vendor claims of support. This can take place in a separate, physical network lab environment, or in a virtual environment such as EVE-NG. Make sure to formulate a detailed test plan that includes test cases specific to your environment. And ensure border cases are tested as well. These are where some vendors may still have limitations. Does your network require multicast, for example? What about mLAG or IPv6-only administration? If your vendor’s platform has any IPv6-only limitations, communicate and work with them so they understand your requirements. Find out where the feature you need sits on their roadmap. Or if not on their roadmap yet, work to get it in their feature enhancement queue. Communication and collaboration are key.
Conclusions
For those deploying EVPN-VXLAN networks in their campus and datacenters, the question should not be, “Why would I deploy an IPv6-only fabric?” but rather “Why would I not deploy an IPv6-only fabric?” What constitutes an IPv6-only fabric? Deploying IPv6-only for underlay infrastructure addressing of loopbacks and point-to-point links, as well as running VXLAN (overlay data plane) and EVPN (overlay control plane) as IPv6-only. Production traffic tunneled on top can still be IPv4, IPv6 or dual stack depending on business requirements and migration strategy. There are numerous drivers for this model, whether mandated by a higher authority, or making the IPv6-only choice as a stand-alone decision. Major network vendors support this architecture. However, since these deployments are relatively new, make sure and work with your suppliers on the proper design that fits your requirements. And don’t forget to conduct the proper testing before rolling out in production. Finally, rest comfortable that you are deploying a network model (EVPN-VXLAN) and protocol (IPv6) with a solid foundation for the foreseeable future.
