Red Hat OpenShift networking: Default OVN-Kubernetes vs. Cilium operator

Cilium vs. OVN-Kubernetes: Choosing the right CNI for Red Hat OpenShift

September 18, 2026
Amjed Jabari (AJ) Wuxin Zeng Rodrigo Gonzalez
Related topics:
Observability
Related products:
Red Hat OpenShift Virtualization

As platform engineering teams scale their Red Hat OpenShift environments to support microservices, AI workloads, and declarative multi-cluster management with Cluster API (CAPI), decisions around Container Network Interface (CNI) architecture carry far-reaching consequences. In modern enterprise Kubernetes, networking is the foundation of your cluster's security posture, application performance, and operational visibility. As such, a critical architectural debate amongst platform leaders has arisen: Is Red Hat OpenShift's default OVN-Kubernetes CNI enough, or does your platform justify the operational shift to Cilium—especially in a Cluster API-driven infrastructure?

By default, Red Hat OpenShift ships with OVN-Kubernetes (Open Virtual Network), a mature, highly scalable CNI integrated into the platform's lifecycle management. OVN-Kubernetes offers robust performance, built-in multi-tenancy, and native support for hardware offloading. However, as eBPF has swept through the cloud-native ecosystem, many platform teams are looking closely at the Cilium operator. Cilium replaces traditional packet-switched networking with kernel-level eBPF programs, unlocking advanced features like identity-based security policies, sidecarless service mesh capabilities, real-time Layer 7 observability through Hubble, and seamless integration into declarative CAPI workflows.

In this article, we explore the underlying technology of both options, evaluate their architectural advantages with practical YAML snippets, and provide a clear framework to help you choose the right CNI for your OpenShift strategy.

What is CAPI and why does it matter here?

Cluster API (CAPI) is a Kubernetes subproject that brings declarative, GitOps-driven infrastructure management to Kubernetes clusters. Instead of provisioning clusters through manual scripts or traditional installer workflows, CAPI allows platform engineering teams to treat entire clusters—and their worker node pools—as custom Kubernetes resources (Cluster, MachineSet, Machine).

In an enterprise Red Hat OpenShift context (often powered by the cluster-capi-operator or hosted control planes with HyperShift), CAPI enables you to:

  • Automate infrastructure lifecycle: Declaratively scale, upgrade, or re-provision worker node pools across cloud providers (AWS, Azure, GCP) or bare-metal environments using standard kubectl or GitOps workflows.
  • Streamline multi-cluster operations: Deploy and manage dozens of workload clusters from a single central management control plane.
  • Integrate CNI bootstrapping: Dynamically attach networking drivers (like eBPF programs or virtual switch rules) during the automated ignition process whenever CAPI provisions new worker nodes.

Understanding CAPI is critical when evaluating CNIs because your CNI must integrate seamlessly into this automated node lifecycle—ensuring that as CAPI scales worker nodes up or down, networking, eBPF probes, and security policies attach instantly without manual intervention.

Provisioning comparison: install-config.yaml and CAPI manifests

Setting up the network provider on OpenShift starts at cluster creation—either inside the traditional install-config.yaml file or with declarative CAPI manifests.

OVN-Kubernetes in install-config.yaml

By default, standard OpenShift installer-provisioned infrastructure (IPI) populates the networking configuration using OVNKubernetes:

apiVersion: v1
baseDomain: example.com
metadata:
  name: ocp-production
networking:
  clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
  machineNetwork:
    - cidr: 10.0.0.0/16
  networkType: OVNKubernetes # Default OpenShift CNI
  serviceNetwork:
    - 172.30.0.0/16

Provisioning Cilium using install-config.yaml

When installing an OpenShift cluster with Cilium using the Isovalent/Cilium OLM manifests, you explicitly specify Cilium as the network type during initial cluster manifests generation:

apiVersion: v1
baseDomain: example.com
metadata:
  name: ocp-production
networking:
  clusterNetwork:
    - cidr: 10.128.0.0/14
      hostPrefix: 23
  machineNetwork:
    - cidr: 10.0.0.0/16
  networkType: Cilium # Custom eBPF CNI
  serviceNetwork:
    - 172.30.0.0/16

Declarative provisioning with CAPI

When using Cluster API (CAPI)—either with OpenShift's native cluster-capi-operator or hosted control planes (HyperShift)—the network infrastructure is declared within the CAPI cluster resource, delegating the pod data plane to Cilium while CAPI handles infrastructure automation:

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: ocp-capi-cilium-cluster
  namespace: capi-clusters
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 10.128.0.0/14
    services:
      cidrBlocks:
        - 172.30.0.0/16
    serviceDomain: cluster.local
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSCluster # Or VSphereCluster / GCPCluster
    name: ocp-capi-cilium-cluster
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: OpenShiftControlPlane
    name: ocp-capi-cilium-control-plane

When CAPI scales out worker nodes dynamically, a MachineSet handles the node creation, and Cilium eBPF agent pods automatically attach to newly bootstrapped Red Hat Enterprise Linux CoreOS nodes:

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineSet
metadata:
  name: ocp-capi-cilium-worker-us-east-1a
  namespace: capi-clusters
spec:
  clusterName: ocp-capi-cilium-cluster
  replicas: 5
  selector:
    matchLabels:
      cluster.x-k8s.io/cluster-name: ocp-capi-cilium-cluster
      node-role.kubernetes.io/worker: ""
  template:
    metadata:
      labels:
        cluster.x-k8s.io/cluster-name: ocp-capi-cilium-cluster
        node-role.kubernetes.io/worker: ""
    spec:
      clusterName: ocp-capi-cilium-cluster
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: OpenShiftWorkerConfig
          name: ocp-worker-bootstrap
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachineTemplate
        name: ocp-worker-aws-template

OVN-Kubernetes strengths and benefits

OVN-Kubernetes is the standard CNI for Red Hat OpenShift, designed as an open, community-driven framework built on top of Open vSwitch (OVS).

First-party support and integration

  • Managed natively by the OpenShift Cluster Network Operator (CNO). Zero third-party lifecycle management overhead.
  • Upgrades occur seamlessly alongside OpenShift version updates without version skew, breaking API changes, or custom operator management.

Hardware offloading (SmartNICs and DPUs)

  • Built on Open vSwitch (OVS), allowing packet processing to be pushed directly down to SmartNICs or Data Processing Units (DPUs) like NVIDIA BlueField.
  • Bypasses host CPU entirely for established network flows, delivering near-wire-speed packet processing and freeing CPU cores for actual workloads.

Deep ecosystem compatibility

  • Natively compatible with OpenShift features out of the box, including Multus CNI, OpenShift Virtualization (KubeVirt), Egress IPs, and Egress Firewalls.

Large-scale distributed architecture

  • Utilizes OVN Interconnect mode to isolate node-level database failures and scale reliably across thousands of nodes in massive enterprise clusters.

Cilium operator (eBPF) strengths and benefits

Cilium takes a fundamentally different path by leveraging eBPF in the Linux kernel. Instead of routing packets through virtual bridges and complex switch tables, Cilium injects sandboxed eBPF bytecode directly into kernel hook points.

Platform engineers configure Cilium's eBPF engine using a custom resource called CiliumConfig:

apiVersion: cilium.io/v1alpha1
kind: CiliumConfig
metadata:
  name: cilium
  namespace: cilium
spec:
  # Enable eBPF Host Routing to bypass iptables/host stack
  bpf-lb-external-cluster-ip: true
  enable-bpf-masquerade: true
  
  # Enable Hubble Observability & L7 Monitoring
  hubble:
    enabled: true
    ui:
      enabled: true
    metrics:
      enabled:
        - dns
        - drop
        - tcp
        - flow
        - icmp
        - http

eBPF kernel performance and lower latency

Bypasses host TCP/IP stack overhead with sockmap short-circuiting, yielding faster pod-to-pod throughput and reduced CPU utilization during heavy network activity.

Deep Observability with Hubble

  • Unlocks real-time flow visibility with the Hubble UI and CLI.
  • Captures flow-level logs, HTTP/gRPC methods, DNS requests, and latency metrics natively without sidecar proxies.

Identity-aware and Layer 7 security policies

  • Enforces security based on dynamic cryptographic identities rather than static IP blocks or CIDR ranges.
  • Supports granular L7 filtering (for example, allowing GET /api/v1/health while blocking POST /api/v1/admin).

Cilium Cluster Mesh and sidecarless service mesh

  • Cluster Mesh connects multi-cluster OpenShift topologies across hybrid clouds with unified load balancing and cross-cluster security policies.
  • Provides native Gateway API routing, mTLS, and ingress capabilities without needing resource-heavy sidecar proxies injected into every pod.

Policy comparison: Standard NetworkPolicy vs. CiliumNetworkPolicy

The functional differences between OVN-Kubernetes and Cilium are clearest when reviewing security policies.

Standard L3/L4 NetworkPolicy (OVN-Kubernetes)

OVN-Kubernetes relies on standard Kubernetes NetworkPolicy objects. You can restrict access based on pod labels, namespaces, and TCP/UDP ports:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-frontend-to-backend
  namespace: payment-system
spec:
  podSelector:
    matchLabels:
      app: backend-api
  policyTypes:
    - Ingress
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: frontend
      ports:
        - protocol: TCP
          port: 8080

Layer 7 identity and FQDN policy (CiliumNetworkPolicy)

Cilium extends capabilities to Layer 7 application rules and dynamic DNS/FQDN filtering. In this example, traffic is restricted not just to port 8080, but specifically to GET calls targeting /api/v1/health, while egress is limited to specified external domains:

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: l7-identity-and-fqdn-policy
  namespace: payment-system
spec:
  endpointSelector:
    matchLabels:
      app: backend-api
  ingress:
    - fromEndpoints:
        - matchLabels:
            app: frontend
      toPorts:
        - ports:
            - port: '8080'
              protocol: TCP
          rules:
            http:
              - method: "GET"
                path: "/api/v1/health"
  egress:
    - toFQDNs:
        - matchName: "api.stripe.com"
      toPorts:
        - ports:
            - port: '443'
              protocol: TCP

Head-to-head comparison

To understand where each CNI excels, we need to compare them across the core operational pillars of modern enterprise platforms: Core architecture, day-1 installation, hardware efficiency, observability, and long-term supportability.

Core technology

  • Default OVN-Kubernetes: Open vSwitch (OVS) and Open Virtual Network (OVN)
  • Cilium operator (eBPF): Linux Kernel eBPF (sockmap, XDP)

Operational Day-1 setup

  • Default OVN-Kubernetes: Zero setup. Natively managed by the OpenShift Cluster Network operator (CNO).
  • Cilium operator (eBPF): Custom setup. Requires Cilium OLM operator, custom CRDs, and explicit Security Context Constraints (SCC) privileges.

Hardware offloading

  • Default OVN-Kubernetes: Native SmartNIC / DPU Offload. Can completely bypass host CPU for OVS flows (for example, NVIDIA BlueField).
  • Cilium operator (eBPF): In-kernel acceleration. Reduces host TCP/IP stack overhead with eBPF. Offloading is limited compared to OVS DPUs.

Observability

  • Default OVN-Kubernetes: Standard Prometheus metrics, OpenShift Console dashboards, and Open vSwitch flow logs.
  • Cilium operator (eBPF): Hubble UI and CLI. Native L3–L7 real-time flow visibility, service dependency maps, and HTTP/gRPC tracing out of the box.

Network policy granularity

  • Default OVN-Kubernetes: L3/L4 (IP, Port, Protocol) plus OpenShift Egress Firewalls.
  • Cilium operator (eBPF): Identity and L7-aware. Cryptographic identity matching, HTTP verb filtering, and FQDN/DNS-based rules.

Multi-cluster connectivity

  • Default OVN-Kubernetes: OVN Interconnect or Submariner integration.
  • Cilium operator (eBPF): Cilium Cluster Mesh. Native multi-cluster pod-to-pod routing, global service load balancing, and cross-cluster policies.

Support and upgrades

  • Default OVN-Kubernetes: 100% Red Hat Supported. Upgrades automatically alongside OpenShift release cycles.
  • Cilium operator (eBPF): Vendor-backed, supported with Isovalent (in the Red Hat Certified Operator catalog).

Architectural deep-dive: OVS vs. eBPF

The true distinction between these 2 options lies in where and how network packets are processed inside the host.

  • OVN-Kubernetes relies on Open vSwitch (OVS), an enterprise-grade virtual switch running on each node. When a packet hits an OVN-Kubernetes node, OVS processes it through programmed flow tables. Because OVS was designed from the ground up to mimic hardware switches, it excels at offloading networking tasks directly to SmartNICs and DPUs. For bare-metal environments or high-throughput telco workloads, bypassing the CPU altogether for established packet flows yields near-line-rate performance.
  • Cilium bypasses traditional Linux networking constructs (like iptables or virtual switches) using eBPF. This allows mini-programs to run directly inside the Linux kernel on specific hook points. When pod A talks to pod B on the same node, Cilium can use sockmap to short-circuit the socket layer, essentially copying data directly from one socket buffer to another without ever passing through the host TCP/IP stack. Furthermore, because eBPF sits at the kernel boundary, Cilium inspects Layer 7 application contexts (such as raw HTTP/gRPC headers) with dramatically lower CPU overhead than running a traditional sidecar proxy.

Selection criteria: When to choose which?

Choosing between OVN-Kubernetes and Cilium isn't about finding the "better" CNI in absolute terms. Instead, you must align your network architecture with your operational capabilities, security compliance needs, and infrastructure hardware.

Which CNI fits your OpenShift strategy?

The default OVN-Kubernetes features:

  • 100% single-vendor support (Red Hat)
  • Hardware offload (SmartNICs / DPUs )
  • Seamless, unattended cluster upgrades
  • Zero platform engineering overhead

When choosing the Cilium operator:

  • Deep L7 / API-level security
  • Rich observability (Hubble UI)
  • Native multi-cluster mesh
  • Sidecarless service mesh goals

Choosing default OVN-Kubernetes

You might choose the default OVN-Kubernetes when:

  • You want out of the box, zero-maintenance day-2 operational experience. If your platform team wants networking to "just work" without managing custom subscriptions, operator lifecycles, or security context configurations, stick with OVN-K. Cluster upgrades update the CNI seamlessly in lockstep with the core platform.
  • Your infrastructure leverages SmartNICs or Data Processing Units (DPUs). If you run bare-metal OpenShift on nodes equipped with acceleration hardware (such as NVIDIA BlueField), OVN-Kubernetes is hard to beat. Its OVS integration allows you to offload packet processing entirely, saving precious CPU cores for running actual workload pods.
  • Your organization requires strict single-vendor support. Certain highly regulated industries demand a single SLA and accountability path. OVN-Kubernetes is a first-party Red Hat component covered under your core OpenShift subscription.
  • Standard L3/L4 NetworkPolicies fit your security baseline. If your security policies primarily dictate that namespace A cannot talk to namespace B on port 443, then OVN-Kubernetes provides all the policy enforcement and egress control you need without additional complexity.

Choosing the Cilium operator

You might choose the Cilium operator when:

  • You need deep, zero-code microservice observability (Hubble). For developers or SREs struggling to answer whether a problem is an application bug or a network timeout, Cilium's Hubble provides instant, flow-level metrics, latency breakdowns, and real-time dependency maps across L3 through L7.
  • Your security architecture demands identity and API-level access controls. If you must enforce policies allowing, for example, a pod to execute GET /health, but never DELETE /database, or if you need to restrict egress traffic based on dynamic FQDNs (for example, *.aws.amazon.com) rather than brittle IP blocks, then you'll find Cilium's identity-aware policy engine purpose-built for the task.
  • You operate declarative multi-cluster environments using CAPI. If you provision OpenShift clusters dynamically using CAPI or hosted control planes with HyperShift, Cilium seamlessly hooks into the node Ignition bootstrap process, allowing worker node scale-outs to initialize eBPF networking automatically.
  • You are building a multi-region, multi-cluster topology. If you operate multiple OpenShift clusters across different cloud providers or data centers, Cilium Cluster Mesh provides seamless pod-to-pod routing, global service discovery, and unified policy enforcement across cluster boundaries without complex gateway proxies.
  • You want to modernize toward a sidecarless service mesh. If you want features like mutual TLS (mTLS), traffic splitting, or ingress routing using the Gateway API without injecting resource-heavy sidecar proxies into every pod, Cilium's eBPF architecture allows you to offload these functions directly to the kernel level.

Practical implementation and migration notes

While the performance and observability benefits of Cilium are compelling, introducing a third-party CNI into a Red Hat enterprise ecosystem requires deliberate planning around Day-2 operations, security privileges, and platform lifecycles.

Privilege and Security Context Constraints (SCCs)

Unlike standard Kubernetes distributions, Red Hat Enterprise Linux CoreOS enforces strict security controls out of the box. Cilium relies heavily on eBPF, requiring access to kernel probe points, system calls, and network interfaces.

Installing Cilium on RHCOS requires granting its daemonsets privileged Security Context Constraints (SCCs) (such as privileged or customized host-network SCCs).

Here's an example snippet of the required SCC definition to allow Cilium host networking:

apiVersion: security.openshift.io/v1
kind: SecurityContextConstraints
metadata:
  name: cilium-host-network
allowHostPorts: true
allowHostNetwork: true
allowPrivilegedContainer: true
readOnlyRootFilesystem: false
runAsUser:
  type: RunAsAny
seLinuxContext:
  type: RunAsAny
users:
  - system:serviceaccount:cilium:cilium

Deployment method: The OLM and Certified operators

Red Hat and Isovalent (part of Cisco) provide a Cilium Certified operator available through the OpenShift Operator Lifecycle Manager.

  • Always deploy Cilium through the certified OLM operator rather than raw Helm charts. This ensures that custom resource definitions (CRDs) and cluster-level components align with OpenShift's strict RBAC and update pipelines.
  • Verify the support matrix between your target OpenShift version (for example, OpenShift 4.x) and the corresponding Cilium release to maintain enterprise support compliance.

Integration with CAPI and hosted control planes (HyperShift)

If your OpenShift clusters are deployed and scaled declaratively using CAPI or hosted control planes (HyperShift):

  • Decoupled lifecycle: Cilium runs on CAPI-managed workload nodes while the OpenShift control plane can be offloaded to a central management cluster.
  • Automated node scale-out: As CAPI MachineSets automatically scale worker nodes up or down based on load, Cilium's DaemonSet and eBPF kernel hooks automatically attach to newly provisioned Red Hat Enterprise Linux CoreOS instances during initial Ignition bootstrap.
  • Certified compatibility: Isovalent Cilium for OpenShift is certified for hosted control plane environments, making it a natural fit for declarative, multi-tenant CAPI topologies.

Day-1 installation vs. Day-2 migration

  • New clusters (Day-1): Installing Cilium during initial cluster provisioning using OpenShift's install-config.yaml or CAPI manifests (by specifying networkType: Cilium with the operator) is the recommended and cleanest path.
  • Existing clusters (Day-2 migration): Migrating a live, production OpenShift cluster from OVN-Kubernetes to Cilium is a non-trivial, disruptive task. Because CNI migration requires re-keying pod interfaces, updating IPTables/OVS rules, and restarting node network daemons, it typically involves scheduled maintenance windows or a rolling node-reprovisioning strategy. For most enterprise environments, building a new cluster and shifting traffic with ingress/DNS is significantly safer than in-place CNI migration.

Co-existence with Multus and Red Hat OpenShift Virtualization

If your workloads rely on Multus CNI for multi-interface pods (common in telco and high-performance computing) or Red Hat OpenShift Virtualization (KubeVirt) to run virtual machines alongside containers, ensure your Cilium configuration explicitly preserves Multus delegation. Both CNIs support Multus as a meta-plugin, but routing policies must be mapped carefully to avoid stepping on secondary interfaces.

Conclusion: Balancing simplicity and capability

Choosing between OpenShift's default OVN-Kubernetes and the Cilium operator isn't about deciding which tool is objectively superior—it's about matching your network substrate to your organization's operational maturity, performance targets, and infrastructure provisioning models.

  • Stick with OVN-Kubernetes if your operational north star is simplicity, hardware acceleration, and single-vendor accountability. For organizations running standard microservices, bare-metal hardware with SmartNICs, or teams that want zero CNI maintenance overhead during cluster upgrades, Red Hat's default engine delivers an enterprise-ready, rock-solid foundation out of the box.
  • Adopt Cilium operator if your platform strategy requires eBPF-driven performance, deep L7 observability, and declarative multi-cluster CAPI management. If your developers need Hubble's real-time service dependency maps, your security team demands identity- and API-aware policies, or your architecture spans multiple hybrid clusters managed with CAPI, the capability boost provided by Cilium more than offsets the added operational complexity.

Ultimately, CNI selection should serve your broader platform goals. By carefully weighing OVN-Kubernetes' reliability against Cilium's eBPF-powered capabilities, you can build an OpenShift networking architecture that supports both your infrastructure today and your application growth tomorrow.

Resources