Many of these posts talk about network functions virtualization (NFV) rather than software-defined networking (SDN). NFV is a subset of SDN that is more specific, and it is applicable to a higher level of the application stack. Whereas SDN is aimed at the network layers, NFV is aimed at manipulating the data. The idea of NFV is to take the functions that traditionally would be a part of the network and move them into the compute stack. This move gives us many abilities that we wouldn’t have if the functions remained isolated from the compute. It also lets us move to a much simpler underlying network that is capable of moving traffic around much more quickly. This article aims to examine the different parts that NFV encompasses and to discuss what we gain.
The first, simplest, and most obvious function to virtualize is the switch. At the most basic level, we can’t virtualize servers without also virtualizing their connectivity. While we could in theory pass all of the traffic for all of the virtual machines to an external switch directly, we would not be able to differentiate between the traffic on the way back to the VM without something inspecting the traffic. In effect, we must have half of a virtual switch, so we may as well have a full one. The virtual switch, then, gives us the ability to avoid hairpinning traffic between VMs in the same host out to an external switch. We can move VLAN tagging and some QoS functions into the server, meaning that top-of-rack switches don’t need to do this grunt work. Virtual switching is an integral part of all hypervisors.
The next step up the application stack is to virtualize routing. Some people have been doing this by implementing routing functions in a VM for many years. This has a massive disadvantage, though. Virtual machines running general operating systems are not optimized for routing. There are no ASICs to take advantage of, and importantly, there are limits to the number of interfaces a VM can have in most systems. More modern NFV systems, such as NSX, have brought the functionality to the hypervisor level. Distributed first-hop routing gives us another way to prevent hairpinning, making inter-VM traffic more efficient. It also allows the use of overlay networks, which means that routing decisions can be data-center agnostic.
Companies have virtualized the firewall functions on a small scale for many years using VMs with multiple NICs. The advantage of virtualizing the firewall is that there can effectively be many small firewalls with simple rule sets that give much finer-grained control than a single big perimeter firewall. Taking this to its obvious conclusion, we get microsegmentation, whereby each vNIC is individually firewalled from the rest of the system. This idea, of splitting firewall functions into smaller, more compact firewalls, is perfect for multi-tenant environments and has been used that way for many years. A firewall for each tenant is implemented with a rule set applicable to it, and is passed into a more general firewall toward the edge of the network.
Next, we have load balancing. The idea of load balancing in software isn’t new. Microsoft’s NLB has been around for decades. However, again, moving the function to the networking control plane gives us much more control over where and how traffic flows, moving away from expensive appliances with limited numbers of interfaces to cheap VMs with limited numbers of interfaces. This obvious extension is similar to moving the distributed router, switch, and firewall to the hypervisor. This, of course, won’t happen as quickly with load balancing as it has with the other, more popular functions.
Finally, we have the last of the security functions: the intrusion detection and intrusion prevention systems, the scanning tools that ensure compliance, etc. These are all functions that exist or have existed as appliances and can move into the compute cloud.
Another thing all of these functions have in common when moved to the compute infrastructure is the “software-defined” part of SDN. When we move them out of the network and into the compute infrastructure, we gain the ability to instantiate and manipulate purely in software, growing or shrinking at will. While most SDN systems encompass the NFV functions, keeping the separate functions as mix-and-match attributes can be very useful. Keeping the NFV functions away from the “network proper” allows for a simpler, more efficient network.