Layer 2 services over SD-WAN?

VPN services have evolved quite a bit, so let’s all agree that how we have been provisioning and consuming business VPN services has changed a lot over the years. The fun thing about technology is that it changes. We find more efficient and faster ways to deliver services, and those changes tend to be disruptive. Now, in the context of WAN and branch connectivity, the most recent innovative change is Software-Defined WAN (SD-WAN).

Unless you have been living under a rock these past 4-5 years, you should know that SD-WAN has created quite a stir across the board as, being bold here, the new de-facto standard in how to provide connectivity across the WAN. Now, we won’t go into detail of what SD-WAN is, so hopefully either you know already, or will go find out. (Here’s a good place to start).

One thing to note is that across the board, some SD-WAN vendors built their architecture on a routing foundation and a few have taken a different approach. A routing foundation make sense considering SD-WAN’s focus on the WAN and branch, and routers have been deployed for years at the edge. Most everyone knows routing. The main differentiator (around routing) between SD-WAN vendors is – How much routing is supported? Beyond OSPF and BGP, is MPLS supported? If MPLS is supported, is L2 and L3 supported? >Protocol support is varied across the board so do your research when evaluating your vendors.

L3VPNs have been deployed in masse over the years. As providers and enterprises are looking to SD-WAN, a certain level of routing and MPLS support is needed to integrate the existing with the new. So far, this has been going successfully since early 2016 – all one has to do is look at the increase in deployments across all of the SD-WAN vendors.

But, what happens if a provider wants to integrate a layer 2 service into SD-WAN? More accurately, what happens if they want to integrate an SD-WAN service with an existing and established layer 2 connectivity service model? Let’s pretend that over time the layer 2 service will go away. In reality, it will not disappear immediately. For those of us who have been around, there isn’t a magic wand that we can wave that transforms an entire enterprise WAN or SP infrastructure in a single day. I wish that was real though…

Back to the topic at hand….

Layer 2 VPNs. SD-WAN. Can it be done? Absolutely it can.

The types of L2 VPN service we will discuss and map to SD-WAN will be Ethernet Virtual Private Line (EVPL) and Ethernet LAN (ELAN). Simply, the below diagram summarizes (and hides much of the architecture) what these services look like without SD-WAN:

The goal of course is to have pure layer 2 connectivity between the sites, across the WAN.

Well, SD-WAN can complicate this.

The issue here is that we have the same network across both sites that are connected over a routed SD-WAN architecture. That SD-WAN overlay is really just a bunch of SD-WAN appliances with routes to each other through secure tunnels. So, in this instance, to get MAC-1 to talk to MAC-2, it’s going to be routed over the SD-WAN Overlay. Well, how does that work if the networks are the same? What happens if it is a layer 2 service/protocol? It breaks… unless you can create a layer 2 SD-WAN or emulate a layer 2 service across the SD-WAN.

So how does that happen?

First, Versa Networks has integrated a full NGFW and UTM in the Versa Cloud IP Platform. Ok – great, why does this matter? Well, you know how firewalls support a virtual-wire mode that is transparent at layer-2 but still do their job?

Traffic is switched but the FW still inspects and applies the appropriate rules and policies. Keep that in mind for now…

Versa Networks can emulate a layer 2 service P2P and P2MP across the SD-WAN overlay and allow for MAC-to-MAC communication – even forwarding broadcasts and multicasts.

How?

In short, Versa creates a virtual-wire that connects a physical port with a virtual tunnel interface (GRE in our example). That virtual tunnel (GRE) then connects to another SD-WAN site.  It’s like a native pseudo-wire service built directly into the SD-WAN edge.

Now let’s look at it with IP addressing and some packet information for you.

Referencing the IP addresses within the above illustration, below are the steps on how this is done in a little more detail.

  1. Step-1: The Customer-Edge Virtual-Router-1 (CE-VR-1) within FlexVNF-1 receives an Ethernet frame from L2-SW-1. It constructs a GRE Header with the Source-IP of the GRE-packet as 192.168.1.1 and Destination-IP of the GRE-Packet as 192.168.3.6. The DSCP of the GRE packet is set according to Layer 3/4 QoS or Application-QoS policy.
  2. Step-2: The received Ethernet frame is then encapsulated within the GRE tunnel and then internally forwarded to SD-WAN-VRF-1 within the same FlexVNF-1.
  3. Step-3: SD-WAN-VRF-1 would look up a matching SD-WAN traffic policy based on the DSCP value of the GRE packet and proceed to forward the GRE traffic along the appropriate SDWAN transport path.
  4. Step-4: SD-WAN-VRF-2 within FlexVNF-2 receives the original Ethernet frame which is encapsulated within the GRE-packet.  It internally forwards this packet to the Customer-Edge-Virtual-Router-2 (CE-VR-2) within the same FlexVNF-2 using normal IP forwarding mechanisms.
  5. Step-5: CE-VR-2 receives this GRE packet, extracts the Ethernet frame then forwards the Ethernet frame towards L2-SW-2.

Here is an illustration of where those steps take place.

Not only can Versa SD-WAN support a virtual-wire service through the overlay, but the customer-side-VR is also able to provide all Versa features. See the below diagram for a look.

These services can be configured to occur in a transparent fashion and when combined with the virtual-wire, provides layer 2 connectivity within the SD-WAN and not sacrificing on application traffic policies and security.

In summary, the Versa Cloud IP Platform can provide layer 2 connectivity with SD-WAN. Accomplished by providing a transparent customer-side VR and a virtual-wire through the SD-WAN overlay allows for seamless layer 2 connectivity from site-to-site or even site-to-multisite.

Advantages of this approach:

  1. Map existing layer 2 services across a layer 3 SD-WAN architecture
  2. Provide advanced SD-WAN features such as ‘Application Based Dynamic Path-steering’ to a layer 2 service
  3. Leverage zero-touch provisioning for CPE VR instantiation
  4. Benefit from one-touch change management with Versa Director
  5. Gain visibility into layer 2 traffic flows across the SD-WAN with Versa Analytics

If interested, reach out to us and request a demo >here. The team would be more than happy to show you a demo on how we can help you bring layer 2 connectivity services in-line with SD-WAN.

Leave a Reply

Your email address will not be published. Required fields are marked *