Introduction:

Presently we can add multiple guest IP ranges within the same subnet in Basic Zone and Advanced sg enabled zones, but we cannot add IP ranges form different subnets.This feature provides this functionality for adding guest IP ranges from different subnets in Basic zone and advanced SG enabled networks. In case Advanced sg enabled network adding ip range to a sg enabled network form different subnet implies we add two or more subnets in the same vlan.

Use case:

There may be cases where admin may want to add more IP address once the old ones are exhausted. Admin may want to add the IP ranges form the same subnet or from different one. Currently in cloudstack there is no flexibility to do this for guest IP ranges.

Design description:

Addition of guest IPs in Basic and Advanced SG enabled zones.

presently the createVlanIpRange API is used to add the guest IP range to a network (shared) in basic zone. The IPs mentioned in this range are assigned to the guest VMs. These are public IPs and allow guest to communicate with the internet. Presently we can add multiple ranges form the same subnet but not from a different one. This feature will extend the createVlanIpRange to add guest IPs from a different subnet, to a shared network in basic zone.
In the present implementation one subnet can have only one gateway. we do no allow overlapping subnets.

APIs:

API Name

API parameters

API response

Available only for root admin

createVlanIpRange

Using the existing parameters. no new parameters will be added

returns the IP ranges

yes

for description of existing parameters please refer this page. http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/root_admin/createVlanIpRange.html

Validation.
#1 Will fail if the zone is not a basic zone or if forvirtual network is true.
#2 Will fail if the new subnet is subset or superset of the existing subnet.

Implementation detail.
In cases where a IP range form a different subnet is added, we need to configure a ipalias on the DHCP server with a IP form the this new subnet. This is required as the IP to the guest VMs is allocated using a DHCP server. So the router should have a interface on the new subnet to listen for the DHCP request coming form VMs in the new subnet.

execution flow.
#1 validate the inputs.
#2 Add the new range to the DB.
#3 When the first ip from the new subnet is allocated to the VM, create a new ip alias to the existing nic on the VR. This ip alias (example eth0:1) will have one of the IPs from the new subnet.

Note. The admin should manually configure the gateway of the new subnet before adding the IP range.

removing the the guest IPs.

We intend to use the deleteVlanRange API to delete the IP ranges. The operations will be atomic. this will fail if any IP form the remove range is being used. While removing we acquire a lock on the valn that is being removed. The Ip Alias created on the virtual router will be removed when the last VM or Nic form the subnet is removed.

DB changes:

created a new table nic_ip_aliase which is used to store the details of the ipalias created on the router per subnet.

Supported Hypervisors.

KVM, XenServer, VMware

Note:
The implementation as of now supports only Ipv4 addresses

  • No labels

1 Comment

  1. We may not need add multiple nics on the dhcp server for distinct subnets.
    Since they are on the same physical media, the dnsmasq should see dhcp requests from all subnets on that physical media (vlan or untagged vlan). Dnsmasq can handle this. See https://caffeine-powered.net/tech/networking/dnsmasq-dns-multiple-subnets-and-static-hosts/
    and http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,28/func,view/id,14979/
    Also this should be necessary only when you add vm with an ip on the new subnet. It should not be in the flow of executing this api (which is synchronous)