Exploring EVPN-VXLAN Overlay Architectures – Bridged Overlay
In this blog, we discuss the first option in the diagram shown below: Bridged Overlay.
QuickStart – Get Hands-on
For those who prefer to “Try first, read later”, head to Juniper vLabs, a (free) web-based lab environment that you can access any time to try Juniper products and features in a sandbox type environment. Among its many offerings is an IP Fabric with EVPN-VXLAN topology. The fabric is built using vQFX virtual switching devices and the sandbox includes HealthBot, Juniper’s network health and diagnostic platform.
What Is a Bridged Overlay Architecture?
A bridged overlay is a basic approach to an EVPN-VXLAN overlay. Just as the name suggests, it provides Ethernet bridging in an EVPN network and really just extends VLANs between the leaf devices across VXLAN tunnels.
In the bridged overlay model, the ‘intelligence’ is at the leaf layer. The spine layer simply provides connectivity between leaf devices.
With all this bridging going on, you might be wondering, “How can I route traffic between VLANs or out of the fabric?” A key detail about the bridged overlay architecture is that it does not provide routing functionality. With the fabric running as a pure Layer 2 environment, Layer 3 gateway functionality must be provided by another device outside the fabric, for example, with an MX Series router or SRX Series firewall.
Why a Bridged Overlay Architecture?
The lack of Layer 3 gateway functionality can seem like a notable shortcoming, however there are some good reasons for using this approach.
One case is when the architecture uses a firewall as the gateway. Let’s say your security policy defines that all inter-VLAN traffic must go through a firewall, such as an SRX device. The best way to implement this is to have the SRX device also function as the VLANs’ Layer 3 gateway. In this case, the Layer 3 gateway functionality is provided by design outside the fabric, so the bridged overlay architecture is a good fit.
Another case is the ‘one step at a time’ method. Because the bridged overlay approach is so basic, it’s a good option when you want to modernize your DC environment, but you don’t want to go all-in and instead take a phased or incremental approach. For example, maybe you want to start by dealing with just Layer 2, that is, upgrade the legacy Layer 2 DC environment to an IP fabric with EVPN-VXLAN and leave the Layer 3 gateway functionality outside the fabric for now. As a second step, you can bring the gateway functionality into the fabric.
Implementing a Bridged Overlay
With any EVPN-VXLAN architecture, you must configure some common elements including:
- BGP-based IP fabric as the underlay
- EVPN as the overlay control plane
- VXLAN as the overlay data plane
With a bridged overlay, spine devices don’t have any VXLAN-oriented configuration since they serve only to transport traffic between leaf devices. The action happens at the leaf layer, so that’s where the VXLAN configuration goes, including:
- Enabling VXLAN and supporting parameters
- Mapping VLAN IDs to VXLAN IDs
- Assigning VLANs to the interfaces connecting to endpoints
With that, we’ve covered the basics for using a bridged overlay architecture. Are there more fine details? Sure, but this will get you started. We’ll discuss other architectures in a future blog. In the meantime…
To learn more, Juniper has a range of resources available: