Skip to content

Conversation

@Kab1r
Copy link

@Kab1r Kab1r commented Jan 9, 2026

Summary

Fixes #518

When ipFamilyPolicy is PreferDualStack, the getLbListenerBackendSetIpVersion function was incorrectly returning [IPv4, IPv6] based solely on subnet capabilities, ignoring the service's ipFamilies field.

This caused NLB creation to fail with the error:

Invalid listener: TCP-443-IPv6 is not associated with a backendset

Root Cause

The bug occurs when:

  • Service has ipFamilyPolicy: PreferDualStack
  • Service has ipFamilies: [IPv4] (cluster doesn't support dual-stack, or explicitly set)
  • OCI subnet supports dual-stack

The old code would create IPv6 listeners (based on subnet capabilities) but only IPv4 backend sets (based on ipFamilies), causing a mismatch.

Fix

The ipFamilies field is the authoritative specification of what IP families a service uses. The ipFamilyPolicy only influences how ipFamilies gets populated when not explicitly set.

This fix ensures the CCM respects ipFamilies by only including IP versions that are both:

  1. Specified in ipFamilies
  2. Supported by the subnet

Testing

  • Updated existing test cases to verify correct behavior
  • Tested with dual-stack OCI subnet and single-stack Kubernetes cluster

Changes

  • pkg/cloudprovider/providers/oci/load_balancer.go: Modified PreferDualStack case to iterate over ipFamilies and only include IP versions supported by subnet
  • pkg/cloudprovider/providers/oci/load_balancer_test.go: Updated test expectations for PreferDualStack with ipFamilies: [IPv4]

When ipFamilyPolicy is PreferDualStack, the getLbListenerBackendSetIpVersion
function was incorrectly returning [IPv4, IPv6] based solely on subnet
capabilities, ignoring the service's ipFamilies field.

This caused issues when:
- Service has ipFamilyPolicy: PreferDualStack
- Service has ipFamilies: [IPv4] (explicitly IPv4-only)
- Subnet supports dual-stack

The CCM would create IPv6 listeners even though the service explicitly
specifies IPv4-only via ipFamilies.

The ipFamilies field is the authoritative specification of what IP families
a service uses. The ipFamilyPolicy only influences how ipFamilies gets
populated when not explicitly set.

This fix ensures the CCM respects ipFamilies by only including IP versions
that are both specified in ipFamilies AND supported by the subnet.
@oracle-contributor-agreement
Copy link

Thank you for your pull request and welcome to our community! To contribute, please sign the Oracle Contributor Agreement (OCA).
The following contributors of this PR have not signed the OCA:

To sign the OCA, please create an Oracle account and sign the OCA in Oracle's Contributor Agreement Application.

When signing the OCA, please provide your GitHub username. After signing the OCA and getting an OCA approval from Oracle, this PR will be automatically updated.

If you are an Oracle employee, please make sure that you are a member of the main Oracle GitHub organization, and your membership in this organization is public.

@oracle-contributor-agreement oracle-contributor-agreement bot added the OCA Required At least one contributor does not have an approved Oracle Contributor Agreement. label Jan 9, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

OCA Required At least one contributor does not have an approved Oracle Contributor Agreement.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

NLB creation fails when ipFamilyPolicy is PreferDualStack but cluster only supports IPv4

1 participant