While software-defined networks may be slow taking hold in organizations, there are network protocols that are generally associated with SDN that are beginning to see an upswing in adoption such as VXLAN (VMware and Cisco) and NVGRE (Microsoft, Intel, Dell (News - Alert), Broadcom, and Arista).

The introduction of virtualization and the resulting mobility of application instances implied by cloud computing models into the network are generally considered to have exposed two key problems with traditional networking models and protocols.

First, existing network isolation protocols such as VLAN and VRF cannot support large cloud deployments because of limitations on the number of network segments available. Second, the mobility of applications via virtual machine migration is hindered by an inability to cross layer 3 boundaries. This can ultimately limit scalability of applications by reducing the total pool of resources available within a layer 3 network silo.

Virtual network overlay protocols (tunnels, to be more precise), of which VXLAN and NVGRE are the most often referenced, seek to overcome these limitations by creating a virtual network overlay that scales past existing limitations and can scale across layer 3 boundaries. It is important to note that both proposals are limited to the logical network; neither provides a means of crossing L2 boundaries. Both also rely on multicast, which is typically eschewed by network architects as it increases the load on the network.

Problems arise when we start trying to implement overlay tunnels on physical devices, which need to communicate with hosts residing on these virtual networks. To resolve the communication problem between non-virtual and virtual networks, a gateway is required.

Virtual network gateways, for lack of a better term, provide translation from non-virtual networks to virtual networks. For example, inbound requests to public IP addresses must be translated and ultimately directed to the appropriate host. If that host resides in a virtual network domain, the device or service providing the translation must also be able to speak, as it were, the virtual network language. They accomplish this by implementing the appropriate endpoint technology required to participate in the virtual network. For example, a gateway might natively act as a vTEP (VXLAN tunnel endpoint) in a VXLAN-enabled virtual network, providing the necessary bridging technology that exchanges the encapsulated network traffic between IP networks.

The virtual network gateway enables communicating by bridging frames between VLAN-connected hosts and VXLAN tunnels, transforming Ethernet broadcast frames into the appropriate multicast protocol-encapsulated packets. In this way, a virtual network gateway can enable communication between application tiers, for instance, where a very dynamic web tier might be deployed using VXLAN to ensure scalability but communicates with a database host still residing on a traditional network that employs VLANs. 

This is particularly important for key cloud and virtualization technologies that must interact directly with hosts on virtual networks and on traditional networks. It also provides a more topologically advantageous virtual endpoint through which intra-vm network traffic can be routed to reduce or eliminate tromboning traffic patterns.

Virtual network gateways will proliferate as the use of virtual networking continues to grow to support the increasingly dynamic and mobile nature of application workloads communicating with each other and requiring connectivity to services remaining hosted on more traditional network technologies.

Lori MacVittie is senior technical marketing manager at F5 Networks (News - Alert) (www.f5.com).