A Quick Thought on VXLANsSeptember 3, 2012
After attending VMworld this year, I decided I needed to try to understand VXLANs a little better. Based off of the basic concept that it stretches a layer two broadcast domain over layer three networks, I was worried that I knew how this was accomplished.
What is VXLAN?
VXLAN stands for Virtual Extensible LAN and is a fairly new method of making the datacenter network elastic. Suppose for example that you want to be able to move your virtual machines from your own server room to a co-location and then to a public cloud depending on what the load was on your environment. In order to do this without causing downtime, you’d need a way for your layer two ethernet frames to continue getting from your clients to your servers even, if a router is in that path.
How VXLANs work
Lets remember that computers use Ethernet frames to communicate with one another on the same broadcast domain. If a two machines are separated by a router, they will need to use IP communications to exchange information. Switches will hold MAC addresses in a table in order to cut down on broadcasts. If machine A is trying to reach machine B and the MAC address is known, the switch will forward the frame out the corresponding switch port. If the MAC address is unknown it will flood the frame or broadcast it out all switch ports in order to find the correct MAC address. Routers will drop these broadcast frames.
VXLANs work by encapsulating the Ethernet frames inside of an IP Packet. Encapsulation is certainly nothing new, VPNs use encapsulation to carry secured traffic between destinations, but VXLANs may change how LANs are thought of and built. Now if the MAC Address is not known by the switch (or the vSwitch) a multicast packet is sent to the router which can then be sent to other machines in the same VXLAN Segment.
In this first example, we see what happens when machine A tries to communicate with machine B and they are on the same VLAN but separated by a router. We see that once the ethernet broadcast gets to the router, the packet is dropped.
In the second example we assume that machine A and B are on the same VXLAN segment. We can assume that machine C is not on the same VXLAN Segment.
The benefits of VXLANs could be utilized in a variety of ways, including making public and private clouds into Hybrid Clouds that have endless resources. Say for instance that your private cloud has 100 GB of available memory to use. If this is being used up by production and more resources are needed, simply vMotion your virtual machines to a public cloud that you’re doing pay-per-use on. When you provision more memory or cut down on resources, then they can be moved back. If you’re using VXLANs then the vm you moved could be on the same layer two address which would be likely not even noticeable by users.
VXLANS can also be very useful for multi-tenancy. Now the same IP addresses can exist on the same layer 2 netowork because they’re wrapped in an extra layer of encapsulation. Not only this, but in a multi-tenant environment you may find out that you’re quickly runnin out of VLANs. VXLANS can help solve this problem.
VXLANs essentially allow you to modify your infrastructure quickly to meet operational needs, without having to wait to modify physical network resources.
The software designed networking that VMware has in mind with the VXLAN idea is certainly an interesting one and perhaps has merit in specific use cases. However, my thoughts are that it should only be used for the specific use cases. In my opinion multicast traffic for a datacenter shouldn’t be passed ove a WAN unless absolutely necessary. It will increase collisions over a likely smaller WAN connection. It also may cause some security problems since many packet inspection utilities aren’t ready for this type of encapsulation.
Please share your thoughts on the subject. I’d love to hear them.