The CNF Illusion: Navigating the Realities of Cloud-Native Networking – vahidhsahemi.com

Skip to content

vahidhsahemi.com

By - Vahid<br>Posted on May 29, 2026<br>Posted in kubernetes, openstack, virtualization

The CNF Illusion: Navigating the Realities of Cloud-Native Networking

If you keep an eye on the infrastructure space, you’ve almost certainly seen the headlines. The prevailing narrative—echoed in countless medium articles and vendor pitches—is that Cloud-Native Network Functions (CNFs) are the undisputed future, systematically replacing traditional network appliances and legacy Virtual Machines in 5G and enterprise networks.

The pitch is undeniable: package your network data planes into containers, deploy them via Kubernetes, and suddenly your infrastructure is as agile, scalable, and declarative as a stateless web application. It is a beautiful, elegant vision.

But when you spend your days in the trenches fighting for bare-metal performance and stable infrastructure, you start to notice the glaring blind spots. I am not against Kubernetes—far from it. It is the control plane of the modern era. However, we need to shine a light on the dark areas of the pure-CNF hype that too many folks take for granted. We are not quite ready to throw Network Function Virtualization (NFV) and VMs into the legacy bin, and the reasons lie deep within the Linux kernel and the physical realities of the network.

The Egress Reality Check

To understand the limitations of a pure CNF approach, we have to look at the data path. The modern push for ultra-fast, containerized networking relies heavily on kernel bypass technologies and eBPF specifically XDP (eXpress Data Path).

XDP is phenomenal for ingress. By hooking directly into the network interface card’s (NIC) RX queue before the Linux network stack even allocates an sk_buff, we can drop malicious packets, route, or load-balance at line rate. It feels like magic. But networking is not a one-way street, and this is where the simplified CNF narrative starts to fracture.

As highlighted in deep-dive analyses on eBPF capabilities, handling outbound traffic is a completely different beast. XDP does not have a native, symmetrical hook for the TX path. If you want to do complex egress traffic shaping, NAT, or filtering, you cannot simply mirror your XDP logic. You are pushed toward the TC (Traffic Control) subsystem. Suddenly, you are navigating a maze of kernel complexities, losing that raw, clean XDP performance, and dealing with significant overhead. Trying to force complex, stateful network functions into a standard container paradigm often results in brittle workarounds that fail to deliver the promised bare-metal speeds.

The Shared Kernel Dilemma

Beyond the data path limitations, we have to confront the reality of container architecture: containers share the host kernel.

A serious network function often requires aggressive sysctl tuning or specific kernel modules. When you deploy a CNF that needs this level of access, you inevitably end up running highly privileged containers. You strip away the security and isolation that containers were meant to provide, exposing the host to significant risk and creating noisy-neighbor problems that can devastate network latency.

Bridging the Gap: OVS and AF_XDP

Now, to be fair, the ecosystem is not standing still, and there are ways to mitigate these CNF limitations without entirely abandoning the container paradigm. This is where Open vSwitch (OVS) paired with AF_XDP becomes a critical piece of the puzzle.

Instead of relying solely on in-kernel XDP hooks or dealing with the egress asymmetry, we can compile OVS with AF_XDP support. This allows us to bypass the standard, bottleneck-prone Linux kernel datapath entirely. AF_XDP pulls packets directly from the NIC into a userspace memory datapath.

What makes this so powerful for CNFs is that it strikes a pragmatic balance. It delivers massive performance gains by moving the switching logic into userspace, completely side-stepping the classic kernel routing overhead. Furthermore, it does this on standard NICs—you aren’t forced into vendor lock-in with expensive SmartNICs. And unlike purely bypassing everything with DPDK, which often leaves you operating in the dark, AF_XDP maintains a connection to the Linux network ecosystem, preserving some level of operational sanity and visibility.

Using OVS with AF_XDP gives Kubernetes pods a datapath that is actually capable of handling heavy telecommunication or enterprise workloads, making CNFs viable for use cases that would otherwise choke a standard bridge setup.

Enter the Modern VMM

Even with userspace acceleration, there are still scenarios where a shared kernel is a hard blocker for security, multi-tenancy, or extreme tuning. This is why we cannot abandon VMs, but we also don’t need to regress to the days of monolithic, slow-booting hypervisors.

Technologies like Kata Containers and Firecracker give us the exact middle ground...