VCAP6-NV (3V0-643) Study Guide – Part 9C. NSX L2 VPN.

This is part 9C of 20+ blogs I am writing covering the exam prep guide for the VMware Certified Advanced Professional 6 – Network Virtualisation Deployment (3V0-643)  VCAP6-NV certification.

At the time of writing there is no VCAP Design exam stream, thus you’re automatically granted the new VMware Certified Implementation Expert 6 – Network Virtualisation (VCIX6-NV) certification by successfully passing the VCAP6-NV Deploy exam.

Previous blogs in this series:

Part 1 – Intro
Part 2 – Objective 1.1
Part 3 – Objective 1.2
Part 4 – Objective 1.3
Part 5 – Objective 2.1
Part 6 – Objective 2.2
Part 7 – Objective 2.3
Part 8 – Objective 3.1
Part 9A – Objective 3.2 IPSec VPNs
Part 9B – Objective 3.2 SSL VPNs

This blogs covers:

Section 3 – Deploy and Manage VMware NSX Network Services
Objective 3.2 – Configure and Manage Logical Private Networks (VPNs)

  • Configure L2 VPN service to stretch multiple logical networks across geographical sites.

As exam objective 3.2 is quite large and covers IPSec VPNs, SSL VPNs and Layer 2 VPNs, I have decided to split objective 3.2 into 3 parts, the first (9A) being IPSec VPNs, (9B) being SSL VPNs and (9C) being Layer 2 VPNs (this blog).

Configure L2 VPN service to stretch multiple logical networks across geographical sites

The NSX L2 VPN service extends Layer 2 connectivity between remote sites.

The L2 VPN is a point to point service that allows a Layer 2 subnet to be stretched between sites over a Layer 3 IP network encrypted inside a SSL VPN tunnel.

The subnets that are configured to traverse L2 VPN share the same Layer 2 address space.

You can configure VLAN to VLAN, VLAN to VXLAN (and vice-versa) or VXLAN to VXLAN between sites.

One site is configured as the L2 VPN Server (destination) and the other as the L2 VPN Client (initiates the connection).

The L2 VPN service can only be configured on the NSX Edge Services Gateway (ESG).

Some use cases for this service might include:

  • Migrating VMs to secondary data centre.
  • Migrating to a service provider cloud (VMware vCloud Director).
  • Cloud bursting where on-premises private cloud bursts into a public cloud for on-demand capacity spikes.
  • There will be more.

You can configure the NSX L2 VPN service between two sites that are both NSX enabled (VXLAN to VXLAN), or from one NSX enabled site to a non-NSX enabled site (VXLAN to VLAN).

Pictures below are from the NSX 6.1 Administration Guide

nsx

Extend VXLAN across Multiple Sites using L2 VPN

 

nsx2

Extend non-NSX site with VLANs to NSX Site with VXLANs

 

Notice above when extending from a non-NSX site (i.e. you have VLANs and no NSX deployment) the deployment of the NSX Standalone Edge is required.The Standalone Edge is an OVF file that needs to be downloaded and deployed. Suggest reading and deploying this for practice as they might ask this in the exam. I am not covering the deploy and config in this blog of the Standalone ESG.

Some new concepts to understand:

Trunk Port: From NSX 6.1 the Trunk Port was introduced increasing the scalability of the virtual networking. One use-case that can take advantage of this feature is the L2 VPN. With a Trunk Port you can stretch multiple subnets through what’s called a ‘sub-interface‘ which is bound to an ESG vNIC. A vNIC on the ESG can have multiple sub-interfaces and each sub-interface carries a VLAN or VXLAN.

sub

Trunk Port configured with sub-interfaces

Egress Optimisation Gateway Address: I cannot find much detailed VMware info on this, but here is my take. In the above pictures there are two remote sites, each site has its own ESG and each ESG has its own route to the Internet.  We have a stretched L2 subnet. The VMs on this subnet all have the same gateway address (assume: 172.16.10.1). When you configure the L2 VPN server and client, one of the bits of info it requires is the Egress Optimisation Gateway address/s. This allows traffic to be locally routed or blocked from traversing across the L2 VPN link. the other nice thing is if you vMotion a VM from one site to the other no guest OS network changes are required, the default gateway for the VMs remains the same. *Please correct me if this is not 100% correct!

Also read this best practice information with regards to L2VPN Options to Mitigate Looping.  In my nested lab I created a routing loop and it took a few hours to resolve after my entire vSphere/vCenter environment melted. Good learning though to resolve it.

The below picture is from the VMware Hands-On-Labs which I have edited to suit a VXLAN to VXLAN L2 VPN configuration.This is the environment in my lab and it gives you an idea of what my configuration looks like. Both sites are NSX enabled, there is an ESG at each site, and all networks are VXLAN. I am using a Distributed Logical Router (DLR) to simulate external routing. I will walk through the L2 VPN configuration. I will be configuring the ESGs for L2 VPN and Sub-Interfaces.

lab-l2-vpn-config

Lab Configuration

I found the NSX documentation to be lacking when it comes to L2 VPN VXLAN to VXLAN. You need to remove the Web-Tier network logical interface (LIF) from the DLR. The sub-interface is the glue between the web-tier logical network and the ESG.

Credit goes to the following two blogs that had excellent diagrams to help me figure this out: Virtualization Gains and blog.bertello.org

From here on I will refer to Site A which is the left-side with the ESG called L2VPN-Server which is the destination. Site B which is the right-side with the ESG called L2VPN-Client which is the client.

L2 VPN Server configuration – SiteA

Create Trunk Port and Sub-interfaces on L2VPN-Server

First off I need to create a Trunk Port and Sub-interfaces. Before doing this I created a new Distributed Port Group and called it L2VPN_SiteA_PG. I created this on my Compute vDS.

vds

I can now proceed to create the Trunk and sub-interfaces. (VMware documentation here)

Log into the vSphere Web Client.

Click Networking and Security, then NSX Edges.

Double-click the ESG that will be configured as the L2 VPN Server for SiteA, in my case this is L2VPN-Server.

Click Interface, select a free interface (in my case vNIC2) and then select Edit (pencil icon).

Change Type to Trunk.

Change Connected To to the port group that was created (in my case  L2VPN_SiteA_PG).

1

Click the green + sign to Add a Sub-interface.

Enter a Name.

Enter a Tunnel ID, a number from 1 to 4093. The Tunnel ID is used to connect the stretched networks and MUST BE THE SAME ON SITE A and SITE B.

Change the Backing Type. I have selected Network. As per the VMware documentation:

backing

For Network, click Select and add the logical switch. As per the lab configuration for Site A this will be: Web-Tier-Network-6051.

Under Configure Subnets, click the green + sign to Add an IP Address. For the lab configuration this will be 172.16.10.1

w

You can now see my Trunk configured.

1

From the Web-01a VM at Site A I can now ping the sub-interface address 172.16.10.1 on the ESG. Nice! The logical network is directly connected to the ESG.

ping

Configure SSL Certificate on L2VPN-Server

Should you require a CA signed or self-signed certificate blog 8 has the process for creating/importing to the Edge. By default the L2 VPN will utilise a System Generated Certificate.

Configure the L2 VPN Server on L2VPN-Server            

This configures the Destination side of the L2 VPN. The Client connects to this endpoint.

Double-click the ESG that will be configured as the L2 VPN Server for SiteA, in my case this is L2VPN-Server.

Change the L2VPN Mode to: Server

Under Global Configuration Details click Change.

Select your External Interface, Port and Encryption. Note the IP address on the Listener IP, this is required on the client ESG to connect.

Under Certificate Details either use a System Generated Certificate or select the Self-Signed, or add a CA signed certificate. 

11

Under Site Configuration Details, click the green + sign to Add a Peer Site. The username and password entered here are required on the client ESG to connect.

12

Make sure you click Publish Changes to apply the configuration.

13

Enable the L2VPN Service. Click the Enable Button. Click on Publish Changes.

15

Site A is complete. Now need to configure SiteB Edge Services Gateway as a L2 VPN Client.

 

L2 VPN Client configuration – SiteB

I select and double-click my Client Edge Services Gateway. L2VPN-Client

Create Trunk Port and Sub-interfaces on L2VPN-Client

Create a port group on the vDS called: L2VPN_SiteB_PG

b.JPG

Add the interface and sub-interfaces

17

Configure SSL Certificate on L2VPN-Client

Should you require a CA signed or self-signed certificate blog 8 has the process for creating/importing to the Edge. By default the L2 VPN will utilise a System Generated Certificate.

Configure the VPN Client on L2VPN-Client

Click on Manage, then L2 VPN.

Change the L2VPN Mode to Client.

Under Global Configuration Details, click Change.

Enter the Remote VPN Server Address. In my case: 192.168.100.200. This is the Listener IP on the destination ESG.

Select the same Port and Encryption Type as configured on the destination VPN Server.

Select the SiteB sub-interface.

Enter the Egress Optimisation IP of the subnet. In this case 192.168.10.1

Enter the username and password configured on the destination VPN Server.

18

Make sure you click Publish Changes to apply the configuration.

Enable the VPN Service, and click Publish Changes.

Click the Tunnel Status is UP.

19

If I switch back to the destination VPN Server and click Show L2VPN Statistics, I can see traffic has flowed across the VPN.

20

If I jump on the console of the Web-01a and run a ping to Web-02b, the ping is successful. I can also ping from other side.

I can now vMotion migrate over this network from SiteA to SiteB.

ping

That’s all for NSX L2 VPNs. I spent about 12 hours on this topic including repairing my lab so make sure you read the looping section before configuring.

I hope you find this blog of value!

The next blog (Part 10) is covering:

Objective 3.3 – Configure and Manage Additional VMware NSX Edge Services

 

Follow me on Twitter or LinkedIn.

Be Social; Please Share.

 

 

 

 

 

  1. […] The next blog, Part 9C will work through exam objective 3.2 covering: Configure L2 VPN service to … […]

    Like

    Reply

  2. […] Part 1 – Intro Part 2 – Objective 1.1 Part 3 – Objective 1.2 Part 4 – Objective 1.3 Part 5 – Objective 2.1 Part 6 – Objective 2.2 Part 7 – Objective 2.3 Part 8 – Objective 3.1 Part 9A – Objective 3.2 IPSec VPNs Part 9B – Objective 3.2 SSL VPNs Part 9C – Objective 3.3 L2 VPNs […]

    Like

    Reply

  3. […] Objective 3.1 Part 9A – Objective 3.2 IPSec VPNs Part 9B – Objective 3.2 SSL VPNs Part 9C – Objective 3.2 L2 VPNs Part 10 – Objective […]

    Like

    Reply

  4. […] Part 8 – Objective 3.1 Part 9A – Objective 3.2 IPSec VPNs Part 9B – Objective 3.2 SSL VPNs Part 9C – Objective 3.2 L2 VPNs Part 10 – Objective 3.3 Part 11 – Objective […]

    Like

    Reply

  5. […] Part 8 – Objective 3.1 Part 9A – Objective 3.2 IPSec VPNs Part 9B – Objective 3.2 SSL VPNs Part 9C – Objective 3.2 L2 VPNs Part 10 – Objective 3.3 Part 11 – Objective 4.1 Part 12 – Objective […]

    Like

    Reply

  6. […] Part 8 – Objective 3.1 Part 9A – Objective 3.2 IPSec VPNs Part 9B – Objective 3.2 SSL VPNs Part 9C – Objective 3.2 L2 VPNs Part 10 – Objective 3.3 Part 11 – Objective 4.1 Part 12 – Objective 4.2 Part 13 – […]

    Like

    Reply

  7. […] Part 8 – Objective 3.1 Part 9A – Objective 3.2 IPSec VPNs Part 9B – Objective 3.2 SSL VPNs Part 9C – Objective 3.2 L2 VPNs Part 10 – Objective 3.3 Part 11 – Objective 4.1 Part 12 – Objective 4.2 Part 13 – Objective […]

    Like

    Reply

  8. […] Objective 3.2 – Configure and Manage Logical Virtual Private Networks (L2 VPNs) […]

    Like

    Reply

  9. […] review the implementation and configuration of the L2VPN service refer to blog post 9C. Make sure everything is configured as it should […]

    Like

    Reply

  10. Hi,

    At the client VPN site you say that Egress Optimisation IP of the subnet is 192.168.10.1, I guess you mean 172.16.10.1 or I am getting it wrong :).
    Cheers,
    Alper

    Like

    Reply

  11. it’s correct, It called Egress localization and it is very useful in DR site (when you design application based DR) and it prevent the traffic from one site to traverse from the other site in incase we have 3 VM in Site 1 and one of them fails and starting on site 2, the traffic of this VM will return back to site 1 because it still work and just the VM fails in site 1

    Like

    Reply

    1. Hi there, thanks for advising me of that. I have updated the link.

      Thank you.

      Like

      Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: