Multi-Tier Network Architecture for 5G vRAN Workloads

5G vRAN workloads require network connectivity that standard Kubernetes CNI solutions simply cannot provide. This post covers the four-tier network architecture deployed in the EIB-Customer platform — from management traffic through to sub-10μs DPDK packet processing paths.

Why Standard CNI Isn't Enough

Vanilla Kubernetes assumes a single flat network per pod. A 5G Distributed Unit (DU) running on this platform might simultaneously need:

• Cluster management connectivity (Calico)
• Fronthaul to the Radio Unit (DPDK, <10μs latency)
• Backhaul to the Central Unit (SR-IOV, 10–50μs latency)
• Legacy OAM connectivity (MacVLAN)

This requires multiple network interfaces per pod with different performance characteristics. The solution: Multus CNI — a meta-CNI that attaches multiple network interfaces to a single pod.

Network Interface Stack

                    Application Pod
                         │
             Multiple Network Interfaces
                         │
    ┌──────────┬──────────┬──────────┬──────────┐
    │          │          │          │          │
  eth0       net1       net2       net3       net4
  Calico    MacVLAN   SR-IOV     SR-IOV      DPDK
  (CNI)               Netdev     Netdev    vfio-pci
    │          │          │          │          │
    └──────────┴──────────┴──────────┴──────────┘
                Physical Network Interfaces
    em1         p2p1              p3p1 (Intel E810)
    Management  MacVLAN           SR-IOV Capable NIC
    + Calico    Bridge            SMC 0-7:  SR-IOV netdev
                                  SMC 8-15: DPDK vfio-pci

The Four Network Tiers

Tier 1: Management / Calico (eth0)

Standard Kubernetes cluster networking using Calico with VXLAN/IPIP encapsulation. All cluster-internal traffic — pod-to-pod, DNS, API server — flows through this interface.

• Interface: em1 (physical), eth0 (pod)
• Network: 192.168.41.0/27 (node management)
• Pod CIDR: 10.42.0.0/16
• Latency: ~1ms (acceptable for control plane)

Tier 2: MacVLAN — Legacy Workloads (net3)

MacVLAN in bridge mode provides Layer 2 connectivity for legacy VNFs that expect to sit directly on a physical network segment. No encapsulation overhead.

• Interface: p2p1 (physical)
• IP Range: 192.168.41.48/28
• IPv6: fd00:1:a:532::/64
• Use case: Legacy VNFs, OAM functions
• Latency: ~100μs

Tier 3: SR-IOV Netdevice — Kernel Data Plane (net1/net2)

SR-IOV (Single Root I/O Virtualization) exposes virtual functions (SMC's) of the Intel E810 NIC directly to pods via the kernel driver. The NIC handles packet steering in hardware, eliminating softirq overhead.

p3p1 (Intel E810 Physical Function)
├── SMC 0-7: netdevice driver
│   └── SR-IOV CNI
│   └── VLAN 538: 192.168.27.128/27
│   └── Use case: 5G DU L2, high-throughput CNF
│
└── SMC 8-15: vfio-pci driver
    └── DPDK CNI (userspace)
    └── VLAN 539: 192.168.27.160/27
    └── Use case: 5G DU L1, DPDK applications

• Throughput: ~50–100 Gbps
• Latency: 10–50μs
• CPU overhead: Low (hardware NIC queue management)

Tier 4: DPDK — Userspace Data Plane (net4)

DPDK (Data Plane Development Kit) bypasses the Linux kernel network stack entirely. Poll Mode Drivers (PMDs) run in userspace, pinned to isolated CPU cores, processing packets via zero-copy DMA.

External 5G RAN (VLAN 539)
    │
    ▼
p3p1 Physical Function (Intel E810)
    │
    └── SMC 8-15 (vfio-pci driver)
         │
    DPDK CNI (userspace)
    VLAN 539: 192.168.27.160/27
         │
    Pod (net4 - DPDK PMD)
    Zero-copy packet processing
    CPU: Pinned to isolated cores (1-30, 33-62)

Hardware Acceleration: Intel FEC

Beyond raw packet throughput, 5G PHY processing requires Forward Error Correction (FEC) — specifically LDPC and Turbo encoding/decoding. The Intel ACC200/VRB1 PCIe accelerator offloads this from the CPU entirely:

• PCI device: 0000:f7:00.0
• SMC's created: 16 (by fec-vf-creation.service at boot)
• Kubernetes resource: intel.com/intel_fec_acc200: "2"

Packet Path Selection by Workload

Kubernetes Network Configuration

Network Attachment Definitions (NADs) define the available secondary networks. The SR-IOV operator manages SMC allocation and binding. Multus reads the pod annotation to attach the right interfaces:

# Pod annotation requesting DPDK interface
annotations:
  k8s.v1.cni.cncf.io/networks: suse-dpdk

# Resource request for DPDK SMC
resources:
  limits:
    rancher.io/dpdk: "1"
    hugepages-1Gi: 2Gi
    memory: 2Gi

Network Sysctl Tuning

Kernel buffer sizes are set aggressively to handle burst traffic at 10Gb+ rates:

The combination of hardware SR-IOV, DPDK userspace processing, and kernel tuning gives this platform the network performance profile required for production 5G vRAN deployment.