As OpenShift Container Platform (OCP) adoption continues to grow on IBM Power systems, customers are increasingly looking to combine advanced networking capabilities with on-premises PowerVM deployments. One area that often generates questions is how EgressIP behaves with a primary UserDefinedNetwork (UDN) and how traffic is routed from workloads attached to that network.
This walkthrough demonstrates how to deploy a Layer 2 primary UserDefinedNetwork, assign an EgressIP, and validate that outbound traffic from a pod traverses the UDN interface rather than the cluster default network. The example is particularly relevant for OpenShift on IBM Power, including PowerVM environments managed through PowerVC.
Why UserDefinedNetworks Matter
UserDefinedNetworks (UDNs) allow OpenShift administrators to create custom pod networking domains separate from the cluster’s default network. When deployed as a Primary network, the UDN becomes the pod’s default network interface and routing domain.
This can be useful for:
- Application isolation
- Dedicated routing paths
- Network segmentation
- Multi-tenant environments
- Advanced EgressIP scenarios
For organizations running OCP on IBM Power, UDNs provide the same flexibility available on other supported OpenShift platforms while leveraging the scale and resiliency of Power infrastructure.
Prerequisites
Before creating the EgressIP resource, choose a valid IP address that:
- Is currently unused
- Is routable from your worker nodes
- Exists on the same Layer 2 segment as the node interface hosting the EgressIP
⚠️ Replace EGRESS_IP_ADDRESS with a valid address from your environment.
For on-premises PowerVM deployments, this IP should belong to the same network segment as the worker nodes that will advertise the EgressIP.
Create the UDN-Enabled Namespace
Namespaces that use a primary UDN must be labeled appropriately.
cat <<'EOF' | oc apply -f -
apiVersion: v1
kind: Namespace
metadata:
name: egressip-udn-repro
labels:
k8s.ovn.org/primary-user-defined-network: ""
egressip-test: "true"
EOFThe label k8s.ovn.org/primary-user-defined-network: “” signals that workloads in the namespace should attach to a primary UserDefinedNetwork.
The additional label egressip-test: “true” is later used by the EgressIP namespaceSelector.
Create a Layer 2 Primary UserDefinedNetwork
Create a primary Layer 2 UDN:
cat <<'EOF' | oc apply -f -
apiVersion: k8s.ovn.org/v1
kind: UserDefinedNetwork
metadata:
name: repro-udn-l2
namespace: egressip-udn-repro
spec:
topology: Layer2
layer2:
role: Primary
subnets:
- "10.100.0.0/24"
EOFWait for the network to become ready:
oc wait userdefinednetwork repro-udn-l2 -n egressip-udn-repro \
--for condition=NetworkReady=True --timeout=60s💡 Ensure the UDN subnet does not overlap with the cluster pod network, service network, or OVN join subnets. In this example, 10.100.0.0/24 is used as the UDN subnet.
Enable EgressIP Assignment on a Worker Node
Label a worker node so OVN-Kubernetes can host EgressIP assignments:
| oc label node worker-0 k8s.ovn.org/egress-assignable=”” |
You can verify the label using:
| oc get nodes –show-labels |
Create the EgressIP Resource
cat <<'EOF' | oc apply -f -
apiVersion: k8s.ovn.org/v1
kind: EgressIP
metadata:
name: repro-egressip
spec:
egressIPs:
- "EGRESS_IP_ADDRESS"
namespaceSelector:
matchLabels:
egressip-test: "true"
EOFIn a lab environment, an unused address was selected from the worker node network and associated with the node through an additional interface configured in PowerVC – and EGRESS_IP_ADDRESS was updated to match the unused address that was routable on the network.
Verify EgressIP Assignment
Confirm that OVN successfully assigned the EgressIP:
| oc get egressip repro-egressip -o yaml |
Review the status section and verify the address is assigned to the intended worker node.
Example:
| status: items: – egressIP: 192.168.1.50 node: worker-0 |
Deploy a Test Pod
Create a simple UBI-based pod:
cat <<'EOF' | oc apply -f -
apiVersion: v1
kind: Pod
metadata:
name: egress-test-pod
namespace: egressip-udn-repro
labels:
app: egress-test
spec:
containers:
- name: curl
image: registry.access.redhat.com/ubi9/ubi-minimal:latest
command: ["sleep", "infinity"]
securityContext:
allowPrivilegeEscalation: false
runAsNonRoot: true
capabilities:
drop: ["ALL"]
seccompProfile:
type: RuntimeDefault
EOFWait until the pod becomes ready:
oc wait pod egress-test-pod -n egressip-udn-repro --for condition=Ready --timeout=120s |
Install curl
Access the pod:
| oc rsh -n egressip-udn-repro egress-test-pod |
Install curl:
| microdnf –setopt=cachedir=/tmp/dnf-cache –setopt=keepcache=0 install -y curl |
Validate External Connectivity
Generate outbound traffic:
| curl -sv https://google.com/ –connect-timeout 10 |
You can replace the endpoint with any reachable external service that allows source IP verification.
Inspect Routing Inside the Pod
Review the routing table:
| cat /proc/net/route |
Example output:
| Iface Destination Gateway ovn-udn1 00000000 0100640A ovn-udn1 0000640A 00000000 eth0 0000800A 0102800A |
Decoded, the routes appear as:
| Destination | Gateway | Interface |
| 0.0.0.0 | 10.100.0.1 | ovn-udn1 |
| 10.100.0.0/24 | Direct | ovn-udn1 |
| 10.128.0.0/22 | 10.128.2.1 | eth0 |
| 100.64.0.0/16 | 10.128.2.1 | eth0 |
| 100.65.0.0/16 | 10.100.0.1 | ovn-udn1 |
| 172.30.0.0/16 | 10.100.0.1 | ovn-udn1 |
The key observation is that the default route points to ovn-udn1, confirming that the primary UDN is acting as the pod’s primary network.
Verify Traffic Flow
Examine interface statistics:
| cat /proc/net/dev |
Example:
| Inter-| Receive | Transmit … eth0: 446 5 ovn-udn1: 21828173 4698 |
The significantly higher packet and byte counts on ovn-udn1 indicate that application traffic is flowing through the UserDefinedNetwork rather than the cluster default interface.
This validates that:
- The pod is attached to the primary UDN.
- The default route is installed through ovn-udn1.
- Outbound traffic follows the UDN path.
- EgressIP can be applied to workloads selected through the namespace selector.
Conclusion
OpenShift’s UserDefinedNetwork capability provides a powerful way to create dedicated networking domains for applications while still taking advantage of platform services such as EgressIP. On IBM Power deployments, including PowerVM-based environments, this enables architects to combine network isolation with consistent outbound IP presentation.
In this validation, a primary Layer 2 UDN successfully became the pod’s default network, routes were installed through ovn-udn1, and traffic counters confirmed that outbound connections traversed the UDN. Combined with EgressIP assignment, this offers a flexible pattern for workloads that require network segmentation and predictable egress behavior on OpenShift running on IBM Power.
