Feature Overview (aka. Goal Summary)  

This feature focuses on defining and enabling supported use of EgressIP on secondary networks for OpenShift clusters deployed on the vSphere platform. Today, EgressIP is disabled on secondary interfaces for vSphere installations, and OpenShift has not formally claimed support for this configuration. However, customers increasingly require this capability due to IP address exhaustion on primary networks, and some deployments may already rely on unsupported behavior.

This feature aims to clarify support boundaries, document expectations, and, where necessary, implement changes to ensure EgressIP on secondary networks behaves predictably and is supportable on vSphere-based OpenShift clusters.

Goals (aka. expected user outcomes)

• Establish official support (or clearly defined non-support) for EgressIP on secondary networks in OpenShift vSphere deployments.
• Address customer demand driven by primary network IP exhaustion.
• Ensure consistent, predictable behavior of EgressIP when used with secondary NICs on vSphere.
• Provide clear documentation and guidance for customers and support teams.
• Identify and close any functional, architectural, or validation gaps required to make this configuration supportable.

Requirements (aka. Acceptance Criteria):

• EgressIP must function correctly when assigned to pods using a secondary network interface on vSphere.
• Behavior must be deterministic and observable, including failover, reassignment, and node failure scenarios.
• Any limitations, prerequisites, or constraints specific to vSphere networking must be explicitly defined.
• The feature must not negatively impact existing, supported EgressIP behavior on primary networks.
• Clear detection, validation, or guardrails must exist if the configuration remains unsupported or partially supported.

Anyone reviewing this Feature needs to know which deployment configurations that the Feature will apply to (or not) once it's been completed.  Describe specific needs (or indicate N/A) for each of the following deployment scenarios. For specific configurations that are out-of-scope for a given release, ensure you provide the OCPSTRAT (for the future to be supported configuration) as well.

Use Cases (Optional):

• Customers who have exhausted available IPs on the primary cluster network and need to route egress traffic through a secondary network.
• vSphere-based OpenShift clusters with multiple NICs per node, where secondary interfaces are already in use for traffic separation or scaling.
• Platform teams seeking to standardize egress traffic across clusters without redesigning primary network addressing.

Questions to Answer (Optional):

• Are code changes required, or is the feature already functionally viable but unsupported?

Out of Scope

• Redesign of EgressIP architecture across all platforms.
• Changes unrelated to vSphere deployments.
• Solving general IP exhaustion beyond enabling or supporting secondary-network egress.
• Providing guarantees for unsupported third-party or custom networking plugins.
• Retrofitting legacy clusters without clear upgrade or validation paths.

Background

Currently, EgressIP is disabled on secondary interfaces for vSphere installations, and OpenShift has never formally claimed support for this use case. Despite this, some customers report that the feature may function without code changes in certain environments. As IP exhaustion becomes more common, customers are increasingly relying on secondary networks for egress traffic, creating a gap between real-world usage and supported configurations.

This feature exists to address that gap by either enabling full support or clearly defining constraints and expectations.

Customer Considerations

• Customers may already be using this configuration in production without official support.
• Lack of clarity leads to support risk and inconsistent outcomes during incident resolution.
• Customers need clear guidance on:
  • Whether this configuration is supported
  • How to safely deploy it
  • What limitations or risks exist
• Backward compatibility and upgrade paths should be considered for existing clusters.

Documentation Considerations

• Explicitly document whether EgressIP on secondary networks is supported on vSphere.
• Provide configuration examples, prerequisites, and known limitations.

Interoperability Considerations

• N/A