which-virtual-networking-technology.html

---
date: 2011-12-21T06:44:00.000+01:00
tags:
- switching
- data center
- overlay networks
- virtualization
title: Which virtual networking technology should I use?
url: /2011/12/which-virtual-networking-technology.html
---

<p>After I published the <a href="https://blog.ipspace.net/2011/12/decouple-virtual-networking-from.html"><em>Decouple virtual networking from the physical world</em></a> article, <a href="https://twitter.com/paulgear1/status/145382168825311233">@paulgear1 sent me a very valid tweet</a>: “<em>You seemed a little short on suggestions about the path forward. What should customers do right now?</em>” Apart from the obvious “it depends”, these are the typical use cases (as I understand them today – please feel free to correct me).<!--more--></p>
<p><strong>Small(er) data centers</strong>: If you have a few hundred physical servers and a few thousand virtual machines, <a href="https://blog.ipspace.net/2011/12/vmware-vswitch-baseline-of-simplicity.html">every-VLANs-on-every port design</a> seems to work well ... assuming a solid MLAG-based dual snowflake L2 design and no multicast applications. As long as the amount of background broadcast noise (primarily ARP) stays low, you’ll do just fine.</p>
<p class="note">The moment you deviate from a pure (dual) snowflake design, you might get asymmetrical traffic flows, unknown unicast flooding (more so if you have a mismatch between ARP timers and MAC address aging timers), and an overloaded network.</p>
<p><strong>Warning:</strong> Implementing a whole data center as a single bridged domain is never a good idea. You should split your infrastructure into several failure domains (aka <em>availability zones</em>) so you don’t <a href="https://blog.ipspace.net/2011/12/large-scale-l2-dci-true-story.html">lose everything if you have a bad hair day</a>.</p>
<p><strong>Large(r) data centers</strong> with more than a few hundred servers in a single broadcast domain will probably need <a href="https://blog.ipspace.net/2011/12/vm-aware-networking-improves-iaas-cloud.html">VM-aware networking</a> to reduce the amount of flooded traffic sent to each server. Obviously, it would be better to split the data center into numerous smaller broadcast domains, but that’s a discussion for another blog post.</p>
<p><strong>Reasonably small compute pools with numerous tenants</strong> might be well-served by vCDNI. If you have a few hundred physical servers (a reasonable number for a <a href="https://blog.ipspace.net/2011/04/vcloud-director-networking.html">single broadcast domain like vCDNI</a> – which is limited to 350 vSphere hosts due to vDS configuration maximums anyway), but need thousands of virtual networks, vCDNI seems like a reasonable solution ... more so if your physical switches support only a few hundred VLANs.</p>
<p><strong>Compute pools distributed </strong><strong>across a data center</strong> for redundancy/maintenance reasons are a perfect use case for <a href="https://blog.ipspace.net/2011/08/finally-mac-over-ip-based-vcloud.html">VXLAN</a>. Instead of implementing large-scale bridged domains with FabricPath, TRILL or 802.1aq, you could build virtual segments across L3 infrastructure. </p>
<p><strong>GRE</strong><strong>-based solution</strong><strong>s with OpenFlow control plane </strong>are a good fit for large-scale operations (public IaaS clouds). They might eventually trickle down to enterprise data centers, but might not be worth the added complexity if you only have a few hundred physical servers.</p>
<p class="warn">Everything I write about Open vSwitch (which uses GRE tunnels) and Nicira’s semi-stealth solutions (which add the control plane to OVS) is pure speculation. You want to know more – go talk to them.</p>
<h4>Anything else?</h4><p>All the other solutions I mentioned are not production-ready. The only shipping <a href="https://blog.ipspace.net/2011/05/edge-virtual-bridging-evb-8021qbg-eases.html">EVB</a> implementation seems to be in programmed in PowerPoint, and the Q-in-Q/PBB/VPLS solutions, while interesting, require significant amount of integration/orchestration development efforts.</p>
<h4>More information</h4><p>If you’re new to virtualized networking, consider my <a href="http://www.ipspace.net/Introduction_to_Virtualized_Networking">Introduction to Virtualized Networking</a> webinar. Check out the <a href="http://www.ipspace.net/VMware_Networking_Deep_Dive">VMware Networking Deep Dive webinar</a> for in-depth information on networking in VMware’s ecosystem.</p>
<p>You’ll get more details on scalability issues, VXLAN, NVGRE and OpenFlow-based virtual networking solutions in my <a href="http://www.ipspace.net/Cloud_Computing_Networking:_Under_the_Hood">Cloud Computing Networking – Under the Hood</a> webinar.</p>