NFV is about running network gear like routers and firewalls as software on standard servers, making networks more flexible and cheaper.
Let’s spin up a simple virtualized network function (VNF) – a basic firewall – and see it in action. We’ll use iptables on a Linux VM acting as our VNF.
Imagine a small office network. We have a router (physical or virtual) connecting to the internet, and behind it, a switch where our servers live. We want to put a firewall between the router and the servers to control traffic.
Traditionally, this would be a dedicated hardware firewall appliance. With NFV, we deploy a firewall software on a server that’s part of our infrastructure. This server could be running multiple VNFs for different functions.
Here’s the setup. We have two virtual machines:
vnf-host: This VM will run ouriptablesfirewall. It has two network interfaces:eth0connected to the "internet" (simulated by another VM or a bridge), andeth1connected to the "internal network" (connected to our server VM).server-vm: This VM is behind the firewall, representing a protected server. It has one interface,eth0, connected to the same internal network bridge asvnf-host’seth1.
First, let’s configure vnf-host to act as a router and firewall.
On vnf-host:
# Enable IP forwarding (router functionality)
echo 1 > /proc/sys/net/ipv4/ip_forward
# Set up iptables rules
# Allow established connections back in
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# Drop everything else by default on the FORWARD chain
iptables -P FORWARD DROP
# Allow all traffic from the internal network to the internet
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT
# Allow specific internal traffic to specific external IPs (example: allow SSH to a jump box)
# iptables -A FORWARD -i eth1 -o eth0 -p tcp --dport 22 -d 203.0.113.10 -j ACCEPT
# Block all incoming traffic on the internet-facing interface (eth0)
iptables -A INPUT -i eth0 -j DROP
# Allow SSH to the firewall itself from internal network (for management)
iptables -A INPUT -i eth1 -p tcp --dport 22 -j ACCEPT
# Log dropped packets for visibility (optional, but good for debugging)
iptables -N LOGGING
iptables -A FORWARD -j LOGGING
iptables -A LOGGING -m limit --limit 2/min -j LOG --log-prefix "IPTables-Dropped: " --log-level 4
iptables -A LOGGING -j DROP
Now, on server-vm, we need to set its default gateway to the IP address of vnf-host’s eth1 interface. Let’s assume:
vnf-hosteth0IP:192.168.1.1(internet side)vnf-hosteth1IP:192.168.10.1(internal side)server-vmeth0IP:192.168.10.100
On server-vm:
# Set the default gateway to the firewall's internal IP
ip route add default via 192.168.10.1
Now, if you try to ping google.com from server-vm, it will fail because iptables -P FORWARD DROP is in effect, and we haven’t explicitly allowed outbound traffic to external IPs.
To allow outbound pings:
On vnf-host:
iptables -A FORWARD -i eth1 -o eth0 -p icmp -j ACCEPT
After this, ping google.com from server-vm should work. The ICMP packets from server-vm go out eth1, get forwarded by vnf-host out eth0, and the replies come back in eth0 and are allowed back through eth1 by the ESTABLISHED,RELATED rule.
The core problem NFV solves is the rigidity and cost of dedicated hardware. Instead of buying a new appliance every time you need a firewall, router, or load balancer, you can deploy these functions as software on generic compute. This allows for rapid scaling, dynamic placement of functions, and a significant reduction in CAPEX. The "system" here is the combination of compute, storage, and networking infrastructure (often managed by an orchestrator like ONAP or OSM) and the software functions themselves. The key levers you control are the VNF descriptors (how the VNF is packaged and configured), the instantiation parameters (how many VNF instances, their resource allocation), and the network connectivity between VNFs and physical/virtual networks.
What most people don’t realize is that the "network" in NFV isn’t just about the VNFs themselves, but also the underlying virtual network infrastructure that connects them. Technologies like Open vSwitch, SR-IOV, and DPDK are critical for providing the high-performance, low-latency packet forwarding that VNFs often require, bridging the gap between software flexibility and hardware performance.
The next logical step is to explore how these VNFs are chained together to create complex services, known as Service Function Chaining (SFC).