Overview

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:

Configuration

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:

Pre-requisites

• 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

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).

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!

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 (169.254.0.0/16 works well for this)

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.

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

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)

• 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".

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

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

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.

Validation

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!

Troubleshooting

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!