Soru

Zorluk: OrtaPlanning Virtual Private Cloud (VPC) Networks and Subnets

A cloud administration team manages a custom-mode Virtual Private Cloud (VPC) network in Google Cloud. An application subnet in `europe-west3` currently uses the primary IPv4 CIDR range 10.30.15.0/2410.30.15.0/24. Due to increased instance deployment, the team needs to expand the capacity of this subnet to a /23/23 netmask length (512512 IP addresses). The adjacent IP block 10.30.16.0/2410.30.16.0/24 is completely unassigned, while the block 10.30.14.0/2410.30.14.0/24 is actively used by a database subnet in the same VPC network. Which strategy should the team implement to resolve the capacity requirement without causing IP allocation errors?

  1. Provision a new subnet using a non-overlapping block such as 10.30.16.0/2310.30.16.0/23 and migrate the workloads to the new subnet.Cevap
  2. B
    Run the subnet expansion command to expand 10.30.15.0/2410.30.15.0/24 directly to 10.30.14.0/2310.30.14.0/23 because Google Cloud automatically re-assigns overlapping IP addresses.
  3. C
    Expand the subnet by setting the new primary range to 10.30.15.0/2310.30.15.0/23 to force expansion upward into 10.30.16.0/2410.30.16.0/24.
  4. D
    Convert the VPC network mode from custom to automatic mode so Google Cloud automatically resizes the subnet range.

Cevap

Provision a new subnet using a non-overlapping block such as 10.30.16.0/2310.30.16.0/23 and migrate the workloads to the new subnet.
When expanding a primary subnet IP range in Google Cloud, the new range must encompass the original range and align to a valid binary CIDR boundary corresponding to the new prefix length. For an odd third octet like 1515 in 10.30.15.0/2410.30.15.0/24, expanding to /23/23 forces the lower boundary back to the even number 1414 (10.30.14.0/2310.30.14.0/23). Because 10.30.14.0/2410.30.14.0/24 is already assigned, GCP will reject the expansion to prevent IP overlap. The only viable path is provisioning a separate, non-overlapping subnet (such as 10.30.16.0/2310.30.16.0/23) and migrating resources.

Adım Adım Çözüm

1
Determine the required CIDR boundary for expanding a /24/24 subnet to a /23/23 subnet.
A /23/23 block contains 512512 addresses and must start on an even number in the third octet. For 10.30.15.0/2410.30.15.0/24, the enclosing /23/23 block is 10.30.14.0/2310.30.14.0/23 (10.30.14.010.30.14.010.30.15.25510.30.15.255).
Google Cloud VPC subnet expansion enforces standard binary CIDR alignment boundaries.
2
Evaluate potential IP range collisions within the existing VPC network.
10.30.14.0/2310.30.14.0/23 includes the IP block 10.30.14.0/2410.30.14.0/24, which is already allocated to an active database subnet.
Subnet ranges in the same VPC network cannot overlap under any circumstances.
3
Select the valid mitigation pattern for constrained subnet expansions.
Direct expansion of 10.30.15.0/2410.30.15.0/24 is impossible. Creating a new contiguous block like 10.30.16.0/2310.30.16.0/23 and re-homing workloads avoids all IP conflicts.
Creating a clean, non-overlapping subnet satisfies capacity needs while complying with VPC expansion constraints.

Anahtar Kavram

GCP Subnet Expansion Alignment and Overlap Constraints
Bu soruyu puanla