VCN API subnet creation fails with 'Invalid CIDR block' error despite valid configuration in networking module

Cloud Platforms Oracle Cloud
, , , , , , , ,
1

I’m automating VCN subnet creation using the OCI REST API and consistently getting ‘Invalid CIDR block’ errors. The subnet CIDR I’m trying to use is 10.0.1.0/24 within a VCN that has 10.0.0.0/16 as its CIDR block. I’ve verified the CIDR doesn’t overlap with existing subnets, and the compartment OCID is correct.

Here’s my API payload structure:


POST /20160918/subnets
{
  "compartmentId": "ocid1.compartment.oc1..aaa...",
  "vcnId": "ocid1.vcn.oc1.phx.aaa...",
  "cidrBlock": "10.0.1.0/24"
}

The VCN exists and I can create subnets fine through the console using the same CIDR. What am I missing in the API call? This is blocking our network automation pipeline.

2

Looking at your payload, you’re missing several fields that trigger proper CIDR validation. Here’s what you need:

VCN/subnet CIDR validation: The API performs multi-stage validation. First it checks payload structure completeness, then CIDR format, then overlap detection. Your error occurs at stage 1.

API payload structure: You must include these fields for 2019 API version:


{
  "compartmentId": "ocid1.compartment.oc1..aaa...",
  "vcnId": "ocid1.vcn.oc1.phx.aaa...",
  "cidrBlock": "10.0.1.0/24",
  "displayName": "subnet-app-tier",
  "availabilityDomain": null,
  "routeTableId": "ocid1.routetable.oc1.phx.aaa...",
  "securityListIds": ["ocid1.securitylist.oc1.phx.aaa..."]
}

Compartment OCID usage: The compartment OCID format looks correct, but ensure you have IAM permissions: manage virtual-network-family in compartment. Without proper permissions, you get CIDR validation errors instead of permission errors (known API behavior).

The routeTableId and securityListIds are critical - the API needs these to validate CIDR against routing and security rules before allowing subnet creation. Get the default route table and security list OCIDs from your VCN using GET /vcns/{vcnId}, then include them in your payload.

For regional subnets, set availabilityDomain to null explicitly. For AD-specific subnets, use the full AD name like “Kfyv:PHX-AD-1”.

Test with the OCI CLI first to capture the exact payload it sends: oci network subnet create --generate-full-command-json-input. This shows all required fields for your API version. The 2019 API is stricter about required fields than later versions.

3

Are you setting the dnsLabel field? I’ve seen cases where the API validation chain checks DNS labels before CIDR validation, and if it fails early, you get a misleading CIDR error. Also verify your API endpoint region matches the VCN region - cross-region calls can produce strange validation errors.

4

Thanks for the suggestions. I added displayName and availabilityDomain fields but still getting the same error. Could this be related to how the compartment OCID is being validated? I’m using a root compartment OCID - should I be using a specific sub-compartment?

5

Root compartment should work fine. The issue is likely in your CIDR format validation on the API side. Make sure there are no trailing spaces in your JSON payload and that you’re using proper Content-Type headers. Also, double-check that your VCN’s CIDR actually allows /24 subnets - if the VCN has any routing rules or security lists that conflict, the API will reject subnet creation with that generic error.

6

I had this exact issue last month. The problem isn’t the CIDR itself but missing required fields in your payload. You need to specify the availabilityDomain (even for regional subnets, pass null explicitly), and the prohibitPublicIpOnVnic boolean. The API is stricter than the console about these fields. Try adding those and see if the validation passes. The error message is misleading because it defaults to CIDR validation when the payload structure is incomplete.

7

Check if you’re including the displayName field. While it’s technically optional, some API versions treat it as required for proper validation. Also verify your authentication headers are complete.