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

["Daan Hoogland (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daan Hoogland updated CLOUDSTACK-7844:
--------------------------------------
    Fix Version/s:     (was: 4.5.1)
                   4.5.2

> IP Reservation in Isolated Networks doesn't work as expected
> ------------------------------------------------------------
>
>                 Key: CLOUDSTACK-7844
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7844
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Virtual Router
>    Affects Versions: 4.4.0
>         Environment: CloudStack 4.4.0 w/ KVM Hypervisor on Ubuntu 14.04 LTS
>            Reporter: Logan B
>             Fix For: 4.5.2
>
>
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)