VMware Cloud Director external network update fails with "Duplicate subnet specified" due to data inconsistency

Products

• VMware Cloud Director

Issue/Introduction

When attempting to modify an existing External Network that contains multiple subnet definitions, the operation fails with an error similar to:

[ <ID> ] Duplicate subnet specified <Gateway_IP_Address>.

This error occurs even when the API or UI modification intends to fix the overlapping or duplicate configuration. This typically affects External Networks that were created with inconsistent, overlapping, or duplicated Gateway IP addresses/subnets.

Environment

10.x

Cause

The root cause is an inconsistent state in the VCD database for the network object, where multiple subnet specifications (<vcloud:IpScope>) share the same Gateway IP address or have overlapping IP ranges.

When the network was initially created, VCD validation may have been bypassed or was less strict, allowing the inconsistent object to be persisted. When attempting to modify the object later, the current, stricter VCD API validation correctly detects the non-compliant, duplicate configuration and prevents the update.

Resolution

The supported resolution is to eliminate the inconsistency by safely recreating the External Network or leveraging the API to remove the corrupt element. Since the API often rejects the removal of a conflicting subnet specification on an existing network, the primary supported method is recreating the External Network with correct parameters.

Method 1: Recreate the External Network (Preferred)

This method ensures a clean, validated object is created in the VCD database and the underlying NSX configuration.

1. Identify Dependencies: Verify that no Organization Virtual Data Center (Org VDC) networks or vApps are actively utilizing the External Network that needs correction.

2. Delete the External Network: Safely remove the corrupt External Network object using the VCD Provider Portal UI or the API:

   DELETE https://<VCD_FQDN>/cloud/network/<network_ID>
   

3. Validate Underlying Network: Confirm that the associated NSX Segment/Port Group is free and correctly configured on the underlying vSphere/NSX layer.

4. Recreate the External Network: Create the External Network again using the VCD Provider Portal UI or API, ensuring that only unique and non-overlapping IP Subnets/Gateway IPs are defined.

Method 2: Update Network Subnets via API (If feasible)

If the network is in use and cannot be deleted, you can attempt to use a PUT request with a minimal, corrected payload. This method works if the VCD API can process the update without being triggered by the historical corruption.

1. Extract Current Configuration: Get the current network configuration via API.

2. Create a Minimal Corrected Payload: Construct a new JSON/XML payload for the PUT request that explicitly removes the conflicting subnet entry(ies) and only includes the unique, intended subnet configurations.

3. Execute the Update: Send the corrected payload via a PUT request to the network's API endpoint.

   PUT https://<VCD_FQDN>/cloud/network/<network_ID>
   Content-Type: application/json

Additional Information

 

• It is critical to ensure that any Org VDC Network or External Network has unique, non-overlapping IP address ranges (CIDRs) within its scope to prevent unexpected network behavior and future update failures.

• Refer to External Networks in Your VMware Cloud Director