Thanks to on-going increases in processor performance, the number of Virtual Machines per server blade is expected to grow rapidly, from typically 20 today to a hundred in 2016. Given this growth, the virtual switch that is present on each server blade will need to distribute significantly increasing volumes of network traffic, becoming a strategic focus for networking equipment suppliers and service providers.
One of the leading applications for network virtualization is the ability to provide network overlays (or tunneling) within the server, distributing applications to multiple users as part of enabling multi-tenant installations. When implemented in an edge node such as a server, well-implemented network overlays allow the establishment of an unlimited number of virtual networks, bypassing the 4K limitation of VLANs.
One of the proposed standards for network overlays relies on the RFC-based GRE (Generic Routing Encapsulation) implementation (RFC 2784). It uses some of the optional GRE field headers to build multi-tenant-aware tools for traffic analysis, traffic inspection, and monitoring with a 24-bit identifier, allowing up to 16 million virtual subnets in the same management domain, in contrast to the limitation of VLANs.
One of the major issues for networking OEMs is the challenge of handling millions of tunnels at high performance, because of the limitations of standard, un-optimized OS networking stacks. Various initiatives are underway to offload traffic shaping functions such as ACL and QoS to optimized Network Interface Cards (NICs). Hardware upgrades, however, are always slower to implement than software changes and availability schedules for the latest NICs are somewhat unpredictable. In addition, server blades and other hardware are typically standardized throughout a data center, to facilitate management, and selective hardware (NIC) upgrades add significant complexity to the overall management environment.
If you had the option to achieve performance increases along with additional traffic engineering functions within the virtual switch, would you accept an implementation in which processor cores were dedicated to this function, in order to benefit from a hardware-independent solution to the above network overlay challenges?