Deploying Stretched VLANs/LAN Extensions

Key requirements for virtual workload mobility include the ability to migrate a virtual machine to a different physical data center while the virtual machine and its applications are still able to communicate and be identified on the network, and that services running can continue to serve end users.

For this to work, stretched VLANs are typically required. A stretched VLAN is a VLAN that spans multiple physical data centers. In a typical multisite data center environment, locations are connected over a Layer 3 WAN. This is the simplest configuration that removes a lot of complex considerations from the environment. However, in a native Layer 3 environment, devices being migrated must change their IP addresses to match the addressing scheme at the other site, or the routing configuration for the entire VLAN subnet must be changed, meaning all resources on that VLAN must move at the same time. This approach severely restricts the ability to move resources from one site to another and does not provide the flexibility that Rainpole.com wants.

Therefore, creating an environment where live migration over distance can occur requires stretched VLANS, because they can be extended beyond a single site and resources can communicate as if they were local to one another.

There are a number of different mechanisms that can be used to stretch VLANs across physical data center sites, depending on the underlying WAN technology being employed in the environment.

Because dark fibre, DWDM, and CWDM physically connect sites point-to-point, VLANs can be extended across the link as if they were located within the same physical data center site. There is no requirement for any additional configuration, assuming physical connectivity has been established.

However, extending VLANs across sites will likely require changes to the LAN configuration. Inter-data center switches are typically added and connected through a Layer 2 link. The inter-data center switches are then aggregated together to form a virtual switch, providing redundancy at the local level. The switches at each site are linked together in pairs to provide redundancy across sites.

The following table addresses design considerations for extending VLANs across fiber-based data center interconnects.

Layer 2 Connectivity	Distance	Fiber Requirements
Aggregation layer switches are connected to inter-data center switches through Layer 2 connections. Inter-data center switches are aggregated into a virtual switch. Spanning Tree Protocol (STP) must not be able to span sites. Block STP on WAN ports. Use Multiple Spanning Tree (MST) to create separate areas for each site.	Limited to DWDM, CWDM, or dark fibre distances	2 pairs of dark fibre at each site (more for additional bandwidth). DWDM – Single fiber or single pair at each site. CWDM – Single pair at each site, depending on bandwidth requirements.

If the design uses an MPLS network between sites, either owned privately or leased, it can be used to tunnel the Ethernet frames. This can be configured by attaching both an MPLS virtual circuit label and MPLS tunnel ID label to the Ethernet frame.

The virtual circuit label is mixed and does not change between the entry and exit points of the MPLS network, where the label is respectively added and removed. The tunnel label is also added at the exit point, but removed and replaced at each hop of the network until it reaches the exit, where it is removed along with the virtual circuit label. This type of encapsulation is referred to as Ethernet over MPLS (EoMPLS) or Virtual Private LAN Services (VPLS). EoMPLS is used for point-to-point configurations, while VPLS is used in point-to-multi-point scenarios or meshed environments.

If the only solution available to the customer is to obtain native IP between the data centers, there are several ways to extend a VLAN across the sites. The simplest option is to use the Layer 2 Tunneling Protocol version 3 (L2TPv3) to tunnel the Ethernet frames. In this approach, an L2TP header is attached to the Ethernet frame and encapsulates it in an IP packet. The Ethernet frame is then delivered to the remote site without having been seen by the connecting network.

Additionally, proprietary technologies such as OTV (Overlay Transport Virtualization) from Cisco can also be adopted. This is the approach being employed in the sample customer design in Section 16, Workload Mobility Implementation Example. The low-level configuration details of OTV are beyond the scope of this document. In brief, with OTV virtual computing, resources can be deployed across geographically distributed data centers providing the following: