[
https://issues.apache.org/jira/browse/CLOUDSTACK-7844?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rajani Karuturi updated CLOUDSTACK-7844:
----------------------------------------
Fix Version/s: (was: 4.5.0)
4.5.1
> 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.1
>
>
> 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)
