Ad slot — header (728x90)

IP range overlaps with an existing subnetwork

Last reviewed: May 2026

If GCP returned this error, the fix is mechanical once you can see which existing range you collided with. This page shows how to find it and how to choose a range that will be accepted.

The exact error

IP range overlaps with an existing subnetwork

What actually causes it

The primary or secondary IP range you supplied intersects a range already assigned to a subnetwork in the same VPC network. Because GCP VPCs are global rather than regional, the conflicting subnetwork may be in a completely different region from the one you are deploying into.

Find the conflicting range

List what is already allocated before guessing at a new range:

gcloud compute networks subnets list \
  --filter="network:my-vpc" \
  --format="table(name, region, ipCidrRange, secondaryIpRanges[].ipCidrRange)"

Fix it, step by step

  1. List every subnetwork in the VPC, across all regions, with the command above. Include the secondary ranges column — omitting it is why this error so often looks inexplicable.
  2. Paste the output into the bulk subnet calculator to identify the intersecting pair.
  3. Choose a non-overlapping range with the free subnet finder, sizing it for both the primary range and any GKE pod and service secondary ranges.
  4. Recreate the subnetwork. Note that a subnetwork's primary range can be expanded later but never shrunk, so err on the generous side.

The GKE trap: a GKE cluster consumes three ranges — nodes (primary), pods (secondary) and services (secondary) — and the pod range is large, commonly a /14. Engineers plan the primary range carefully, let GCP auto-allocate the secondaries, and then collide months later when a second cluster is created. Always plan pod and service ranges explicitly.

Fastest pathPaste your existing ranges into the bulk subnet calculator — it accepts raw CLI JSON and CSV exports directly — then use the free subnet finder to get a list of ranges that are guaranteed not to conflict.
Find a range that will not conflict →

Preventing it next time

This error is almost always a symptom of address space that was never planned centrally. Allocating each environment a documented block from one supernet, and checking new ranges against that record before deployment, removes the whole class of failure. The Cloud VPC & VNet CIDR Planning Guide sets out that approach.

Frequently Asked Questions

Why does GCP say my CIDR block conflicts?

The primary or secondary IP range you supplied intersects a range already assigned to a subnetwork in the same VPC network. Because GCP VPCs are global rather than regional, the conflicting subnetwork may be in a completely different region from the one you are deploying into.

Can two subnets have overlapping CIDR blocks?

Not within the same VPC or virtual network. Providers require subnets to be disjoint so routing is unambiguous. Overlap is also what blocks VPC peering, VNet peering and Transit Gateway attachments between networks.

How do I find which range is causing the conflict?

List every existing range in the network, then compare each one against the range you are trying to create. The bulk subnet calculator on this site accepts CLI JSON and CSV exports directly and reports every overlapping pair, which is faster and more reliable than comparing by eye.

Related Guides

Ad slot — footer (728x90)