Network Virtulazation, NVO, VXLAN, VXLAN GATEWAY, VXLAN MPLS

7 Nov
Using MPLS Protocols to distribute Network Virtualization Overlays across a Service Provider Cloud

Server Virtualization and the evolving network requirements has led to a recent rise in Network Virtualization Overlay (NVO) solutions. VLAN’s and MPLS is a current network virtualization method but has perceived shortfalls with scale and complexity, thus giving rise to new and innovative network virtualization (NV) technologies VXLAN and NVGRE.

Both VXLAN and NVGRE are layer 3, IP-based technologies that pre-pend an existing Layer 2 frame with a new IP header, providing layer 3 based tunneling capabilities of Layer 2 frames. Essentially, this means you can extend a Layer 2 domain across a Layer 3 boundary.

Scenario 1: Network Virtualization Overlay for Fully Virtualized Environments

In the diagram below, VM1, VM2, and VM3 are all part of the same Layer 2 VLAN, say VLAN 45, because the Layer 2 frames are encapsulated via the VXLAN (we would also use NVGRE, but we’ll focus solely on VXLAN) IP header.  Since VXLAN is a Layer 3 protocol, this effectively enables the Layer 2 domain to be distributed across the Layer 3 boundary.

Scenario1-NVO-for-fully-virtualized-environment

The VTEP includes an important function, to consult it’s VM to VXLAN ID VTEP mapping table and inspect Layer 2 frames or Layer 3 packets and determine if a VXLAN header should be added or removed.  The VTEP does the encapsulation and de-encapsulation.  Notice also in the figure above, the VTEP function is housed in the Hypervisor for this scenario.

Scenario 2: Network Virtualization Overlay for Virtualized and Physical Environments

In this diagram, the scenario changes a bit. On the virtualized side, we still have the VTEP in the Hypervisor but on the right side, we have a physical server that’s been placed on its own unique subnet. The challenge comes when these two environments has a Layer 2 requirement to communicate via one another but are in different subnets in different parts of the network.  Here again, NVO’s and VXLAN can help.

Scenario12NVO-for-virtualized-and-physical-environment

The VTEP functionality, supporting the VM to VXLAN ID VTEP mapping table, can also be moved into the network switch. VLAN 45 can be associated with VM1 and VM2 in subnet A and also with the non-virtualized server in subnet C.  VXLAN provides the Layer 3 bridge between the physical and virtual environments. Note in the above diagram, the VTEP function can be in the switch.

Scenario 3: Network Virtualization Overlay across Service Provider networks

With the recent demand for new network virtualization strategies, another deployment model may include providing Network Virtualization across a Service Provider cloud.  For example, Layer 2 MPLS VPN’s or Layer 3 MPLS VRFs have been common service offerings for 10+ years so enterprises and customers are likely to continue to demand these service offerings, but now also using the perceived simpler and more scalable NVO technologies, including VXLAN and NVGRE.

Scenario13-NVO-across-SP-MPLS-Cloud

In this environment, we have two network virtualization technologies that need to be aligned – VXLAN and MPLS. Please note that BGP and MPLS VPN’s are proven Service Provider Network Virtualization technologies, defined in RFCs 2547 and 4364.

The VXLAN VTEP identifies tunnel endpoints, provides the encapsulation and de-encapsulation of the VXLAN header, and provides the VM-to-VXLAN ID VTEP table mapping.

The MPLS PE router performs normal MPLS VPN functions, including using BGP for route distribution and VRF’s for unique routing tables and identified local attachments.  However, the local attachments here are the VXLAN IDs soa VRF associates with a specific VXLAN ID.  BGP is used to distribute the MPLS VRF labels among the MPLS PE routers while the MPLS P routers (MPLS Core) remain unchanged with MPLS label switching.

One interesting point is that VXLAN and NVGRE can support 16 million unique IDs due to the 24 bit wide header field.  The MPLS Label field is 20 bits wide, indicating there are approximately 1 million unique MPLS VPN ID’s.  This issue must be reconciled for any VXLAN to MPLS VPN mapping development.

Ultimately what is needed is an MPLS VPN to VXLAN mapping functionality that bridges the two Network Virtualization technology domains, aka L3VPN – VXLAN internetworking functionality.

Source: http://dcxtc.com/2013/11/06/vxlan-to-the-mpls-cloud/

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: