---
title: "Red Hat OpenShift networking: Default OVN-Kubernetes vs. Cilium operator"
description: "The article compares Red Hat OpenShift’s default OVN-Kubernetes CNI with the Cilium operator for teams managing microservices, AI workloads, and declarative multi-cluster infrastructure with Cluster API (CAPI). It describes OVN-Kubernetes as natively managed by the OpenShift Cluster Network Operator, with Open vSwitch foundations, hardware offloading, Multus and OpenShift Virtualization compatibility, and OVN Interconnect for large-scale deployments. Cilium uses kernel-level eBPF programs and offers identity-based policies, sidecarless service mesh capabilities, and Hubble Layer 7 observability, while CAPI manifests and MachineSets support declarative worker-node provisioning. The source recommends Cilium for new clusters when eBPF capabilities and CAPI integration justify added operational complexity, while positioning OVN-Kubernetes as the simpler choice for integrated lifecycle management and hardware acceleration."
---

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

[Red Hat](https://yomu.fyi/company/red-hat) · Amjed Jabari (AJ), Wuxin Zeng, Rodrigo Gonzalez · Sep 18, 2026

**Type:** Explainer

## Summary

The article compares Red Hat OpenShift’s default OVN-Kubernetes CNI with the Cilium operator for teams managing microservices, AI workloads, and declarative multi-cluster infrastructure with Cluster API (CAPI). It describes OVN-Kubernetes as natively managed by the OpenShift Cluster Network Operator, with Open vSwitch foundations, hardware offloading, Multus and OpenShift Virtualization compatibility, and OVN Interconnect for large-scale deployments. Cilium uses kernel-level eBPF programs and offers identity-based policies, sidecarless service mesh capabilities, and Hubble Layer 7 observability, while CAPI manifests and MachineSets support declarative worker-node provisioning. The source recommends Cilium for new clusters when eBPF capabilities and CAPI integration justify added operational complexity, while positioning OVN-Kubernetes as the simpler choice for integrated lifecycle management and hardware acceleration.

## Context

The decision is framed around operational maturity, performance targets, security and observability requirements, infrastructure automation, and the desired degree of single-vendor lifecycle management. OVN-Kubernetes emphasizes native OpenShift integration and hardware acceleration, while Cilium emphasizes eBPF capabilities, Hubble observability, identity-aware policy, and CAPI-oriented workflows.

## Approach / What changed

The article compares install-config.yaml and CAPI provisioning examples, then contrasts OVN-Kubernetes and Cilium across lifecycle management, performance, observability, security, hardware offloading, and ecosystem compatibility. It also distinguishes Day-1 Cilium installation from disruptive Day-2 migration and notes configuration considerations for Multus and OpenShift Virtualization.

## Takeaways

- OVN-Kubernetes is managed by the OpenShift Cluster Network Operator and integrates with OpenShift upgrades, Multus, OpenShift Virtualization, Egress IPs, and Egress Firewalls.
- Cilium uses eBPF for kernel-level networking and adds identity-based policies, sidecarless service-mesh capabilities, and Hubble metrics and Layer 7 observability.
- The source recommends installing Cilium when creating a new cluster rather than migrating an existing production cluster, because in-place CNI migration can require maintenance or node reprovisioning.

## FAQ

### Why might a platform choose Cilium over OVN-Kubernetes?

Cilium is presented as a fit for platforms requiring eBPF-driven performance, deep Layer 7 observability, identity- and API-aware policies, or declarative multi-cluster management with CAPI. Hubble provides real-time service dependency maps and related metrics.

### Is migrating an existing OpenShift cluster to Cilium straightforward?

No. The source describes live migration as non-trivial and disruptive because it can require re-keying pod interfaces, updating iptables and OVS rules, and restarting node network daemons. Scheduled maintenance or rolling node reprovisioning may be needed.

### What must be checked when using Multus or OpenShift Virtualization?

The Cilium configuration must preserve Multus delegation when workloads use multiple pod interfaces or OpenShift Virtualization. Routing policies need careful mapping so the primary CNI does not interfere with secondary interfaces.

**Tags:** [Cilium](https://yomu.fyi/topic/cilium), [Cluster API](https://yomu.fyi/topic/cluster-api), [eBPF](https://yomu.fyi/topic/ebpf), [Kubernetes](https://yomu.fyi/topic/kubernetes), [OpenShift](https://yomu.fyi/topic/openshift)

- Source: [Red Hat](https://developers.redhat.com/articles/2026/09/18/openshift-networking-default-ovn-kubernetes-vs-cilium-operator)
- Source URL: https://developers.redhat.com/articles/2026/09/18/openshift-networking-default-ovn-kubernetes-vs-cilium-operator
- Ingested by Yomu: 2026-09-18T15:00:16.470Z

[Read original post](https://developers.redhat.com/articles/2026/09/18/openshift-networking-default-ovn-kubernetes-vs-cilium-operator)