NFV – replacing networking hardware with virtualization

NFV –  replacing networking hardware with virtualization

What is NFV?

NFV or Network functions virtualization strives to replace physical specialized hardware, for instance, a load balancer or a firewall with virtualized instances that perform the same function. Simply said to add a firewall all you have to do is spin up a virtual machine and you don’t have to bother with buying, installing, and configuring a bare-metal proprietary piece of network gear that would handle that function in a traditional datacenter. Also, disregard that similar tools were virtualized or run directly on servers before (eg. iptables in Linux based systems), just nobody gave them a cool name.

In theory, this allows companies to update their networking stack without changing hardware, which can be very costly or logistically complex to replace in a large scale datacenter. Depending on your vendor adding network functions is as seamless as running a few extra VMs or as complex as having vendor-specific NFVs provided by the vendor that runs on their specialized NFV enabled hardware. Also, you could go from entirely Open Source NFV components to completely closed options such as F5s Big IP platform (which also allows running their NFV instances on nonproprietary hardware). In recent years there has been a trend among major networking vendors in pushing towards providing NFV virtualized versions of their hardware offering. 

When does NFV make sense?

  • Adding a particular network component to the current stack 
  • Add network component without large scale buying and installing of hardware
  • Adding a particular functionality to an existing SDN
  • Experimenting with the usage of a particular function without having to buy dedicated hardware (starting VMs is always faster than shipping hardware)
  • When you can take the performance hit virtualization and lack of dedicated hardware can have compared to barebones dedicated solutions (probably doesn’t apply to you if you’re upgrading decades-old gear)
credits: xkcd

Commonly used as a Silver bullet:

1. NFV will transform your <<insert segment or vague business sounding word>>:
  • Network functions virtualization is specifically dealing with the networking stack (eg. datacenter networking or whole corporation). If the problem definition is not talking about problems on this particular level of abstraction, just disregard them.
  • You don’t plan to upgrade aging gear in order to increase capacity, solve problems, change vendors…
  • Problems with the current network stack or aging equipment nearing the end of life.
  • Need to change gear due to new demands that old gear can’t solve
2. It will reduce costs and increase performance
  • If it’s open-source it’s cheaper/free to implement. Assuming you can find, pay, train and retain people who know how to maintain it as part of your network maintenance/sysadmin team
  • If its vendor offering VM licenses with network functions, it’s cheaper than hardware but licensing fees can add up over time. And you still need to find, pay, train, and retain people who know how to maintain it as part of your network maintenance/sysadmin team. 

In both cases above, as well as with the traditional buy proprietary hardware option, you should try to see what will provide you the required level of performance (there is no real-life “best” only adequate for the use case), and then judge what resources you have (gear, people, know-how…) and if you’re working on a large scale thing what will be the easiest thing to keep properly staffed. 

3. It will simplify and optimize your <<insert IT or business concept>>
  • In case you’re replacing a current piece of hardware. It probably won’t (it will keep it more or less at the same level of complexity)
  • In the case where you’re replacing 10 dedicated hardware boxes with one NFV virtualization server/switch combo. It probably will (assume you know how to run and configure said NFVs, and that they are a good direct substitute for the gear they replace)
  • If you have to add new paradigms (on-premise cloud, cloud, containers, VMs, different NIC protocols/connectors/cables). It will probably complicate your setup, and it also might require a major HR or logistics effort in order to implement. 

Further reading:

Back to top