The dark side of server virtualisation

A future way to overcome this problem is by allowing "hairpin turns" in the switch. With hairpin turns, the vSwitch is configured to send all traffic, even VM1 to VM2 traffic, directly to the network switch. The network switch then applies the policies and assigns QoS. The VM1-to-VM2 traffic would be sent back to the vSwitch which then delivers it to VM2.

This would make vSwitch a "dumb" switch with only a forwarding role. The problem is that 802.1d, the bridging standard that all Layer 2 switches are based on, does not allow traffic that came from a port to be sent back down the same port the traffic came from. Thus under the current rules the network switch could not return the packet from VM1 addressed to VM2 because doing so would break this rule. This was added to prevent loops from being formed. The IEEE is working a revision to 802.1d that allows the switch to perform hairpin turns and additional work is underway to standardise the dump switch in the hypervisor. When this becomes widespread it addresses the problem and has the benefit of removing most of the coordination between the network and server group.

Enterasys has a workaround that directs the vSwitch to put each VM in a separate VLAN. They select VLAN numbers that are not being used to prevent any potential problems. Because the VMs are in different VLANs, they cannot communicate with each other. When the packet arrives at the network switch, the switch replaces the VLAN numbers with the real one assigned to the VM making it appear to the network and their destination that they have always been in the correct VLAN.

The VLAN connection issue

 There is another VLAN configuration problem that the techniques described thus far do not address. When a new VLAN number is assigned to a port, it needs to be connected to all the other ports with that VLAN number. This requires that all the aggregation switches in the path need to have the VLAN defined on them.

For example, let's say VLAN 5 supports an accounts payable application. All the VMs that support the application are located on one top-of-rack switch that has been configured for VLAN 5. For workload reasons, one of the VMs running the accounts payable application is moved to another rack with its own switches in another part of the data center that is reached by way of several aggregation switches.

Preserving the VLAN means that all the intermediate switches need to be configured with VLAN5; if they are not then the VLAN is broken. Currently none of the products mentioned here deal with how to automatically assign the VLAN in the aggregation switch. This means that if a VM can move across a data center, the VLAN number must be preconfigured in all the aggregation and core switches. Additionally, it is not likely that this problem will be solved in the immediate future.

The industry has worked out a set of adequate solutions for the port VLAN and policy problems. There is no magic, most require the networking and virtualisation groups to coordinate their activities in the short term to make it work smoothly. The hairpin turn is the best long-term solution and the industry is moving toward it. It is important that network managers understand how the various solutions work with the different virtualisation vendors they support, as the full range of solutions are not available for all the virtualisation solutions currently in the market.

Layland is head of Layland Consulting. He can be reached at robin@layland.com.