FS - IP Range Reservation within a Network

Bug Reference

https://issues.apache.org/jira/browse/CLOUDSTACK-705

Branch

master, 4.2.0

Introduction

Purpose

Currently in CloudStack the Guest CIDR is used for dhcp-range for the Guest VMs. The entire CIDR is used by CloudStack for assigning IPs to Guest VMs.
This feature will allow part of address space to be used for non CloudStack hosts also.

Supported Networks: Isolated Guests and VPC.

PRD is available at:

https://cwiki.apache.org/confluence/display/CLOUDSTACK/IP+Range+Reservation+within+a+Network

Glossary

1. Network CIDR : The Address space shared by Guest VMs and Non CloudStack hosts/physical servers.
2. GuestVm CIDR : The Address space that will be used only by Guest VMs.
3. Reserved Range : The Address space used by Non CloudStack hosts/physical servers.

     Guest Vm CIDR + Reserved Range = Network CIDR

     Guest Vm CIDR is the dhcp-range of Cloudstack Guest Vms.

• For isolated guest networks with IP Reservation:

cidr <==> guestVmCidr  and  network_cidr <==> network cidr

• For others:

cidr <==> network cidr and network_cidr is null

Feature Specifications

• Guest CIDR could be configured at 2 places at Creating Zone and Adding Guest Networks.
• Adding reservation functionality during Update of Guest Networks.
• Reservation implemented only when the network itself is “implemented”.
• Reservation would be optional add-on service, no default reservations done.

For existing/new networks:

1. The network offering does not use external network devices like NetScaler.

• The Guest CIDR can be defined for these networks by the user through the createNetwork API .
• If the Guest CIDR is not defined explicitly in the createNetwork API then the Guest CIDR is the same as that defined during Create Zone.

    2.  The network offering uses external network devices

• The Guest CIDR cannot be defined for these networks by the user through the createNetwork API
• It does not pick the Guest CIDR defined during Create Zone.
• Guest CIDR is not a choice of the admin.

Work Flow for both the cases:

• When the network is in implemented state, allow for reservation through the Update Network API.
• Add new option : "GuestVm CIDR" in the API and make CIDR editable in UI.(In UI CIDR will correspond to Guest Vm CIDR in the API).
• Admin/User specifies a valid GuestVm CIDR and reservation is applied if there are no active IPs outside the Guest VM CIDR.

Checks:

• GuestVm CIDR is a subset of the network CIDR.

Upgrade of Network offering for an existing Network:

    If the network offering upgrade requires the Guest CIDR to be modified (eg. updating network offering from an offering with no external devices to one with external devices) and the existing network had reservation enabled :

Work Flow:

• Wait until the network reaches implemented state after upgrading to new network offering.
• Allow reservation again by Update Network API.
• Add new option : "GuestVm CIDR" in the UI and API.
• Add new option : "GuestVm CIDR" in the API and make CIDR editable in UI.(In UI CIDR will correspond to Guest Vm CIDR in the API).
• Admin/User specifies a valid GuestVm CIDR and reservation is applied if there are no active IPs outside the Guest VM CIDR.
• Also clearly log/UI display alert message about the network change and informing non cloudstack hosts in the old network to be reconfigured in the new network.

Checks:

• GuestVm CIDR is a subset of network CIDR.

The following table describes the various scenarios of Guest Network creation:

Reservation Reset:

To reset an existing IP reservation just apply for IP reservation with guestVmCidr equal to the network cidr.

Use Cases:

• A user wants to share the Guest Network with physical server or VMs not deployed by CloudStack.

         CloudStack currently uses the entire CIDR for DHCP. Large networks like 10.1.1.0/24 generally do not use the complete address space for so the feature will allow for better IP utilization.

         Specifying /26 to be GuestVm CIDR we can limit 10.1.1.1-10.1.1.62 for dhcp range for guest VMs and remaining IPs in 10.1.1.0/24 can be reserved for Non CloudStack hosts.

Architecture and Design description

APIs

Modify the following APIs:

• updateNetwork: Add new parameter guestVmCidr
• listNetwork: Add new response parameter networkCidr and reservedIpRange (Non Cloudstack IPs)

Note: CIDR is now the effective DHCP range for the guest vms. Network CIDR is the CIDR for the entire guest network.

UI flow:

• Column to specify Guest VM CIDR  during network update.

          Networks -> Update GuestNetwork

DB

• Add columns guest_cidr to the following tables:

 networks 

 .

Open Issues

• Expansion of GuestVm Cidr :

GuestVm Cidr could theoretically be expanded to a level such that GuestVm CIDR = Guest CIDR, but need to take care if the IPs in the extended range are not allocated.
To check this, ping could be a solution but many devices may not allow ICMP so need a discussion on the same.

• Force Reservation :

The current reservation scheme does not allow reservation if active nics are found outside the Guest Vm Cidr. It may happen the user wants a force reservation, in which even if VMs are outside the Guest Vm Cidr, reservation should be made effective. This will involve every active host outside of Guest Vm Cidr to be shutdown and a reimplementation of the network so that these hosts get IPs inside the Guest Vm Cidr.

Test Cases

1. TBD