Making the Invisible Visible: eBPF Observability for Cloud-Native 5G

The visibility gap in a transformed infrastructure

Inside World Wide Technology's (WWT) Advanced Technology Center, the AI Aerial Innovation Lab gives service providers a realistic production place to prove out AI-native, software-defined network functions like Packet Core and Radio Access Network (RAN) before committing to them in the field. The lab runs NVIDIA AI Aerial on GH200 Grace Hopper Superchips, Supermicro and Cisco compute, Docker-enabled Ubuntu, and Red Hat OpenShift as the infrastructure OS, with OpenAirInterface (OAI) packet Core and RAN instantiated as containerized network functions on top.

Once that Core runs as containerized NFs on Kubernetes/OpenShift, it inherits the same visibility problem every cloud-native network has. Telecom infrastructure has moved through three eras in a little over a decade purpose-built appliances, virtualized network functions on hypervisors, and now containerized, Kubernetes-orchestrated functions. Each step traded dedicated hardware and fixed interfaces for elasticity and cost efficiency, and each step made the network harder to see. An appliance had ports you could tap a VM had a NIC you could mirror, a containerized network function has neither pods churn across namespaces, service meshes rewrite paths on the fly, and east-west traffic never touches a switch port. Agents, sidecars, and switch port analyzer (SPAN) ports either can't keep up with that churn or add enough overhead that teams quietly stop maintaining them.

F5 BIG-IP eBPF Observability (EOB) closes that gap by moving the vantage point to the one layer that hasn't changed across all three eras, the Linux kernel a natural fit for the AI-native, GPU-accelerated environment the AI Aerial Innovation Lab is built to prove out. The solution isn't limited to containerized Packet Core and RAN network functions, though. It applies to any containerized workload running on Kubernetes or OpenShift, which makes it just as relevant to a platform or security team as it is to a service provider's network engineering team.

What F5 BIG-IP eBPF Observability actually does

F5 BIG-IP eBPF Observability (EOB) gives platform, security, and operations teams real-time visibility into cloud-native workloads by capturing telemetry directly from the Linux kernel, using eBPF (extended Berkeley Packet Filter) to run small, verified programs safely inside the kernel itself, the one layer every process, pod, and packet has to pass through, regardless of language, framework, or service mesh. Lightweight eBPF agents, deployed once per Kubernetes or OpenShift node, delivers raw packet captures, live pod-to-pod topology, access to payload data before encryption or after decryption, including traffic protected by TLS 1.3, protocol-specific metadata (SBI, DNS, HTTP, F1-AP), and detailed flow records precisely scoped through user and admin-defined directives and streamed continuously to a message bus for consumption by security, analytics, and assurance tools. The result is deep visibility into how cloud-native services communicate, without requiring application level instrumentation or sidecar deployment for each workload.

Why this matters specifically for 5G core networks

3GPP's Service-Based Architecture means every 5G core network function AMF, SMF, UDM, PCF, AUSF, NSSF, UDR, AF talks to every other NF it needs over a common HTTP/2-based Service-Based Interface (SBI), registering and discovering peers through the NRF. That uniformity is a strength for interoperability, but it's also exactly the kind of east-west, container-to-container traffic legacy monitoring struggles to reach and in production it's almost always encrypted, since SBI runs over HTTPS (TLS over HTTP/2). A packet capture without TLS session keys shows encrypted frames, not the JSON payloads underneath. This is precisely where EOB's kernel-level vantage point, instrumented here through the Tawon agent and Tawon dashboard, earns its keep: it observes traffic at points where the payload is available before encryption or after decryption inside the workload, surfacing plaintext protocol metadata and payload records a downstream packet capture never could, without modifying a single network function.

Three use cases, one EOB deployment

Use case 1: DNS traffic monitoring inside OpenShift

CoreDNS resolves service discovery for every pod in the cluster, making it one of the highest-value, lowest-effort places to start with EOB. A directive scoped to port 53 and the coredns process streams only DNS query/response traffic to a dedicated store, viewable live in EOB's packet viewer or exported as a PCAP for Wireshark. This is a genuine troubleshooting lens, not just a demo the same technique can surface failures invisible at the application layer an upstream forwarder silently unreachable for an entire capture window while CoreDNS quietly fails over to a healthy secondary, well before it becomes a user-facing symptom. A finding that traditionally requires someone to already suspect DNS and go hunting inside the CoreDNS pod falls out of EOB as a two-minute directive.

Use case 2: NRF registration and discovery

Every NF's lifecycle starts the same way: register with the NRF, keep that registration alive, and let other NFs discover you.

AMF -> NRF   PUT NF Profile         -> 201 Created

AMF -> NRF   PATCH Heartbeat   -> 204 No Content

SMF -> NRF   GET Discovery         -> 200 OK (AMF)

EOB validates this directly: TS-1 confirms AMF registration, TS-2 confirms the heartbeat keeps it alive, TS-3 confirms SMF can discover a registered AMF all captured as the traffic crosses the SBI.

Use case 3: Control-plane and user-plane trace

The EOB deployment provides the packet, flow, and protocol data operators can use to follow signaling and user-plane activity for UE registration/authentication (N2, N12, N13, N8) and PDU session establishment (N11, N4, N2/N1, and the N3/N6 user-plane path to the data network) giving one consistent evidence trail from signaling through to user traffic, without a second instrumentation layer.

The takeaway

The shift to containerized, cloud-native 5G cores didn't just change where network functions run it changed where visibility has to come from. Sidecars and application instrumentation don't scale cleanly to CNF density and churn kernel-level observability does, because it doesn't ask the application to cooperate. EOB's combination of lightweight node-level agents, directive-based scoping, and a message-bus-first architecture gives platform, security, and assurance teams a single, consistent vantage point from CoreDNS resolution, to NRF registration, to UE registration and PDU session troubleshooting with the data available in real time to whatever analytics or security tooling already sits downstream.