cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Logan B (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CLOUDSTACK-7844) IP Reservation in Isolated Networks doesn't work as expected
Date Wed, 05 Nov 2014 18:35:34 GMT
Logan B created CLOUDSTACK-7844:
-----------------------------------

             Summary: 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.0


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