Continuing on from the server configuration in Part 1, this is the NSX-T L2VPN Client setup.
There’s a few options to terminate an L2VPN in NSX-T, but all of them are proprietary VMware, so there’s no vendor inter-op here. This article uses the ‘Autonomous Edge’ option, previously called Standalone Edge in NSX-V, which is essentially a stripped-down Edge VM that can be deployed to a non-NSX prepped host. Confusingly this isn’t the new type of Edge Node used in NSX-T, but instead is the same ESG that was used in V.
The Topology
The Overlay Segments on the left are in the NSX site that’s hosting the L2VPN server. On the right is a single host in a non-NSX environment that will use the Autonomous Edge to connect the VLAN-backed Client-User VM to the same subnet as SEG-WEB.
OVF Deployment
First the Autonomous Edge OVF needs to be deployed in vCenter:
The first options are to set the Trunk and Public (and optionally HA) networks. The Trunk interface should connect to a (shock) trunked portgroup (VL4095 in vSphere) and the Public interface should connect to the network that will be L3 reachable by the L2VPN server (specifically the IPSec Local Endpoint IP). Also, as this is an L2VPN there will need to be a loosening of security settings to allow unknown (to vCenter) MACs to be allowed. If the portgroups are in a VDS then a sink port should be used for the Trunk, alternatively if on a standard portgroup; Forged Transmits and Promiscuous Mode are required.
Next, set up the passwords and Public interface network settings. Then in the L2T section set the Peer Address to the L2VPN Local Endpoint IP and copy the Peer Code from the server setup into the Peer Code field:
The last step in the OVF is to set the sub-interface to map a VLAN (on the local host) to the Tunnel ID (that was set on the Segment in the server setup). Here VLAN80 will map to Tunnel ID80 which mapped to the SEG-WEB:
The Tunnel
Once the OVF is deployed and powered on, either the L2VPN Client or Server can initiate an IKE connection to the other to setup the IPSec tunnel. Once this is established then a GRE tunnel will be setup and the L2 traffic will be tunnelled inside ESP on the wire. There’s a few options to view the status of the VPN:
Client tunnel status:
Server tunnel status:
GUI tunnel stats:
Connecting a Remote VM
Now that the VPN is up a VM can be placed on VLAN 80 at the remote site and be part of the same broadcast domain as the SEG-WEB Overlay Segment. Here the NSXT25-L2VPN-Client-User VM is placed in a VLAN80 portgroup, which matches what was set in the OVF deployment. NOTE there isn’t even a physical uplink in the networking here (although this isn’t a requirement) so traffic is clearly going via the L2VPN Client:
Now set an IP on the new remote VM in the same subnet as the SEG-WEB:
And load up a website hosted on the Overlay and voila!
1338network 
Excellent contribution. I want to ask you the following:
I have two sites managed by NSX-T. I want to extend an NSX-T Segment VLAN (VLAN 2005) with Default Gateway (10.160.40.1/24) defined on the Cisco Nexus network of site A to the NSX-T Segment VLAN (VLAN 3005) defined on the Cisco Nexus network of site B .
Can I use two instances of NSX-T T0 Router, one at each site to be able to build L2VPN VLAN-to-VLAN without using NSX Autonomous Edge ??
Thank you.
Carlos
LikeLike
Sure, that’s an option! The use case for this article is one site that has NSX-T and one that doesn’t.
In your case you can host the L2VPN Server on the T0 at Site A and an L2VPN Client on the T0 at Site B, the server-side setup will be the same as Part 1. There’s even an option to use an NSX-V ESG as a client, which could help with migrations.
LikeLike