Red Hat Summit Red Hat SummitSupportConsoleDevelopersStart a trialContact

Chapter 8. Network requirements

Use this section to understand the different network considerations when planning deployments.

8.1. IPv6 support

Red Hat OpenShift Data Foundation version 4.12 introduced the support of IPv6. IPv6 is supported in single stack only, and cannot be used simultaneously with IPv4. IPv6 is the default behavior in OpenShift Data Foundation when IPv6 is turned on in Openshift Container Platform.

OpenShift Container Platform dual stack with Red Hat OpenShift Data Foundation IPv4 is supported from version 4.13 and later. Dual stack on Red Hat OpenShift Data Foundation IPv6 is not supported.

8.2. Multi network plug-in (Multus) support [Technology Preview]

OpenShift Data Foundation supports the ability to use multi-network plug-in Multus on bare metal infrastructures to improve security and performance by isolating the different types of network traffic. By using Multus, one or more network interfaces on hosts can be reserved for exclusive use of OpenShift Data Foundation.

Important

Multus support is a Technology Preview feature that is only supported and has been tested on bare metal deployments. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

To use Multus, first run the Multus prerequisite validation tool. For instructions to use the tool, see OpenShift Data Foundation - Multus prerequisite validation tool. For more information about Multus networks, see Multiple networks

8.2.1. Segregating storage traffic using Multus

By default, Red Hat OpenShift Data Foundation is configured to use the Red Hat OpenShift Software Defined Network (SDN). The default SDN carries the following types of traffic:

  • Pod-to-pod traffic
  • Pod-to-storage traffic, known as public network traffic when the storage is OpenShift Data Foundation
  • OpenShift Data Foundation internal replication and rebalancing traffic, known as cluster network traffic

There are three ways to segregate OpenShift Data Foundation from OpenShift default network:

  1. Reserve a network interface on the host for the public network of OpenShift Data Foundation

    • Pod-to-storage and internal storage replication traffic coexist on a network that is isolated from pod-to-pod network traffic.
    • Application pods have access to the maximum public network storage bandwidth when the OpenShift Data Foundation cluster is healthy.
    • When the OpenShift Data Foundation cluster is recovering from failure, the application pods will have reduced bandwidth due to ongoing replication and rebalancing traffic.

  2. Reserve a network interface on the host for OpenShift Data Foundation’s cluster network

    • Pod-to-pod and pod-to-storage traffic both continue to use OpenShift’s default network.
    • Pod-to-storage bandwidth is less affected by the health of the OpenShift Data Foundation cluster.
    • Pod-to-pod and pod-to-storage OpenShift Data Foundation traffic might contend for network bandwidth in busy OpenShift clusters.
    • The storage internal network often has an overabundance of bandwidth that is unused, reserved for use during failures.

  3. Reserve two network interfaces on the host for OpenShift Data Foundation: one for the public network and one for the cluster network

    • Pod-to-pod, pod-to-storage, and storage internal traffic are all isolated, and none of the traffic types will contend for resources.
    • Service level agreements for all traffic types are more able to be ensured.
    • During healthy runtime, more network bandwidth is reserved but unused across all three networks.

Dual network interface segregated configuration schematic example:

Dual network interface segregated configuration schematic

Triple network interface full segregated configuration schematic example:

Triple network interface full segregated configuration schematic

8.2.2. When to use Multus

Use Multus for OpenShift Data Foundation when you need the following:

Improved latency - Multus with ODF always improves latency. Use host interfaces at near-host network speeds and bypass OpenShift’s software-defined Pod network. You can also perform Linux per interface level tuning for each interface.

Improved bandwidth - Dedicated interfaces for OpenShift Data Foundation client data traffic and internal data traffic. These dedicated interfaces reserve full bandwidth.

Improved security - Multus isolates storage network traffic from application network traffic for added security. Bandwidth or performance might not be isolated when networks share an interface, however, you can use QoS or traffic shaping to prioritize bandwidth on shared interfaces.

8.2.3. Multus configuration

To use Multus, you must create network attachment definitions (NADs) before deploying the OpenShift Data Foundation cluster, which is later attached to the cluster. For more information, see Creating network attachment definitions.

To attach additional network interfaces to a pod, you must create configurations that define how the interfaces are attached. You specify each interface by using a NetworkAttachmentDefinition custom resource (CR). A Container Network Interface (CNI) configuration inside each of these CRs defines how that interface is created.

OpenShift Data Foundation supports two types of drivers. The following tables describes the drivers and their features:

macvlan (recommended)

ipvlan

Each connection gets a sub-interface of the parent interface with its own MAC address and is isolated from the host network.

Each connection gets its own IP address and shares the same MAC address.

Uses less CPU and provides better throughput than Linux bridge or ipvlan.

L2 mode is analogous to macvlan bridge mode.

Almost always require bridge mode.

L3 mode is analogous to a router existing on the parent interface. L3 is useful for Border Gateway Protocol (BGP), otherwise use macvlan for reduced CPU and better throughput.

Near-host performance when network interface card (NIC) supports virtual ports/virtual local area networks (VLANs) in hardware.

If NIC does not support VLANs in hardware, performance might be better than macvlan.

OpenShift Data Foundation supports the following two types IP address management:

whereabouts

DHCP

Uses OpenShift/Kubernetes leases to select unique IP addresses per Pod.

Does not require range field.

Does not require a DHCP server to provide IPs for Pods.

Network DHCP server can give out the same range to Multus Pods as well as any other hosts on the same network.

Caution

If there is a DHCP server, ensure Multus configured IPAM does not give out the same range so that multiple MAC addresses on the network cannot have the same IP.

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, Inc.