Network Function Virtualization with Linux Namespaces

I virtualized network functions, a router, a firewall, and a load balancer, as isolated Linux network namespaces connected by veth pairs, then chained them into a single service path. Running VNFs in software on commodity hardware replaced dedicated appliances for the lab fabric.

Objective & Context

NFV decouples network functions from proprietary hardware, running them as software instances that can be chained into service function paths. This lab uses namespaces as lightweight VNFs and HAProxy as a virtual load balancer, the same primitives behind container networking.

Environment & Prerequisites

Step-by-Step Execution

1. Create VNF namespaces and link them [PRIVILEGED]

Expected output:

(no output on success: every ip command here is silent)

Expected output:

lo               UNKNOWN        127.0.0.1/8
veth-fw2         UP             192.168.100.2/30
veth-fw          UP             10.0.0.1/30

What this teaches: namespaces plus veth pairs are the lightweight primitives behind containers, VNFs, and virtual routers alike.

Creating a veth pair leaves both ends in the current namespace: each end must be moved with ip link set ... netns, addressed, and brought up, or the link stays DOWN and nothing routes. The host (client side) reaches the service network through 192.168.100.2, and the lb namespace returns traffic through 10.0.0.1.

2. Run a firewall VNF in its namespace

Expected output:

net.ipv4.ip_forward = 1

Expected output:

table inet filter {
	chain forward {
		type filter hook forward priority 0; policy drop;
		ct state established,related accept
		tcp dport 80 accept
	}
}

What this teaches: a firewall VNF is just packet-filter rules scoped to one namespace's interfaces.

The add rule command fails on a fresh system unless the table and chain already exist: create them first, exactly as above. The chain uses policy drop with an established/related rule so return traffic passes; only new connections to TCP 80 are permitted. ip_forward is a per-namespace setting, so it must be enabled inside the fw namespace. Confirm forwarding between the links with: ip netns exec fw ping -c 2 10.0.0.2.

3. Run HAProxy as the load-balancer VNF

Config content (save as /etc/haproxy/lb.cfg; install first with sudo apt install -y haproxy):

global
    daemon
defaults
    mode http
    timeout connect 5s
    timeout client 30s
    timeout server 30s
frontend web
    bind 10.0.0.2:80
    default_backend web
backend web
    balance roundrobin
    server b1 127.0.0.11:8001 check
    server b2 127.0.0.12:8002 check

Expected output:

Configuration file is valid

Expected output:

(haproxy prints nothing: the daemon directive backgrounds it)
LISTEN 0      128    10.0.0.2:80    0.0.0.0:*

What this teaches: chaining VNFs turns independent functions into an ordered service path, the core NFV idea.

Always validate the config with haproxy -c before starting: a typo otherwise kills the process silently. The backends are two Python web servers on loopback aliases inside the lb namespace (any 127.x address is valid on lo). HAProxy health checks (check) mark a backend down if its server stops responding.

4. Test the full service chain [PRIVILEGED]

Expected output:

<!DOCTYPE HTML>
<html lang="en">
<head>
<meta charset="utf-8">
port 22 blocked by the firewall VNF

What this teaches: the chain is only real when traffic provably traverses it: the request crossed the firewall VNF, hit the HAProxy frontend, and was served by a backend.

HTTP through the chain returns a directory listing (proving the firewall passed TCP 80 and the LB distributed to a backend); SSH to port 22 times out (proving the drop policy works). Repeat the curl a few times and watch the backend logs alternate between b1 and b2 (roundrobin). Cleanup when done: sudo pkill -f 'http.server 800' \; ip netns exec lb pkill haproxy \; sudo ip netns del fw \; sudo ip netns del lb.

Validation & Testing

Send requests through the chain and confirm they traverse firewall then load balancer and distribute across backends. Pass criteria: only permitted traffic passes the firewall VNF and load is shared across both backends.

Troubleshooting

Key Results

• Chained 3 virtual network functions into a single service path.
• Replaced dedicated appliances with software VNFs on commodity hardware.
• Load-balanced traffic across 2 backends through the HAProxy VNF.
• Isolated each function in its own namespace for clean teardown.

Practice Challenges