If network virtualization is all about virtualizing networks, then network function virtualization (NFV) is all about virtualizing–you guessed it–network functions. But what exactly are network functions, and why would we virtualize them?
Forests and Trees
In traditional, legacy networks we often define the network through the included devices and the connections between them. We might say that a particular network is made up of seven switches and one router connected in a ring topology. Or that we have 6 routers connected in a full mesh, etc.
The problem with this perspective is that it tends to miss both the forest (the whole network as a distributed system) and the trees (the individual and distinct components of that system). This is because devices themselves are subsystems of the overall network system. And they in turn are collections of various hardware and software components. Those same individual and distinct components are what determine how the network works.
What is a Network Function?
For example let’s consider a common and simple function; the ACL. Short for access control list, an ACL is essentially a policy statement that when enforced affects a stateless firewall. In a device-centric view of the network we may perceive that our 6 routers each have their own ACL configured to protect (for example) the control plane; this perception leads us to separately manage 6 ACLs in the network. However, if we take a function-centric view of the network we would perceive instead that there should only be a single ACL, written and updated once for the entire network, and then applied within 6 routers.
Functional Benefits
Independently creating 6 distinct ACLs for the same purpose in the same network is inefficient and error prone. Crafting a single ACL to meet our needs and then applying it 6 times removes the extra work and much of the risk. Many network engineers already work this way, and have for decades. Who was the first to copy a bit of configuration into a text editor, make changes, and then copy and paste the updated stanza to multiple devices? We may never know - but we can safely assume it was done quite some time ago.
Modern network function virtualization (NFV) goes beyond this. Today, NFV is all about disaggregating all of the jobs performed from any specific network hardware. Each role, each purpose is instantiated in software, divorced from any specific hardware. For another example, think about the difference between a switch and a router. These days, that line feels more and more blurry. That’s because we’re often conflating the physical device (a switch) with a software function (the routing daemon).
A Monolithic Past
In the past this distinction was very hard to make, because network gear was only sold packaged as monolithic packages of hardware and software. Imagine an iPhone with no app store. Apple provides the hardware and software packaged together and you have no options other than what Apple makes available. You can replace the firmware wholecloth with a new version but you have no choice in what features are or are not included. This is how all the major networking vendors operated for a long time.
Network Disaggregation
More recently, a wave of disaggregation has swept across the industry. This wave has been building for some time. In 1996 the GNU Zebra project was started. The project created the world’s first open-source software routing engine. While that project was discontinued in 2005, it lives on, having been commercialized by its creators as ZebOS and also forked into another open source project, Quagga (named for an extinct subspecies of the African zebra). Quagga has since been forked into the Free Range Routing (FRR) software suite. BIRD (the BIRD Internet Routing Daemon) is another popular open source software routing engine used by internet exchanges and others around the world. And VyOS is quickly gaining popularity as a more general purpose, open-source network operating system (NOS) even more recently. These packages, along with several others, make it possible to run a “router” on any UNIX-like (Linux, BSD, etc) operating system.
The cumulative effect is the disaggregation of hardware and software for networking. These projects all provide a routing function that can be used independent of any specific hardware. Of course, routing isn’t the only function we can disaggregate from hardware, and disaggregation does not require open-source software. These days many proprietary network functions are also available virtualized as software.
This can be a full, proprietary network operating system (NOS) that runs in a virtual machine (VM) or a container. It can also be a more specific function, like routing, Ethernet switching, firewalling, load balancing, or essentially any other network objective. And this disaggregation can be leveraged in at least two broad methods.
Network Disaggregation Use-Cases
First, disaggregation provides the ability to “mix and match” network hardware and software. Using just the functions you need, from software packages you trust, on the hardware of your choice. Imagine running FRR on a big vendor’s router or switch, or running that vendor’s NOS on a third-party (commodity) bare metal switch.
Second, disaggregation allows you to run these functions purely as software within your datacenter or cloud infrastructure. Think of running BIRD in a container on commodity server hardware, and of all the networking functions provided by a public cloud operator (or in a kubernetes cluster).
Why NFV?
The upshot is that virtualized network functions (VNFs) can be run exactly where you need them, with whatever resources (compute/memory/storage) needed, often independent of specific physical devices. While we will always need hardware switches to push packets physically around the network, in some cases it can be more efficient to move network software into discrete functions.
Among the benefits already mentioned, this allows us to limit our attack surface (by not running features or functions that are not required) and enables easier upgrades (by separating the bits needing to be upgraded). It can also allow us to use the same software for these functions whether they are instantiated on physical network devices, within our own virtualized or containerized environments, or across public cloud infrastructure.
The Bottom Line
Just as network virtualization abstracts our network topology from the physical network connections, NFV abstracts our network architecture from the physical network devices.
Beyond Network Function Virtualization
In the next installment of our “NetDevOps Primer” series, we’ll dive into the enchanting and exciting idea of Infrastructure as Code (IaC).
For those with less patience; everything in this series is available RIGHT NOW in the FullCtl whitepaper: The NetDevOps Primer.