Pseudo-Wire 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). Be

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, most SD-WAN vendors built their architecture on a routing foundation. It seems to make sense considering its 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 leverage SD-WAN to provide layer-2 connectivity across sites? Let’s pretend that over time layer 2 services 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 type of service we will discuss and map to SD-WAN will be Pseudo-Wire. 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 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 transport layer 2 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 the pseudo-wire P2P across the SD-WAN overlay.

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 SD-WAN-SITE-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 L3/L4 or AppQoS policy.
  2. Step-2: The received Ethernet frame is then encapsulated within the GRE tunnel and then internally forwarded to SD-WAN-VRF-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 at SD-WAN-Site-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) 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 across Versa SD-WAN connected sites while not sacrificing on application traffic policies and security.

In summary, the Versa Cloud IP Platform can transport L2 frames with SD-WAN. Accomplished by providing a transparent customer-side VR and a virtual-wire through the SD-WAN overlay allows site-to-site layer 2 connectivity

Advantages of this approach:

  1. Map existing layer 2 networks to Pseudo-Wire instance(s) and across layer 3 SD-WAN architecture
  2. Provide advanced SD-WAN features to layer 2
  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 existing pseudo-wire connectivity services in-line with SD-WAN.

Leave a Reply

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