There is a lot of client interest regarding the use of VLAN-stretching to address data center inter-connectivity (DCI) requirements. VLAN-stretching enables layer 2 networks to be stretched across layer 3 networks (L2 over L3), and Cisco has supported this for several years with their OTV technology.
In addition, most major data center network vendors now have alternative approaches. This is certainly “cool” from a technological perspective (hey, I’m finally liberated from containing VLANs to a single physical location!). However, this isn’t panacea, and there is confusion over the use of these technologies. Some common misconceptions include that a) stretched VLANs are required for VM migrations and that b) stretched VLANs are required for Active/Active data centers. These are simply not true.
While there are certainly use-cases where VLAN-stretching makes perfect sense (temporary data center migrations comes to mind), we would caution pinning an entire business continuity strategy on it. VLAN-stretching can solve specific challenges at the network layer (to a hammer, everything looks like a nail), but there are a ton of other things to consider, including
- Application architecture – The data center is meant to support Apps, but will they properly function in an environment where the LAN has WAN-like latency?
- L4-7 services architecture – Will traffic hairpin/trombone between data centers as it goes thru firewalls, ADCs, and other L4-7 services?
- Resiliency and split brain – What happens when the connectivity between the stretched Data Centers goes down (think Ghostbusters and crossing the streams)?
- Traffic Symmetry – What about traffic entering and leaving the data center – can we assure it will be symmetric now that the same subnet is in two locations?
Due to these issues and client demand, we just published research on the topic:
Stretching Your Data Center Network Could Break Applications and Waste Money
Summary: Many network architects are considering “stretched VLANs” to satisfy data center interconnectivity requirements. While these approaches may appear as a simple fix, they often increase complexity, reduce performance and availability, and increase the overall cost of your network.
Regards, Andrew – “What’s tactically right maybe strategically wrong”