Infrastructure and application virtualization has been the modus operandi in the server world for over a decade. With Network Function Virtualization (NFV), it’s poised to become mainstream in the networking world as well.

Traditionally, computer networking functions such as routing, switching and firewalling have been performed by vertically-integrated appliances combining hardware, operating system and the network function “apps” or services themselves. So say you want to protect your branch office network with a firewall, you’d buy a firewall appliance from your firewall appliance vendor and cable it in between the branch LAN and the Internet, job done.

While simple and robust, this model is starting to show its shortcomings in the context of a rapidly scaling Internet. So your new firewall works great, and now you’re noticing a lot of suspicious blocked connections in the firewall logs – bad guys are trying to breach your network.

From truck rolls to remote roll-out

Turns out the firewall you installed doesn’t support advanced intrusion detection and prevention.  Perhaps it’s an entry-level model where the vendor has omitted the feature, or perhaps it doesn’t have enough onboard storage for the threat signature database. So you buy a new firewall that supports deep packet inspection or perhaps a secondary appliance – either way it’s back out to the branch office to reinstall.

Now what if your job was managing hundreds of branch office LANs all over the country?  At scale, your “simple reinstall” will be slow, expensive and prone to human error.  It’s no wonder much of the push for NFV is by telcos and network service providers with large deployments of CPE on their hands.

Using NFV, the firewalling and IDS/IPS functions are decoupled from the appliance operating system. Instead, the OS is basically a hypervisor under which you can install virtual machines, each VM running a Virtual Network Function (VNF), like firewalling. Rather than route through physical cables, VNFs are chained via virtual interfaces inside software.

This means you can now deploy your new IDS/IPS function much in the same way you’d install a software app.  What’s more, the software roll-out can be orchestrated centrally, no need for site visits.

Because network interfaces can also be virtualized, this design also lends itself to using commodity hardware, i.e. x86 servers. Relative to specialized network appliances, off-the-shelf servers are cost effective to overprovision with storage and CPU grunt. General purpose, future proof hardware means longer refresh cycles and therefore fewer truck rolls.

Is NFV for you?

If rapid deployment of new network functions is key to your business, NFV is a no brainer. Your engineering teams can now focus on developing and delivering those services, free from vendor-imposed constraints. However most organizations following traditional network engineering practices have cause to think twice.

Until NFV matures and its inner workings are nicely wrapped up into platforms, you’re going to struggle without a team of developers fluent in technologies like OpenStack, Linux and Python. Besides, there’s a lot to be said for turnkey functionality and having a “single throat to choke” when things go wrong.

The widespread adoption of network virtualization is inevitable. However, it can only go so far. Recall that layer 1 of the OSI model is the physical layer – fundamentally networking is about physically connecting point A to point B. This means some low-level networking technologies, like cellular radio and out-of-band management, may prove immune to virtualization.