cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daan Hoogland (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-7844) IP Reservation in Isolated Networks doesn't work as expected
Date Thu, 09 Jul 2015 09:10:07 GMT

     [ 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.2)
                   Future

> 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: Future
>
>
> 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)

Mime
View raw message