Bite-size pieces of knowledge about tech
Stretching VLANs using NSX-T L2VPNs


Although Network Virtualization with NSX-T allows for dynamic provisioning and fluid movement of workloads between physical networks and compute environments, there are still times where VLAN bridging is necessary. In NSX-T, there are 2 primary methods for doing this:

  • Layer 2 Bridging
    • L2 Bridging is useful for spanning a Segment across physical and virtual workloads, generally for the purposes of migration. This solution requires adjacency between the networks that need bridging. Click here for more info.
  • L2VPN
    • Layer 2 VPN, on the otherhand, does not require adjacency between the networks that require briding. In other words, they can exist across Layer 3 domains, whether within the same data center or across the Internet on a public cloud provider. L2VPN also has the capability to convert between VLAN and Overlay-backed networks (and vise-versa). This allows for many interesting use cases.

In this blog, we will discuss L2VPN. The use case revolves around the need to stretch an existing VLAN from one part of a data center to another part of a data center - where an L2 network domain doesn't stretch. An example of this could be 2 separate ToR pairs in a L3 Spine/Leaf network or 2 separate Pods in a legacy Core/Distribution/Access network topology.

In my lab, I'm simplifying this down to 2 Hosts in a single vSphere cluster, where I have 2 VMs on separate VLANs, but in the same IP space. I have a L3 switch with a gateway located on VLAN 7.

Here is the overall design of my lab environment: Segments


IP Planning

For IP planning, your mileage may vary. This is to give an indication of the amount of IP addresses one must plan for:

Description IP Address / Range VLAN
Web01 Server 7
Web02 Server 77
Server Default GW 7
NSX-T Manager Mgmt 1
Host TN Mgmt 1
Edge TN Mgmt 1
Edge TEP Pool 5
T0 Uplink Network 4
Server T0 Loopback N/A
Client T0 Loopback N/A


  • NSX-T Manager cluster
    • Configure an NSX-T Management cluster to support network services on NSX-T Edges. This includes installing the NSX-T Manager OVA, (optionally) forming a 3-node cluster for high availability, configuring VLAN and Overlay Transport Zones and a Compute Manager connection to vCenter.
  • Segments to be stretched
    • Create VLAN-backed Segments attached to VLAN-backed Transport Zones
    • Create a VLAN-backed Segment for the T0 Uplink Network (VLAN 4 in my lab)


  • An Edge Cluster at Server and Client ends
    1. On the server-side vSphere cluster, create an NSX-T edge that has an interface attached to the segment to be stretched. In my lab, I have a VDS-backed portgroup that trunks all VLANs to the Edge.
      • NOTE - Even though this demo is a VLAN-to-VLAN L2VPN, it is still required to attach the Overlay Transport Zone to the Edge's N-VDS and include TEPs for the Server and Client Edges. This is due to the fact that the Edge Cluster requires TEPs for cluster formulation.
    2. Optionally create a second edge on the server-side cluster to serve as the Standby Edge.
    3. Create an Edge cluster using the edges in the above steps.
    4. Repeat steps 1-3 for the edge at the Client location
  • T0 Server
    • Adding a T0 Gateway for the L2VPN Server is fairly simply. Enter a useful name, set the HA Mode to Active / Standby, and attach the appropriate Edge Cluster.
    • Once added though, some additional configuration is necessary
      • Create an external Interface with the appropriate IP Address / Mask and attach to the T0 Uplink Network Segment
  • T0 Client
    • Repeat the same steps as the T0 L2VPN Server
  • Test VMs connected to each Segment

Test VMs

L2VPN Setup

OK, now that we've cleared the pre-requisites - on to the fun stuff.

Create IPSec Server and IPSec Client VPN Services

As mentioned earlier, the NSX-T L2VPN service is tunnelled inside of an IPSec tunnel. Therefore, the first step in creating an L2VPN service is to create the IPSec tunnel.

The IPSec services tie the IPSec service to a specific T0 or T1 (in this case, T0).

IPSec VPN Services

Create L2VPN Server and L2VPN Client VPN Services

Just like the IPSec VPN Services in the previous step, this step ties the L2VPN service to a specific T0 or T1 (in this case, T0). Please make sure that the IPSec VPN Service and the L2VPN Service for the Server tie to the same T0 and the IPSec VPN Service and L2VPN Service for the Client tie to the other T0. In other words, don't mix up Client and Server!

L2VPN VPN Services

Create Local Endpoint for Server

Create a Local Endpoint (Loopback) for the L2VPN Server by choosing the appropriate IPSec VPN Service and IP Address.

Create L2VPN Session for Server (this will automatically create an IPSec Session)

  • Name the session
  • Choose your Server Local Endpoint
  • Type the IP of the Client Endpoint
  • Create a pre-shared key
  • Defined Tunnel Interface / pool
    • This pool is used to definte the Virtual Tunnel Interfaces (VTIs). They don't need to be routed in the network. For clarity sake, pick something that doesn't overlap with other IP addresses in your network ( works well for this)

L2VPN Server Session

Note: The Local Endpoint is just a fancy name for the Loopback on the Edge where the IPSec tunnel terminates

Next, under the L2VPN Server Session, add the Segment(s) to be stretched. Pick a Tunnel ID that will be shared on Server and Client side.

L2VPN Server Session L2VPN Server Session

Create L2VPN Client for Client (this will automatically create an IPSec Session and a Local Endpoint for the Client)

L2VPN Client Session

For the L2VPN Client Session, we some similar steps: - Name the session - Type the IP of the Client Endpoint (Loopback assigned to the Client Edge) - Type in the IP Address of the Server Local Endpoint (I'm not sure why, but there is no dropdown for the Server Endpoint in the Client Session configuration)

L2VPN Client Session

  • Instead of typing in any further details, the Client Session page asks for a Peer Configuration "Peer Code". This can be found by opening up the L2VPN Server Session Configuration and clicking "Download Config".

L2VPN Client Session

  • Open the downloaded file and copy the "Peer Code" text from the file and paste it in the appropriate location.

L2VPN Client Session

  • This will automatically populate some configuration information for the Client configuration L2VPN Client Session

Create / Ensure routing between Server and Client Local Endpoints (Loopbacks)

The L3 VPN and underlying L2 VPN services operate over Local Endpoints on each of the T0s. Since Proxy ARP isn't supported for VPN Services, there much be routes in the underlying network and in the T0s to support connectivity between Client and Server.

This can be achieved with static routes or with BGP. Since there are a few choices here, this topic is out of scope of this post.


If all goes well, we should see green status lights (Success) on the following: - All of the 4 VPN Services - Both of the IPSec Sessions - Both of the L2 VPN Sessions - Both of the Local Endpoints - Clicking the "i" next to the Status icon on the L2 VPN Sessions show the status of the tunnels:


  • There is also an "Errors" tab that may aid in troubleshooting any issues


  • Finally, clicking the arrow on the L2VPN Server Session and choosing "View Statistics" shows the individual traffic statistics per segment:


  • The final test is pinging and getting that response across the tunnel!



If the GUI doesn't provide appropriate detail to aid you in troubleshooting a connectivity issue, its best to jump on both the Client and Server Edges, log into the VRF associated with each T0, and view the L3 and L2 VPN configuration. See the CLI Guide for more info on available commands:

More Info

The L2VPN instructions are documented in the official NSX-T Documentation here. As always, reach out if you have any questions!

Context Profile Paths for NSX-T Terraform Provider

While writing Terraform for NSX-T, I found myself yearning to have a quick-list of all the available Context Profile (L7) entries available that are pre-created in NSX-T for use in DFW rules. So, I decided to export all of them via the API Command GET https:///api/v1/ns-profiles The result is a bunch of JSON, which I parsed/converted into a .tf file that can be consumed in Terraform. Basically, its a list of variables that you can...

Read More
Applying a LetsEncrypt Certificate in NSX-T Manager

By now, you may have heard of the free non-profit Certificate Authority (CA) service known as LetEncrypt. The service offers anyone access to certificates that are signed and trusted by most modern web browsers default certificate store. The best part…they’re free! In my case, I’m interested in a wildcard certificate that I can apply to my entire lab environment. Installing Tools The first step is to install a tool called Certbot, which will be...

Read More
How to Configure LAG in NSX-T

In NSX-T, the N-VDS is the virtual switch used to control data-plane traffic through the network and security kernel modules installed on the Transport Node. In the case of a vSphere-based Transport Node, one must dedicate at least 1 physical NIC to the N-VDS in order to facilitate access to these services (such as overlay networking and/or East/West micro-segmentation). In a production environment where resiliency is required, one option available is to configure...

Read More
Hello Cheese!

Yes, that is my spin on "Hello World". I've decided to give this blogging thing a try. I've been doing enough random testing in my VMware lab that I feel like I need to share my trials and triumphs with the community. Wish me luck!...

Read More

Receive Updates