In OpenShift Container Platform (OCP), OVN refers to Open Virtual Network, used via OVN-Kubernetes. It’s the default networking solution in modern OpenShift clusters.

What OVN is (in simple terms)

OVN is a software-defined networking (SDN) system that:

• Creates virtual networks for pods
• Handles routing, switching, and network policies
• Replaces older OpenShift SDN implementations

Think of it as the “network brain” of your cluster.

How OVN works in OCP

Core components

• OVN Northbound DB → stores high-level network config
• OVN Southbound DB → translates config to actual rules
• OVN Controller (on each node) → programs networking rules
• Open vSwitch (OVS) → does the actual packet forwarding

What it actually does

1. Pod networking

Each pod gets:

• Its own IP address
• Ability to talk to other pods across nodes

2. Routing

Handles:

• Pod-to-pod communication
• Pod-to-service traffic
• External access (ingress/egress)

3. Network policies

Controls traffic like:

• “Only allow frontend → backend”
• “Block everything except specific ports”

4. Load balancing

Implements Kubernetes Services internally

Traffic flow (simplified)

1. Pod sends traffic
2. Goes through Open vSwitch (OVS) on the node
3. OVN rules decide:
   • Where it goes
   • Whether it’s allowed
4. Traffic reaches destination pod/service

Why OCP uses OVN

Compared to older SDN:

• Better performance and scalability
• Native support for Kubernetes NetworkPolicy
• More flexible routing and IP management
• Cleaner architecture (decoupled control + data plane)

OVN vs OpenShift SDN

Key concepts to remember

• OVN = control plane for networking
• OVS = data plane (moves packets)
• Pods communicate via virtual networking managed by OVN
• Policies are enforced at the network layer

Real-world example

If you deploy:

• frontend pod
• backend pod

With OVN:

• Both get IPs
• OVN ensures routing between them
• A NetworkPolicy can allow only frontend → backend traffic

Debugging OVN in OpenShift Container Platform (via OVN-Kubernetes) can feel overwhelming at first, but there’s a clear, structured way to approach it.

Below is a practical, field-tested workflow you can follow.

0. Start with the symptom

Before touching OVN internals, identify the issue type:

• ❌ Pod can’t reach another pod
• ❌ Pod can’t reach a service
• ❌ External traffic not working
• ❌ DNS failing
• ❌ Only some nodes affected

This helps narrow the scope fast.

1. Check cluster networking health

oc get co network

• Should be Available=True
• If Degraded → OVN problem likely

2. Check OVN pods

oc get pods -n openshift-ovn-kubernetes

Look for:

• CrashLoopBackOff
• NotReady pods

Key pods:

• ovnkube-node (runs on every node)
• ovnkube-master

3. Check logs (most important step)

Node-level (data plane issues)

oc logs -n openshift-ovn-kubernetes <ovnkube-node-pod>

Control plane

oc logs -n openshift-ovn-kubernetes <ovnkube-master-pod>

Look for:

• Flow programming errors
• DB connection failures
• OVS issues

4. Validate pod networking

Get pod IPs:

oc get pods -o wide

Test connectivity:

oc exec -it <pod> -- ping <other-pod-ip>

If this fails:

• Likely OVN routing or policy issue

5. Check NetworkPolicies

oc get networkpolicy -A

Common mistake:

• Policy blocking traffic unintentionally

Test by temporarily removing policy or creating an allow-all:

kind: NetworkPolicy
spec:
  podSelector: {}
  ingress:
  - {}
  egress:
  - {}

6. Check Open vSwitch (OVS)

SSH into a node:

oc debug node/<node-name>
chroot /host

Then:

ovs-vsctl show

Look for:

• Bridges (like br-int)
• Missing interfaces = problem

7. Inspect OVN DB state

From master node:

ovn-nbctl show

Check:

• Logical switches
• Ports for pods

If missing → OVN not programming correctly

8. Check services & kube-proxy replacement

OVN replaces kube-proxy.

Check:

oc get svc

Test:

curl <service-cluster-ip>

If service fails but pod IP works:
→ Load balancing issue in OVN

9. Check egress / external connectivity

From pod:

curl google.com

If fails:

• Check EgressFirewall / EgressIP
• Check node routing

10. Use must-gather (for deep issues)

oc adm must-gather -- /usr/bin/gather_network_logs

This collects:

• OVN DB state
• OVS config
• Logs

Common real-world issues

1. MTU mismatch

Symptoms:

• Intermittent connectivity
• Large packets fail

2. NetworkPolicy blocking traffic

Very common in production

3. OVN DB not syncing

Symptoms:

• Pods exist but no routes

4. Node-specific issues

• Only pods on one node fail → check that node’s ovnkube-node

5. DNS issues (often misdiagnosed as OVN)

Check:

oc get pods -n openshift-dns

Debugging mindset (this is key)

Always go in this order:

1. Is cluster networking healthy?
2. Are OVN pods running?
3. Is traffic blocked (policy)?
4. Is routing broken (OVN/OVS)?
5. Is it actually DNS or app issue?

Pro tip

Use a debug pod:

oc run test --image=busybox -it --rm -- sh

From there:

• ping
• nslookup
• curl

This isolates networking from your app.