Doubts with L2VPN and Edge Perimetral

[santunez2275]

Hello Guys

I have the next subject

For MPLS issues that it is not possible to increase the MTU to 1600 I should see an alternative to extend vxlan between my main site and DR.

As I have read and I have commented in this forum, through an L2VPN configuration I can solve the issue, but I have the following question.

My perimeter Edge is configured with OSPF towards a Huawei core, and the networks are published without problems. At the UDLR level, I have OSPF configured with the networks to publish and, as I indicated, everything works perfectly.

Now, with the MTU problem, we created a new Edge for L2VPN and reading information points out that I must add the networks as Sub-interface and that you are removing them from the UDLR.

So, given this scenario, my question is how do I publish the networks in the Perimeter Edge if it is no longer at the UDLR level but as a sub-interface in the Edge L2VPN.

My configuration is the following:

Huawei ----- Perimeter Edge ----- Transit ---- UDLR

For L2VPN

MPLS ------ Switch ---- Edge L2VPN ----- Sub-Interface ---- HR Network.

I have not been able to find information on how to configure this alternative, because I have never had a scenario where I can not increase MTU in the MPLS.

I appreciate any comments about it because it is the first time that I touch this scenario

Thank

Sebastian

[vLingle]

Sebastian,

WRT to your question on publishing networks to the Edge…The ESG can route Logical Switches, just follow this doc Add a Sub Interface.  You will set the “Backing Type” to “Network” and select the LS. 

Regards,

Jeff

[cnrz · Accepted solution]

As addition Egress Optimization may be helpful similar to Local Egress on UDLR

Perimeter Edge on Site1 is used as L2VPN Server, and the new Edge for for L2VPN is on Site2 and acts as L2VPN Client, Huawei router is the CE device for the MPLS Cloud -->  is the undertanding correct? (Or could there be another seperate router for MPLS  and/or L2VPN Server on Site1 could be a seperate Edge other than the Perimeter Edge?)

Is there local egress-ingress requirement for the DR Site2? As UDLR is currently used, this may be a requirement as it allows for VMs on Site2 on seperate Logical switch tiers to communicate without being routed from Site1.

Since L2VPN extends Vlans and/or Vxlans between Main Site and DR as mentioned the LIF interfaces on the UDLR needs to be removed from the Logical Switches on both sites. The default gateway is carried to the Perimeter Edge Trunk Interface, so normally Site2 vxlan/vlan egress is done through Site1 L2VPN Server. So for other subnets such as clients or non-L2VPN server subnets can learn the L2VPN Subnet with adding this Subnet to OSPF or redistributing the connected L2VPN subnet into OSPF. East-West and North-South traffic passes through the Edge on Site1. Since the Perimeter Edge has Ospf with UDLR Control VM on Site1, Intra Site1 traffic may be through Perimeter Edge <-->DLR Instance on ESX host.

Egress Optimization for L2VPN allows the  same default gateway to reside on both L2VPN Server Edge  on Site1 and L2VPN Client Edge on Site2. In that case, similar to  Site1, the L2VPN Client Edge may use ospf with Site2 Mpls router Northbound, and Site2 UDLR Control VM Southbound. In that case announcing /32 VM IP addresses (Since they may exist on Site1 or Site2) for Symmetric traffic may be necessary for symmetrical Ingress on Site1 and 2.

These links may be helpful about  publishing routes for L2VPN Subnets and Configuring Trunk Interfaces:

http://blog.ipcraft.net/nsx-edge-service-gateway-esg-trunk-interface/

Step 1. Create a Port Group for Trunk Interface

First, I need to create a port group on the vSphere virtual switch. This can be a standard or distributed port group and it will be associated to NSX ESG Trunk interface later. I prefer to use distributed port group as I do not need to manually create the port group on every hosts if I have more than one ESXi hosts.

http://blog.bertello.org/2015/04/nsx-for-newbies-part-9-l2vpn-and-stretched-vlanvxlan-networks/

Local Egress Optimization: this is more easy to understand. It enables the ESG to route any packets sent towards the Egress Optimization IP address locally, and send everything else over the tunnel. Why? VM Mobility! If the default gateway for the virtual machines (belonging to the subnets you’re stretching) is same across the two sites you need this setting to ensure traffic will be locally routed on each site. Should you need to migrate VM from one site to the other, you can do so without touching the guest os network configuration.

http://raoconnor.com/nsx/nsx-lab-configure-layer-2-vpn/

Egress Optimization ensures traffic will use the local site edge

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/vcat/vmware-customer-onboarding-wi...

For implementations that require workloads on the extended segment located within the VMware Cloud Provider to access the Internet, egress optimization can be enabled on the NSX Edge appliances with an egress optimization IP address. Typically, this is the same IP address as the default gateway that is used for the on-premises network being extended to the VMware Cloud Provider. Enabling this feature allows Internet bound traffic on the provider side of the connection to exit (egress) through the local egress optimization gateway instead of sending the traffic back over the extended network link to the Internet and then back across the extended link. The egress optimization feature is intended to be used to allow extended workloads to access the Internet or other networks within the VMware Cloud Provider’s environment.