What is a Virtual Network Function?

A Virtual Network Function (VNF) is a network function – a firewall, router, WAN optimizer, or similar service – implemented as software running on a virtual machine instead of purpose-built hardware. VNFs are selected from a vendor catalog, deployed onto devices such as uCPE platforms, and chained together to process traffic in order.

Key takeaways

• VNFs replace dedicated hardware appliances with software on a VM.
• Vendors like Fortinet, Palo Alto, and Riverbed ship VNF images.
• Service chains link VNFs together in a defined processing order.
• uCPE-capable devices host third-party VNFs alongside native VOS services.
• Cloud-hosted VNFs can also run Versa’s own VOS as a virtual appliance.

On this page: Why it matters · How it works · Types · Virtual Network Functions & Versa · FAQ

Why are Virtual Network Functions important?

Before network function virtualization, adding a firewall or WAN optimizer to a site meant racking another box: procurement, power, cabling, and a truck roll when it failed. VNFs replace that model with software on general-purpose compute – a single uCPE appliance or cloud virtual machine can host several VNFs that would otherwise each need dedicated hardware.

That shift matters in three ways. Provisioning becomes remote: a new function is deployed by pushing a software image, not shipping equipment to a branch. Vendor choice widens: a service chain can pair a VOS device with a third-party firewall from a catalog, rather than locking into one vendor’s hardware. Scaling becomes elastic, too: a VNF’s CPU, memory, and disk resize in software, where a physical appliance’s capacity is fixed at purchase.

What is a Virtual Network Function?

A VNF takes a network function that traditionally shipped as a fixed-purpose appliance – a firewall, optimizer, load balancer, or router – and packages it as a virtual machine image running on standard x86 compute. The image (Versa’s uCPE catalog uses the qcow2 format) is paired with a defined “flavor”: memory, disk, and CPU count, dedicated or shared with other guests on the host.

A cloud-init profile, uploaded once and reused, configures the VNF the moment it instantiates, so it comes up with licensing or basic settings already applied. The hosting layer – a uCPE hypervisor at a branch, or a VM platform in a public cloud – supplies the compute, storage, and virtual switching the VNF runs on. The same model applies whether the VNF is a third-party product chained behind a VOS device, or VOS itself running as a virtual appliance.

Types of Virtual Network Functions

VNF catalogs classify each function by what it does. Security VNFs – firewalls and next-generation firewalls from vendors such as Fortinet, Palo Alto, and Secui – are the most common chain addition. WAN optimization VNFs, such as Riverbed or Replify, compress and deduplicate traffic across constrained links. Networking and application-delivery VNFs cover routers, load balancers, and ADCs; Versa headend deployments use one in this role, fronting management servers behind a virtual IP. A catalog’s Others category covers anything that doesn’t fit cleanly, such as custom Linux-based functions.

VNFs also vary by where they run. Branch-hosted VNFs live on a uCPE device’s hypervisor, chained behind or alongside VOS at the site. Cloud-hosted VNFs run as virtual machines in a public cloud such as Azure – including VOS itself, peered to the cloud provider’s virtual routers over BGP.

Virtual Network Functions & Versa

Versa’s uCPE solution turns a bare-metal VOS device (minimum 8 CPUs, 16 GB RAM, 128 GB disk) into a hypervisor host for third-party VNFs, configured end to end from Versa Director. An administrator adds a vendor and product to the uCPE vendor catalog, uploads its qcow2 image and a cloud-init profile, and builds a service chain that assigns dedicated or shared CPUs, memory, and Layer 2 or Layer 3 chaining. Zero-touch provisioning brings the device and its guest VNFs online together, and Director’s Monitor tab tracks each guest VNF’s resource and traffic, with an optional bypass-on-fail path for unresponsive VNFs.

VOS itself is also deployable as a VNF: Versa VNFs run as virtual machines in public clouds such as Azure, peering with the cloud provider’s virtual routers and forwarding SD-WAN traffic as a CSG appliance would at a branch.

Frequently asked questions

What is the difference between a VNF and NFV?

NFV is the broader architecture of running network functions as software on standard compute; a VNF is one instance of that – a specific firewall, router, or optimizer packaged as a virtual machine. NFV describes the approach; a VNF is what gets deployed.

What is the difference between a VNF and a container-based network function?

A VNF runs as a full virtual machine with its own guest OS on a hypervisor. A container-based network function packages the same function as a container sharing the host OS kernel, which starts faster and uses fewer resources but offers thinner isolation between functions.

What hardware does a VNF run on?

Any x86 compute with enough CPU, memory, and disk to host a hypervisor – from a uCPE-capable branch appliance to a virtual machine in a public cloud such as Azure. The VNF image is hardware-agnostic; only the host and its resource allocation change between deployments.

Can VNFs be chained together?

Yes. Service chaining orders multiple VNFs so traffic passes through each in sequence – for example, a firewall VNF followed by a WAN optimizer – before reaching its destination. The chain is defined once as a template and pushed to the host device.

Is Versa’s own software ever deployed as a VNF?

Yes. VOS, Versa’s operating system, can run as a virtual appliance – called a Versa VNF – on public clouds such as Azure, peering with the cloud provider’s virtual routers and delivering the same SD-WAN and security services a physical CSG appliance provides at a branch.

More on Virtual Network Functions

If you want to learn more, these are sources we trust.

Related terms

If you’re reading about Virtual Network Functions, these are worth looking at next.