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)
