Since its introduction in VMware Cloud Director (VCD) 10.4.1, IP Spaces has matured into a robust, feature-rich, structured approach for allocating IP addresses across VCD organizations. IP Spaces not only provides IP address management but also streamlines and automates a lot of the provider configuration work to supply their tenants with north-south communication paths.
During conversations with VMware Cloud Service Providers, discussing how IP Spaces differ from legacy IP Blocks and how it can help and improve their cloud infrastructure and work, I have been asked multiple times if using IP Spaces they have the flexibility to do a specific (custom) IP allocation to their tenants.
The answer is YES, but before going into details, let us quickly recap IP Spaces’ main concepts.
IP Spaces Types
- Public – This type of IP Space can be utilized by multiple organizations and is controlled by the service provider through a quota-based system. The word “Public” is not related to the IP address type: public or private IP. The provider can create a Public IP Space and utilize both public and private IP addresses CIDRs, even in the same IP Space, if appropriate to his use case. The Public IP Space’s IP schema cannot overlap with other Public or Shared IP Spaces (described next).
- Shared – A Shared IP Space is similar to the Public one, except that it is not exposed directly to the organizations for consumption. Instead, the provider can utilize the Shared IP Space, creating services or management networks that he does not want to reveal to the tenants but are nevertheless required in the tenant space.
- Private – As its name suggests, this IP Space is used by only one organization specified during IP Space creation. The Private IP Space has no quota, and the IP consumption is unlimited. Tenants can also create Private IP Spaces if they have the necessary rights. The IP schema of a Private IP Space can be overlapped for different organizations.
IP Spaces Attributes
Apart from the general object characteristics like name and description, an IP Space had the following attributes.
- Network Topology – Enables the support of networking features (Routing, NAT, Firewall) so that IP Spaces can help to automate the tenants’ north-south traffic paths provisioning. (To read more: Default NAT and Firewall auto-configuration in VMware Cloud Director 10.5 )
- Scope – This attribute has two sub-attributes:
- Internal Scope (mandatory) – This is a list of IP subnets (Classless Inter-Domain Routing – CIDRs) defining the exact span of IP addresses for this IP Space.
- External Scope (optional) – Defines the total span of IP addresses for this IP Space. For the Internet, this may be 0.0.0.0/0. For a WAN, this could be 10.0.0.0/8. The External Scope is used when Network Topology auto-configuration tasks are performed.
- IP Ranges (optional) – A list of IP Ranges that can be used for Edge Gateway services’ addresses (Floating IPs) assignment.
- IP Prefixes (optional) – A List of IP Prefixes for Org VDC networks CIDR assignment. Different IP Prefixes block sizes and numbers of them are supported.
IP Spaces supports both IPv4 and IPv6, but they cannot be mixed in one and the same IP Space.
IP Spaces Allocation
IP Spaces typically allocates IP addresses following the first-come, first-served pattern. This means that the Floating IPs or IP Prefixes are incrementally distributed, i.e., the first request gets the first available IP from the IP Range, or the first available CIDR block from the IP Prefix, etc.
Specifically for Public or Shared IP Spaces, this also means that there is no guarantee that a specific Floating IP or IP Prefix will be assigned to a particular organization.
But sometimes, providers want to be more deterministic of the IP schema they provide to their tenants, because they might also utilize this information to configure different services’ access on physical devices like Firewalls.
As per the current version (10.5), VCD doesn’t provide this functionality from the UI, but like most full API-driven platforms, more can be done with APIs. If we navigate the VCD API Explorer and search the “IP Spaces allocate” POST API call, we will find that we can also utilize the value property to request a specific Floating IP or IP Prefix.
Excellent! Then, usually, a followup question comes:
“Can we achieve the same with Terraform?”
Terraform provider for VCD
The current terraform provider for VCD is version 3.10.0. According to the documentation for the vcd_ip_space_ip_allocation resource, the value argument is supported. Still, if you try to use it in the resource specification, you will receive an error when applying the configuration.
This issue has been identified, and thanks to VMware engineering, the fix has already been merged into the main branch and will be available for version 3.11.0 of the provider.
In the meantime, I was eager to test it, so I cloned the Github repo https://github.com/vmware/terraform-provider-vcd and created a local build and installation.
Please note that while writing this blog, the terraform provider for VCD v3.11.0 has yet to be released, so the use of it is at your own risk.
Requesting a specific Floating IP or IP Prefix from IP Space
Creating the terraform resources for IP allocation is straightforward. We can omit the prefix_length argument when specifying the value because it is part of the string itself.
Note that a single Floating IP or IP Prefix is supported by the vcd_ip_space_ip_allocation terraform resource.
resource “vcd_ip_space_ip_allocation” “public-ip-prefix” { org_id = data.vcd_org.org1.id ip_space_id = vcd_ip_space.space1.id type = “IP_PREFIX” value = “192.168.241.128/26” } resource “vcd_ip_space_ip_allocation” “public-floating-ip” { org_id = data.vcd_org.org1.id ip_space_id = vcd_ip_space.space1.id type = “FLOATING_IP” value = “192.168.243.100” }
|
resource “vcd_ip_space_ip_allocation” “public-ip-prefix” { org_id = data.vcd_org.org1.id ip_space_id = vcd_ip_space.space1.id type = “IP_PREFIX” value = “192.168.241.128/26” }
resource “vcd_ip_space_ip_allocation” “public-floating-ip” { org_id = data.vcd_org.org1.id ip_space_id = vcd_ip_space.space1.id type = “FLOATING_IP” value = “192.168.243.100” } |
When applying the configuration, the terraform provider for VCD (v3.11.0) successfully provisions the two resources.
Now, we can verify the desired IP allocation from the VCD tenant UI. First, the Floating IPs tab shows that the 192.168.243.100 IP address is allocated to the tenant.
Second, the requested CIDR – 192.168.241.128/26 was also appropriately allocated for the tenant in the IP Prefixes tab.
Usage
The custom-allocated IP Prefix and Floating IP can then be used to create Org VDC networks and Edge Gateway services, respectively.
Below is the VCD UI representation of the terraform configured resources for the Routed Org VDC network …
and DNAT rule.
Conclusion
Service Providers can significantly benefit from automating their Day 2 operations and utilizing the entire VMware Cloud Director API feature set available. One way to achieve this is by using the Terraform provider for VCD, thereby streamlining their operations and making the most of the available resources.
The terraform configuration files used in the blog can be found at:
https://github.com/nnikodimov/customize-ip-spaces
If you are looking for more VMware Cloud Director’ IP Spaces information, refer to this blogs:
Remain up-to-date by regularly checking this blog for the latest updates. You can also connect with us on Slack, Facebook, Twitter, and LinkedIn.
Stay tuned for new demo videos and enablement on YouTube, especially our Feature Fridays series.