Skip to content

ovn

When Hardware Offload Goes Silent: The Case of the Orphaned TC Flowers

In large-scale cloud infrastructure, few things sound as compelling on paper as hardware offloading. When you are running Genestack—powering enterprise OpenStack clouds orchestrated on top of Kubernetes with Kube-OVN and Open vSwitch (OVS)—encapsulating Geneve overlay traffic and tracking connection state can consume measurable CPU cycles across a busy fleet. Offloading those flow tables and match-action rules directly into the physical NIC silicon is the holy grail: line-rate throughput, near-zero CPU overhead, and microsecond packet handling.

Until your network cards decide they cannot actually handle it.

Octavia OVN Overview

Octavia provides the ability to utilize OVN(Open Virtual Networking) as a provider driver to deploy layer 4 loadbalancing. While Octavia OVN loadbalancers may not be as feature rich as Amphora based loadbalancing OVN based loadbalancers provide a resource efficient, fast deploying and highly availble loadbalancing solution. View the Amphora and OVN loadbalancing comparison matrix for more info about which features are supported.

For additional information regarding Octavia OVN loadbalancers view the Octavia OVN Docs.

  • in ovn
  • 7 min read

Repairing pod communication problems with the join network

While converting a production region to Kube-OVN managed by Helm chart from its original kubespray installation as detailed in the Genestack doc docs/k8s-cni-kube-ovn-helm-conversion.md, we encountered an issue with some of the kube-ovn-cni pods when they restarted with an inability to communicate with the join network, and crash looping or pending pod states. We found that a reboot of the pod's node generally solved this problem, but also discovered a method that could repair connectivity with the join network without rebooting the node.