Redefining Networking

The networking industry as we know and love is shaken. New concepts emerge almost daily, buzz words abound, various “visions” in their nascent forms mixing reality with fantasy. Beneath the surface of chaos, fundamental changes are taking shape.

Like many network professionals, I feel the need to navigate through the frontal tide of confusion, and grasp the essence of change. Initially, as I swallowed a lot of information, I was easily confused and swayed one way or another. Let’s face it, most materials out there are vendor affiliated, which is inherently partial and biased. But over time, a clearer picture has emerged. However pure and simple, it has given me consistency and continuation in the thought process. I hope it will help you establish your own framework as well, and chart your own course forward.

Virtual Networking – the beginning of change

Let’s start with why, why the change, why now. To me, change is not about doing what networking already does, in a different way. Fundamentally, networking enables communication and supports compute, which enables applications. Compute has gone through its own revolution which is virtualization. Compute virtualization brought networking into the hypervisor environment, thus creating an overlap between two previously separate domains. This rudimentary form of virtual networking can be seen in the form of current generation virtual switches.

Another look at Flow Control in the cloud

I posted about Cisco Flow Control with NetApp NAS during first round of cloud implementation almost two years ago. Paul commented about updates in NetApp documentation, so now is a good time for an update, with a fresh look at the general use of flow control.

Let’s start with NetApp’s “Ethernet Storage Best Practices”, which recommends:

1.  Not enable flow control throughout the network
2. Set storage to “send” flow control, set switch to “receive”

We can all agree on the first point. 802.3x Ethernet Flow Control has not been widely adopted in practice, due to implementation complexity and hardware dependency. Higher layer mechanism such as TCP Windowing, is more predictable and effective for end-to-end flow control.

vmware ESX/ESXi host network load sharing options - Simplified

Why load sharing

With virtualization, network and server domains converge; there are usually multiple vendors for server, NIC, storage, and networks. A typical example is using Nexus 1000v which is a Cisco product, embedded in ESX which is VMware, utilizing an HP NIC, and interacting with NAS which is yet another vendor.

Why load sharing? It is high desirable to have redundant uplinks from an ESX host for high availability. In addition, load sharing over redundant uplinks improves performance and utilization. So what are the load sharing options from the host?

A fundamental design is how traffic flows to and from VM to the rest of the network. In this example, VMs reside in ESX, but the concept is the same for any virtualization host interacting with the network.

There have been numerous vendor documents, often covering a certain aspect in detail, occasionally conflicting and confusing as technologies have been evolving. I posted earlier about load sharing mainly on Nexus switch side. Scott Lowe has a series of excellent articles on the topic. Why the summary here? I found it necessary to organize multiple concepts around host load sharing under a simple framework to make it easier to understand and apply.

Options

The following table summarizes common load sharing options, from the least desirable to the most.

click to see full size image of the summary.

Additional Considerations - LACP

The last two options require some clarification. Without Nexus 1000v, VMware does not support dynamic DHCP.  Therefore VMware documentation usually specifies “mode on” as the recommended configuration. Cisco definitely supports dynamic LACP, although earlier Nexus 1000v releases may have had some LACP specific bugs. The latest Nexus 1000v Release 4.2(1) SV1(4) contains many fixes, but is to be proven in a production system, it also has the additional benefit of LACP offload from VSM to VEM. If you know of more recent developments or road map, please kindly let me know.