VI Team Blog

The world of networking is often unfamiliar territory for server and VMware Infrastructure (VI) admins. In most enterprises, networking is the responsibility of a dedicated team of networking experts who may be unfamiliar with the world of server virtualization. So how does a VI admin approach networking? How does he or she say to the networking folks, “I want to roll out VI across these hosts and I need them all connected to the production network.”

First up, involve the network team early and provide them with some information on how VI networking works. A good place to start is the VMware Virtual Networking Concepts paper at http://www.vmware.com/resources/techresources/997 This paper covers the essentials of VI networking: what is a vSwitch? How do I use VLANs? What are my options for NIC teaming, and so on? A network admin will find the concepts presented quite familiar. vSwitches (virtual switches) are very similar to L2 physical switches. Having the network folks read this paper will help put you all on the same page.

Next, talk about the application requirements. In almost all cases, you will want to separate all the traffic by type. 802.1Q VLAN tagging to the vSwitch (Virtual Switch Tagging) is the most common and recommended practice for scaling and separating traffic with restriction from the number of physical NICs. Management/Service Console (SC), VMotion, iSCSI, NFS, and VM traffic in most cases should be separated through the use of VLANs and appropriate NIC teaming policies. The network folks will look after and allocate the VLAN numbering (and may talk about avoiding VLAN 1 and use of native VLANs, etc).

NIC teaming gives you the two-fold benefit of maximizing the use of the host NICs while protecting against NIC, switch of link failures. The most common (and best practice method for guest VMs) is to select “originating virtual port-id” in the port group definition. This spreads the load over the available links in the NIC team—each guest VM hashes to one of the physical NICs (vmnics). Should a link, NIC or switch failure occur, traffic is forwarded over the remaining links in the team. Spreading the links over two physical switches protects the host against network failure, thereby maximizing availability. All that is required from a network admin standpoint is L2 continuity between the switches.

But, what about spanning tree protocol (STP), I hear someone say? Doesn’t this create a loop? vSwitches do not participate in STP. They don’t consume, forward or produce BPDUs. The other thing is, any frame received on a vmnic uplink is never forwarded out another uplink. This means we can connect our uplinks to different switches without causing any loops and avoiding the wasteful STP property of causing links to block (to avoid loops). You do not need to disable STP on the adjacent physical switch ports, but enable trunkfast or portfast to bypass the learning and listening phases of STP upon the link becoming active.

In summary, the concepts aren’t that complex, but you do need to understand how the pieces fit together.

There are many other networking topics to cover and we have quite a rich list of content coming out to help you with understanding and deploying VI networking. Look out for the VI Networking blog at blogs.vmware.com/networking starting this week.

If there is something you think I need to cover, let me know. Email me at guy@vmware.com