interfacing-overlay-virtual-networks.html

---
date: 2014-01-15T07:51:00.000+01:00
tags:
- data center
- overlay networks
- MPLS VPN
- virtualization
title: Interfacing Overlay Virtual Networks with MPLS/VPN WAN
url: /2014/01/interfacing-overlay-virtual-networks/
---

<p>During my <ahref="http://www.ipspace.net/ExpertExpress">ExpertExpress engagements</a> with engineers building multi-tenant cloud infrastructure I often get questions along the lines of “<em>How do I integrate my public IaaS cloud with my MPLS/VPN WAN?</em>” Here are a few ideas.<!--more--></p>
<h4>Don’t Overcomplicate</h4><p>Let’s eliminate the trivial options first. </p>
<ulclass="ListParagraph"><li>If your our public cloud offers hosting of individual VMs with no per-customer virtual segments, use one of the mechanisms I described in the <ahref="/2013/12/does-it-make-sense-to-build-new-clouds/"><em>Does It Make Sense to Build New Clouds with Overlay Networks?</em></a><em></em>post and ask the customers to establish a VPN from their VM to their home network. </li>
<li>If your public cloud offers virtual private networks, but you don’t plan to integrate the cloud infrastructure with a multi-tenant transport network (using, for example, MPLS/VPN as the WAN transport technology), establish VPN tunnels between the virtual network edge appliance (example: vShield Edge) and customer’s VPN concentrator.</li>
</ul>
<p>The rest of this post applies to multi-tenant cloud providers that offer private virtual networks to their customers and want to integrate those private networks directly with the MPLS/VPN service they offer to the same customers.</p>
<h4>VLAN-based virtual networks</h4><p>Many public cloud deployments use the “legacy” VLAN-based virtual network approach. Interfacing these networks with MPLS/VPN is trivial – create VLAN (sub)interface in a customer VRF for each <em>outside </em>customer VLAN on data center WAN edge PE-routers (Inter-AS Option A comes to mind).</p>
<divclass="separator"><ahref="/2014/01/s1600-Cloud+MPLS_VPN_VLAN.png" imageanchor="1"><imgborder="0" src="/2014/01/s400-Cloud+MPLS_VPN_VLAN.png"/></a><br/>Simple VLAN-based connectivity</div>
<h4>Overlay virtual networks without MPLS/VPN support</h4><p>If you use overlay virtual networking technology that has no integrated MPLS/VPN support (example: Cisco Nexus 1000V, VMware vCNS, VMware NSX, Hyper-V, OpenStack Neutron OVS plugin with GRE tunnels), you have to use VLANs as the demarcation point:</p>
<ulclass="ListParagraph"><li>Create a VLAN per customer;</li>
<li>Use a VM-based appliance (firewall, load balancer) or L2/L3 gateway to connect the customer’s <em>outside </em>overlay virtual network with the per-customer VLAN;</li>
<li>Read the previous section.</li>
</ul>
<divclass="separator"><ahref="/2014/01/s1600-Cloud+MPLS_VPN_L2GW.png" imageanchor="1"><imgborder="0" src="/2014/01/s400-Cloud+MPLS_VPN_L2GW.png"/></a><br/>Connecting overlay virtual networks and MPLS/VPN WAN through L2 gateway</div>
<h4>Direct integration with MPLS/VPN infrastructure</h4><p>Some overlay virtual networking solutions (Juniper Contrail, Nuage Virtualized Services Platform) communicate directly with PE-routers, exchanging VPNv4 routes via MP-BGP and using MPLS-over-GRE encapsulation to pass IP traffic between hypervisor hosts and PE-routers. </p>
<p>Integrating these solutions with the MPLS/VPN backbone is a trivial undertaking – establish MP-BGP sessions between the overlay virtual network controllers and WAN edge PE-routers. I would use Inter-AS Option B to establish a demarcation point between the cloud infrastructure and WAN network and perform route summarization on the PE-router (it doesn’t make much sense to leak host routes created by Contrail solution into the WAN network).</p>
<divclass="separator"><ahref="/2014/01/s1600-Cloud+MPLS_VPN_Contrail.png" imageanchor="1"><imgborder="0" src="/2014/01/s400-Cloud+MPLS_VPN_Contrail.png"/></a><br/>MPLS/VPN integration with Juniper Contrail</div>
<h4>VM-level integration</h4><p>If you don’t want to use one of the MPLS/VPN-based overlay virtual networking solutions (they both require Linux-based hypervisors and provide off-the-shelf integration with OpenStack and CloudStack), use a VM-based PE-routers. You could deploy Cisco’s Cloud Services Router (CSR) as a PE-router, connect one of its interfaces to a VLAN-based network and all other interfaces to customer overlay virtual networks. </p>
<divclass="separator"><ahref="/2014/01/s1600-Cloud+MPLS_VPN_CSR.png" imageanchor="1"><imgborder="0" src="/2014/01/s400-Cloud+MPLS_VPN_CSR.png"/></a><br/>Using Cisco CSR as MPLS/VPN PE router</div>
<pclass="note">The number of customer interfaces (each in a separate VRF) on the CSR router is limited by the hypervisor, not by CSR (VMware maximum: 10).</p>
<h4>More Information</h4><p>Visit <ahref="http://www.ipspace.net/SDN">SDN</a>, <ahref="http://www.ipspace.net/Cloud">Cloud</a> or <ahref="http://www.ipspace.net/Virtualization">Virtualization</a> resources on ipSpace.net, or get in touch if you need <ahref="http://www.ipspace.net/ExpertExpress">design or deployment advice</a>.</p>
<p>Individual webinars you might find useful include:</p>
<ulclass="ListParagraph"><li><ahref="http://www.ipspace.net/Cloud_Computing_Networking">Cloud Computing Networking</a></li>
<li><ahref="http://www.ipspace.net/Overlay_Virtual_Networking">Overlay Virtual Networking</a></li>
<li><ahref="http://www.ipspace.net/VMware_NSX_Architecture">VMware NSX Architecture</a></li>
<li><ahref="http://www.ipspace.net/Enterprise_MPLS_VPN_Deployment">Enterprise MPLS/VPN Deployments</a></li>
</ul>