[CLOUDSTACK-7844] IP Reservation in Isolated Networks doesn't work as expected

• Type: Bug
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 4.4.0
• Fix Version/s: Future
• Component/s: Virtual Router
• Security Level: Public (Anyone can view this level - this is the default.)
• Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS
• Assignee: Unassigned
• Reporter: Logan B
• Created: 05/Nov/14 18:35
• Updated: 09/Jul/15 09:09

Description

When using the IP Reservation functionality on an Isolated Guest Network in an Advanced Zone it doesn't work as expected.

Goal: Create Isolated Network with 10.1.1.0/24 subnet. Configure network with IP reservation to 10.1.1.0/25.

Test:
1. Create Isolated Guest Network with VR/DHCP/Etc. (Using the default 'IsolatedNetworkOfferingWithSourceNAT' offering). Use default Guest CIDR (10.1.1.0/24).
2. Deploy VM on network to "Implement" it.* Make sure VM has a NIC in 10.1.1.0/25. (ex: 10.1.1.50).
3. Edit network and set "Guest CIDR" to 10.1.1.0/25. After saving the "Guest CIDR" field should display 10.1.1.0/25, and the "Network CIDR" field should be 10.1.1.0/24.
4. NOTE: At this point everything should be working as expected. Problems don't occur until the next step.
5. Restart the network you created (with "Cleanup" checked).
6. Reboot the VM you created earlier, or run dhclient on the primary interface.
7. The VM will now have a /25 (255.255.255.128) netmask, instead of the /24 it was initially deployed with.
8. Manually modify the VMs IP and netmask to be outside the Guest CIDR, but still within the network CIDR (e.g., 10.1.1.150/24), and create a default route for the VR IP (e.g. 10.1.1.1).

Expected Result:

• No VMs should be deployed in the reserved range.
• IPs in the reserved range (10.1.1.127 - 10.1.1.254) should be able to ping VMs in the Guest CIDR range (10.1.1.2 - 10.1.1.125), and vice versa.
• The virtual router should still have a 255.255.255.0 netmask, and provide routing/DHCP/etc for the entire subnet (10.1.1.0/24).
• New VMs created on the guest network should get an IP in the Guest CIDR range (10.1.1.0/25) but have the Network CIDR netmask (255.255.255.0).

Observed Result:

• No VMs are deployed in the reserved range.
• IPs in the reserved range (10.1.1.127 - 10.1.1.254) are NOT ABLE to ping VMs in the Guest CIDR range (10.1.1.2 - 10.1.1.125), and vice versa.
• The virtual router has a /25 (255.255.255.128) netmask, and only provides routing/DHCP for addresses in that subnet.
• New VMs created on the network are deployed in the Guest CIDR range (10.1.1.0/25) with a /25 (255.255.255.128) netmask, instead of a /24 (255.255.255.0) netmask.

I'm assuming this is not the intended behavior. I posted these results on the dev list, but didn't get much traction.

I would assume this can be resolved in one of two ways:

• Option A) Ensure that the Virtual Router always pulls it's netmask/routing from the Network CIDR. As I understand it CloudStack manually creates static DHCP entries when provisioning VMs, so I don't think any networking changes should take effect on the VR when implementing IP reservation. (If anything we should just update the "dhcp-range" instead of the netmask/routing.

• Option B) When IP reservation is in effect the virtual router should be updated with a route to the reserved range (10.1.1.128/25). That way it will still be reachable if we manually set a /24 netmask on hosts in the reserved range. This option seems like a workaround rather than a fix, so Option A would be preferred.

Notice that this problem ONLY comes up when the Virtual Router is cleaned up or re-deployed. Because of this it may not be caught in standard testing, but it can cause problems when the router is restarted for HA/migrations/maintenance/etc.