Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 1. About the OVN-Kubernetes network plugin

You can use the OVN-Kubernetes Network Interface to create and manage network connections for internet-connected nodes.

1.1. MicroShift default networking plugin
Copy link

The OVN-Kubernetes Container Network Interface (CNI) plugin is the default networking solution for a MicroShift node. OVN-Kubernetes is a virtualized network for pods and services that is based on Open Virtual Network (OVN).

  • Changing the CNI is not supported on MicroShift.
  • Default network configuration and connections are applied automatically in MicroShift with the microshift-networking RPM during installation.
  • A node that uses the OVN-Kubernetes network plugin also runs Open vSwitch (OVS) on the node.
  • OVN-K configures OVS on the node to implement the declared network configuration.
  • Host physical interfaces are not bound by default to the OVN-K gateway bridge, br-ex. You can use standard tools on the host for managing the default gateway, such as the Network Manager CLI (nmcli).

Using configuration files or custom scripts, you can configure the following networking settings:

  • You can use subnet CIDR ranges to allocate IP addresses to pods.
  • You can change the maximum transmission unit (MTU) value.
  • You can configure firewall ingress and egress.
  • You can define network policies in the MicroShift, including ingress and egress rules.
  • You can use the MicroShift Multus plugin to chain other CNI plugins.
  • You can configure or remove the ingress router.

1.2. MicroShift networking configuration matrix
Copy link

The following table summarizes the status of networking features and capabilities that are either present as defaults, supported for configuration, or not available with the MicroShift service:

Expand
Table 1.1. MicroShift networking features and capabilities overview
Network capabilityAvailabilityConfiguration supported

Advertise address

Yes

Yes

Kubernetes network policy

Yes

Yes

Kubernetes network policy logs

Not available

N/A

Load balancing

Yes

Yes

Multicast DNS

Yes

Yes

Network proxies

Yes

CRI-O

Network performance

Yes

MTU configuration

Egress IPs

Not available

N/A

Egress firewall

Not available

N/A

Egress router

Not available

N/A

Firewall

No

Yes

Hardware offloading

Not available

N/A

Hybrid networking

Not available

N/A

IPsec encryption for intra-cluster communication

Not available

N/A

IPv6

Not available

N/A

Ingress router

Yes

Yes

Multiple networks plugin

Yes

Yes

Additional details about networking capabilities
  • Advertise address: If unset, the default value is set to the next immediate subnet after the service network. For example, when the service network is 10.43.0.0/16, the advertiseAddress is set to 10.44.0.0/32.
  • Multicast DNS: You can use the multicast DNS protocol (mDNS) to allow name resolution and service discovery within a Local Area Network (LAN) using multicast exposed on the 5353/UDP port.
  • Network proxies: There is no built-in transparent proxying of egress traffic in MicroShift. Egress must be manually configured.
  • Firewall: Setting up the firewalld service is supported by RHEL for Edge.
  • Ingress router: Configure by using the MicroShift config.yaml file.

1.2.1. Default settings
Copy link

If you do not create a config.yaml file, default values are used. The following example shows the default configuration settings.

  • To see the default values, run the following command: 

    $ microshift show-config
    Copy to Clipboard Toggle word wrap

    Default values example output in YAML form

    apiServer:
  advertiseAddress: 10.44.0.0/32
    1 
    
  auditLog:
    maxFileAge: 0
    2 
    
    maxFileSize: 200
    3 
    
    maxFiles: 10
    4 
    
    profile: Default
    5 
    
  namedCertificates:
    - certPath: ""
      keyPath: ""
      names:
        - ""
  subjectAltNames: []
    6 
    
debugging:
  logLevel: "Normal"
    7 
    
dns:
  baseDomain: microshift.example.com
    8 
    
etcd:
  memoryLimitMB: 0
    9 
    
ingress:
  listenAddress:
    - ""
    10 
    
  ports:
    11 
    
    http: 80
    https: 443
  routeAdmissionPolicy:
    namespaceOwnership: InterNamespaceAllowed
    12 
    
  status: Managed
    13 
    
manifests:
    14 
    
  kustomizePaths:
    - /usr/lib/microshift/manifests
    - /usr/lib/microshift/manifests.d/*
    - /etc/microshift/manifests
    - /etc/microshift/manifests.d/*
network:
  clusterNetwork:
    - 10.42.0.0/16
    15 
    
  serviceNetwork:
    - 10.43.0.0/16
    16 
    
  serviceNodePortRange: 30000-32767
    17 
    
node:
  hostnameOverride: ""
    18 
    
  nodeIP: ""
    19
    Copy to Clipboard Toggle word wrap

    1
    A string that specifies the IP address from which the API server is advertised to members of the cluster. The default value is calculated based on the address of the service network.
    2
    How long log files are kept before automatic deletion. The default value of 0 in the maxFileAge parameter means a log file is never deleted based on age. This value can be configured.
    3
    By default, when the audit.log file reaches the maxFileSize limit, the audit.log file is rotated and MicroShift begins writing to a new audit.log file. This value can be configured.
    4
    The total number of log files kept. By default, MicroShift retains 10 log files. The oldest is deleted when an excess file is created. This value can be configured.
    5
    Logs only metadata for read and write requests; does not log request bodies except for OAuth access token requests. If you do not specify this field, the Default profile is used.
    6
    Subject Alternative Names for API server certificates.
    7
    Log verbosity. Valid values for this field are Normal, Debug, Trace, or TraceAll.
    8
    By default, etcd uses as much memory as needed to handle the load on the system. However, in memory constrained systems, it might be preferred or necessary to limit the amount of memory etcd can to use at a given time.
    9
    Base domain of the cluster. All managed DNS records are subdomains of this base.
    10
    The ingress.listenAddress value defaults to the entire network of the host. The valid configurable value is a list that can be either a single IP address or NIC name or multiple IP addresses and NIC names.
    11
    Default ports shown. Configurable. Valid values for both port entries are a single, unique port in the 1-65535 range. The values of the ports.http and ports.https fields cannot be the same.
    12
    Describes how hostname claims across namespaces are handled. By default, allows routes to claim different paths of the same hostname across namespaces. Valid values are Strict and InterNamespaceAllowed. Specifying Strict prevents routes in different namespaces from claiming the same hostname. If the value is deleted in a customized MicroShift config.yaml, the InterNamespaceAllowed value is automatically set.
    13
    Default router status, can be Managed or Removed.
    14
    The locations on the file system to scan for kustomization files to use to load manifests. Set to a list of paths to scan only those paths. Set to an empty list to disable loading manifests. The entries in the list can be glob patterns to match multiple subdirectories.
    15
    A block of IP addresses from which pod IP addresses are allocated. This field is immutable after installation.
    16
    A block of virtual IP addresses for Kubernetes services. IP address pool for services. A single entry is supported. This field is immutable after installation.
    17
    The port range allowed for Kubernetes services of type NodePort. If not specified, the default range of 30000-32767 is used. Services without a NodePort specified are automatically allocated one from this range. This parameter can be updated after the cluster is installed.
    18
    The name of the node. The default value is the hostname. If non-empty, this string is used to identify the node instead of the hostname. You cannot change this immutable setting after MicroShift starts for the first time.
    19
    The IP address of the node. The default value is the IP address of the default route.

1.3. Network features
Copy link

Understand which networking feature are available and which are not for your MicroShift deployments.

Networking features available with MicroShift 4.16 include:

  • Kubernetes network policy
  • Dynamic node IP
  • Custom gateway interface
  • Second gateway interface
  • Node network on specified host interface
  • Blocking external access to NodePort service on specific host interfaces

Networking features not available with MicroShift 4.16:

  • Egress IP/firewall/QoS: disabled
  • Hybrid networking: not supported
  • IPsec: not supported
  • Hardware offload: not supported

1.3.1. IP forward
Copy link

You must use ip_forward to access network connectivity.

The host network sysctl net.ipv4.ip_forward kernel parameter is automatically enabled by the ovnkube-master container when started. This is required to forward incoming traffic to the CNI. For example, accessing the NodePort service from outside of a node fails if ip_forward is disabled.

1.4. Network performance optimizations
Copy link

By default, three performance optimizations are applied to OVS services to minimize resource consumption:

  • CPU affinity to ovs-vswitchd.service and ovsdb-server.service
  • no-mlockall to openvswitch.service
  • Limit handler and revalidator threads to ovs-vswitchd.service

1.5. MicroShift networking components and services
Copy link

Understand networking components and services and their operation in MicroShift.

Note

The microshift-networking RPM is a package that automatically pulls in any networking-related dependencies and systemd services to initialize networking, for example, the microshift-ovs-init systemd service.

NetworkManager
NetworkManager is required to set up the initial gateway bridge on the MicroShift node. The NetworkManager and NetworkManager-ovs RPM packages are installed as dependencies to the microshift-networking RPM package, which contains the necessary configuration files. NetworkManager in MicroShift uses the keyfile plugin and is restarted after installation of the microshift-networking RPM package.
microshift-ovs-init
The microshift-ovs-init.service is installed by the microshift-networking RPM package as a dependent systemd service to microshift.service. It is responsible for setting up the OVS gateway bridge.
OVN containers

Two OVN-Kubernetes daemon sets are rendered and applied by MicroShift.

  • ovnkube-master Includes the northd, nbdb, sbdb and ovnkube-master containers.

  • ovnkube-node The ovnkube-node includes the OVN-Controller container.

    After MicroShift starts, the OVN-Kubernetes daemon sets are deployed in the openshift-ovn-kubernetes namespace.

Packaging

OVN-Kubernetes manifests and startup logic are built into MicroShift. The systemd services and configurations included in the microshift-networking RPM are:

  • /etc/NetworkManager/conf.d/microshift-nm.conf for NetworkManager.service
  • /etc/systemd/system/ovs-vswitchd.service.d/microshift-cpuaffinity.conf for ovs-vswitchd.service
  • /etc/systemd/system/ovsdb-server.service.d/microshift-cpuaffinity.conf for ovs-server.service
  • /usr/bin/configure-ovs-microshift.sh for microshift-ovs-init.service
  • /usr/bin/configure-ovs.sh for microshift-ovs-init.service
  • /etc/crio/crio.conf.d/microshift-ovn.conf for the CRI-O service

1.6. Bridge mappings
Copy link

Understand how provider network traffic reaches the physical network through bridge mappings. The following concepts apply:

  • Traffic leaves the provider network and arrives at the br-int bridge.
  • A patch port between br-int and br-ex then allows the traffic to traverse to and from the provider network and the edge network.
  • Kubernetes pods are connected to the br-int bridge through a virtual ethernet pair. One end of the virtual ethernet pair is attached to the pod namespace, and the other end is attached to the br-int bridge.

1.7. Network topology
Copy link

OVN-Kubernetes provides an overlay-based networking implementation. This overlay includes an OVS-based implementation of Service and NetworkPolicy resources.

The overlay network uses the Geneve (Generic Network Virtualization Encapsulation) tunnel protocol. The pod maximum transmission unit (MTU) for the Geneve tunnel is set to the default route MTU if it is not configured.

To configure the MTU, you must set an equal-to or less-than value than the MTU of the physical interface on the host. A less-than value for the MTU makes room for the required information that is added to the tunnel header before it is transmitted.

Important

The MTU value of the OVN overlay networking in MicroShift must be 100 bytes smaller than the MTU value of the base network. If no MTU value is configured, MicroShift autoconfigures the value using the MTU value of the default gateway (Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6)) of the host. If the auto-configuration does not work correctly, the MTU value can be configured manually. For example, if the MTU value of the network is 9000, the OVN MTU size must be set to 8900.

OVS runs as a systemd service on the MicroShift node. The OVS RPM package is installed as a dependency to the microshift-networking RPM package. OVS starts immediately when the microshift-networking RPM is installed.

Red Hat build of MicroShift network topology

317 RHbM OVN topology 0923

OVN node switch

A virtual switch named <node-name>. The OVN node switch is named according to the hostname of the node.

  • In this example, the node-name is microshift-dev.
OVN cluster router

A virtual router named ovn_cluster_router, also known as the distributed router.

  • In this example, the node network is 10.42.0.0/16.
OVN join switch
A virtual switch named join.
OVN gateway router
A virtual router named GR_<node-name>, also known as the external gateway router.
OVN external switch
A virtual switch named ext_<node-name>.
  • The north-south traffic between the network service and the OVN external switch ext_microshift-dev is provided through the host kernel by the gateway bridge br-ex.
  • The OVN gateway router GR_microshift-dev is connected to the external network switch ext_microshift-dev through the logical router port 4. Port 4 is attached with the node IP address 192.168.122.14.

  • The join switch join connects the OVN gateway router GR_microshift-dev to the OVN cluster router ovn_cluster_router. The IP address range is 100.62.0.0/16.

    • The OVN gateway router GR_microshift-dev connects to the OVN join switch join through the logical router port 3. Port 3 attaches with the internal IP address 100.64.0.2.
    • The OVN cluster router ovn_cluster_router connects to the join switch join through the logical router port 2. Port 2 attaches with the internal IP address 100.64.0.1.
  • The OVN cluster router ovn_cluster_router connects to the node switch microshift-dev through the logical router port 1. Port 1 is attached with the OVN cluster network IP address 10.42.0.1.
  • The east-west traffic between the pods and the network service is provided by the OVN cluster router ovn_cluster_router and the node switch microshift-dev. The IP address range is 10.42.0.0/24.
  • The east-west traffic between pods is provided by the node switch microshift-dev without network address translation (NAT).
  • The north-south traffic between the pods and the external network is provided by the OVN cluster router ovn_cluster_router and the host network. This router is connected through the ovn-kubernetes management port ovn-k8s-mp0, with the IP address 10.42.0.2.

  • All the pods are connected to the OVN node switch through their interfaces.

    • In this example, Pod 1 and Pod 2 are connected to the node switch through Interface 1 and Interface 2.

1.8. Additional resources
Copy link

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat