The Virtual Extensible LAN (VXLAN) announcement made by Cisco and VMware at the recent VMworld event has caused quite a ruckus among networking engineers (I actually received an e-mail with the subject I used for the title of this post). We wonder: Is this is another ploy to get rid of the pesky networking people in a virtual environment or does this actually make sense? The truth, as always, is somewhere in the middle.
What is VXLAN? It’s a very simple MAC-in-UDP encapsulation scheme allowing you to build virtualized Layer 2 subnets spanning multiple physical IP subnets.
Why do we need a new technology? There are several existing MAC-over-IP standards -- including EtherIP and bridging over GRE tunnels -- but none of them addresses the need to go beyond VLAN-based segment tagging, which limits you to 4,096 distinct VLANs. Even if you could use these standards to implement logical segments, you would have to dig deep into the MAC header (in the payload) to find the virtual segment ID. VXLAN uses a 24-bit segment ID, which allows you to deploy millions of virtual segments in a single data center.
Furthermore, the VXLAN packet format is easy to implement in hardware, opening the door for future tighter integration with physical networking gear.
Is VXLAN another proprietary technology? No. It started as an IETF draft co-authored by VMware, Cisco, Arista, Broadcom, Citrix and Red Hat. It would be hard to get a better team (You can guess that Arista and Broadcom have joined the efforts since Broadcom is making chipsets that Arista is using in data center switches.)
When would I need VXLAN? Contrary to some claims that “you should consider VXLAN if you have more than 250 virtual machines in your data center” (Who doesn’t?), you should consider VXLAN if you need hundreds of logical segments. Stick with time-tested technologies like VLANs if you need just a few -- or a few tens -- of logical segments.
VXLAN standard handicaps
Is there a difference between VLANs and VXLAN? VXLAN obviously scales better -- 4,096 VLANs vs. 16 million VXLAN segments -- but it has a tremendous handicap at the moment: A logical subnet using VXLAN encapsulation cannot communicate with the physical devices such as switches, load balancers or firewalls, although one would expect some data center switch vendors to implement Layer 3 VXLAN termination support.
The only way you can connect a VXLAN segment to the outside world is through a virtual Layer-3 appliance such as vShield Edge, Vyatta router or F5 load balancer -- having one vNIC in a physical VLAN and one or more vNICs in VXLAN segments.
Can I run VXLAN across any IP network? Almost -- it does require IP multicast to implement Layer 2 flooding (broadcasts or multicasts).
Can I use VXLAN to implement long-distance VM mobility? I wouldn’t. The technology allows you to do that -- assuming you can propagate IP multicast between the data centers -- but just because you can doesn’t mean that you should. VXLAN has no mechanism to alleviate long-distance traffic trombones that will inevitably start to appear once you spread the virtual machines in the same logical subnet across multiple data centers.
What then is the VXLAN’s sweet spot? VXLAN is an ideal technology to use if you’re building a totally virtualized Infrastructure-as-a-Cloud service where you want to rely on customer-configured virtual appliances to connect the customer subnets with the outside network.
About the author: Ivan Pepelnjak, CCIE No. 1354, is a 25-year veteran of the networking industry. He has more than 10 years of experience in designing, installing, troubleshooting and operating large service provider and enterprise WAN and LAN networks and is currently chief technology advisor at NIL Data Communications, focusing on advanced IP-based networks and Web technologies. His books include MPLS and VPN Architectures and EIGRP Network Design. Check out his IOS Hints blog.