Networking overview
Understanding fundamental networking concepts and general tasks in OpenShift Dedicated
Abstract
Chapter 1. About networking Copy linkLink copied to clipboard!
To optimize network traffic management and security across hybrid clusters, configure Red Hat OpenShift Networking.
The Red Hat OpenShift Networking ecosystem of networking capabilities integrates ingress, egress, load balancing, high-performance throughput, security, and inter- and intra-cluster traffic management. The Red Hat OpenShift Networking ecosystem also provides role-based observability tooling to reduce its natural complexities.
The following list details some of the most commonly used Red Hat OpenShift Networking features available on your cluster:
- Cluster Network Operator for network plugin management.
Primary cluster network provided by either of the following Container Network Interface (CNI) plugins:
- OVN-Kubernetes network plugin, which is the default CNI plugin.
- OpenShift SDN network plugin, which was deprecated in OpenShift 4.16 and removed in OpenShift 4.17.
Before upgrading OpenShift Dedicated clusters that are configured with the OpenShift SDN network plugin to version 4.17, you must migrate to the OVN-Kubernetes network plugin. For more information, see Migrating from the OpenShift SDN network plugin to the OVN-Kubernetes network plugin.
Chapter 2. CIDR range definitions Copy linkLink copied to clipboard!
To ensure stable and accurate network routing in OpenShift Dedicated clusters that use OVN-Kubernetes, define non-overlapping Classless Inter-Domain Routing (CIDR) subnet ranges. Establishing unique ranges prevents IP address conflicts so that internal traffic reaches its intended destination without interference.
For OpenShift Dedicated 4.17 and later versions, clusters use 169.254.0.0/17 for IPv4 and fd69::/112 for IPv6 as the default masquerade subnet. You must avoid these ranges. For upgraded clusters, there is no change to the default masquerade subnet.
You can use the Red Hat OpenShift Network Calculator to decide your networking needs before setting CIDR range during cluster creation.
You must have a Red Hat account to use the calculator.
The following subnet types are mandatory for a cluster that uses OVN-Kubernetes:
- Join: Uses a join switch to connect gateway routers to distributed routers. A join switch reduces the number of IP addresses for a distributed router. For a cluster that uses the OVN-Kubernetes plugin, an IP address from a dedicated subnet is assigned to any logical port that attaches to the join switch.
- Masquerade: Prevents collisions for identical source and destination IP addresses that are sent from a node as hairpin traffic to the same node after a load balancer makes a routing decision.
- Transit: A transit switch is a type of distributed switch that spans across all nodes in the cluster. A transit switch routes traffic between different zones. For a cluster that uses the OVN-Kubernetes plugin, an IP address from a dedicated subnet is assigned to any logical port that attaches to the transit switch.
You can change the join, masquerade, and transit CIDR ranges for your cluster as a postinstallation task.
When specifying subnet CIDR ranges, ensure that the subnet CIDR range is within the defined Machine CIDR. You must verify that the subnet CIDR ranges allow for enough IP addresses for all intended workloads depending on which platform the cluster is hosted.
OVN-Kubernetes, the default network provider in OpenShift Dedicated 4.14 and later versions, internally uses the following IP address subnet ranges:
-
V4JoinSubnet:100.64.0.0/16 -
V6JoinSubnet:fd98::/64 -
V4TransitSwitchSubnet:100.88.0.0/16 -
V6TransitSwitchSubnet:fd97::/64 -
defaultV4MasqueradeSubnet:169.254.0.0/17 -
defaultV6MasqueradeSubnet:fd69::/112
The earlier list includes join, transit, and masquerade IPv4 and IPv6 address subnets. If your cluster uses OVN-Kubernetes, do not include any of these IP address subnet ranges in any other CIDR definitions in your cluster or infrastructure.
2.1. Machine CIDR Copy linkLink copied to clipboard!
To establish the network scope for cluster nodes in OpenShift Dedicated, specify an IP address range in the Machine Classless Inter-Domain Routing (CIDR) parameter. Defining this range ensures that all machines within the environment have valid, routable addresses for internal cluster communication.
You cannot change Machine CIDR ranges after you create your cluster.
This range must encompass all CIDR address ranges for your virtual private cloud (VPC) subnets. Subnets must be contiguous. A minimum range of 128 IP addresses, using the subnet prefix /25, is supported for single availability zone deployments. A minimum address range of 256 addresses, using the subnet prefix /24, is supported for deployments that use multiple availability zones.
The default is 10.0.0.0/16. This range must not conflict with any connected networks.
2.2. Service CIDR Copy linkLink copied to clipboard!
To allocate IP addresses for cluster services in OpenShift Dedicated, specify an IP address range in the Service Classless Inter-Domain Routing (CIDR) parameter. Defining this range ensures that internal services have a dedicated block of addresses for reliable communication without overlapping with node or pod networks.
Red Hat recommends, but this task is not mandatory, that the address block is the same between clusters. This does not create IP address conflicts.
The range must be large enough to accommodate your workload. The address block must not overlap with any external service accessed from within the cluster. The default is 172.30.0.0/16.
2.3. Pod CIDR Copy linkLink copied to clipboard!
To allocate internal network addresses for cluster workloads in OpenShift Dedicated, specify an IP address range in the pod Classless Inter-Domain Routing (CIDR) field. Defining this range ensures that pods can communicate with each other reliably without overlapping with the node or service networks.
Red Hat recommends, but this task is not mandatory, that the address block is the same between clusters. This does not create IP address conflicts. The range must be large enough to accommodate your workload. The address block must not overlap with any external service accessed from within the cluster. The default is 10.128.0.0/14.
2.4. Host prefix Copy linkLink copied to clipboard!
To allocate a dedicated pool of IP addresses for pods on each node in OpenShift Dedicated, specify the subnet prefix length in the hostPrefix parameter. Defining an appropriate prefix ensures that every machine has sufficient unique addresses to support its scheduled workloads without exhausting the cluster’s network resources.
For example, if you set the hostPrefix parameter to /23, each machine is assigned a /23 subnet from the pod CIDR address range. The default is /23, allowing 512 cluster nodes and 512 pods per node. Note that where 512 cluster nodes and 512 pods are beyond the maximum supported.
For example, if the host prefix is set to /23, each machine is assigned a /23 subnet from the pod CIDR address range. The default is /23, allowing 510 cluster nodes and 510 pod IP addresses per node.
Consider another example where you set the clusterNetwork.cidr parameter to 10.128.0.0/16, you define the complete address space for the cluster. This assigns a pool of 65,536 IP addresses to your cluster. If you then set the hostPrefix parameter to /23, you define a subnet slice to each node in the cluster, where the /23 slice becomes a subnet of the /16 subnet network. This assigns 512 IP addresses to each node, where 2 IP addresses get reserved for networking and broadcasting purposes. The following example calculation uses these IP address figures to determine the maximum number of nodes that you can create for your cluster:
65536 / 512 = 128
65536 / 512 = 128
You can use the Red Hat OpenShift Network Calculator to calculate the maximum number of nodes for your cluster.
Legal Notice
Copy linkLink copied to clipboard!
Copyright © 2025 Red Hat
OpenShift documentation is licensed under the Apache License 2.0 (https://www.apache.org/licenses/LICENSE-2.0).
Modified versions must remove all Red Hat trademarks.
Portions adapted from https://github.com/kubernetes-incubator/service-catalog/ with modifications by Red Hat.
Red Hat, Red Hat Enterprise Linux, the Red Hat logo, the Shadowman logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat Software Collections is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation’s permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.