Using an EgressIP with UserDefinedNetwork on OpenShift Container Platform for IBM Power

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"
EOF

The 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"
EOF

Wait 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"
EOF

In 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
EOF

Wait 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:

1. The pod is attached to the primary UDN.
2. The default route is installed through ovn-udn1.
3. Outbound traffic follows the UDN path.
4. 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.