Just trying to clear something up before I submit a bug report:

When using IP reservation in an isolated network it looks like the virtual
router is getting the wrong netmask.

For example:
- Network CIDR: 10.1.1.0/24
- Guest CIDR: 10.1.1.0/25
- Reserved IP Range: 10.1.1.127-10.1.1.254
- Virtual Router IP: 10.1.1.1

With this configuration, the Virtual Router gets get following
netmask/routing:

eth0      Link encap:Ethernet  HWaddr 02:00:55:eb:00:03
          inet addr:10.1.1.1  Bcast:10.1.1.127  Mask:255.255.255.128

Destination     Gateway         Genmask         Flags Metric Ref    Use
Iface
0.0.0.0         162.223.12.129  0.0.0.0         UG    0      0        0 eth2
10.1.1.0        0.0.0.0         255.255.255.128 U     0      0        0 eth0
162.223.12.128  0.0.0.0         255.255.255.128 U     0      0        0 eth2
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth1

This means that any server or VM configured in the reserved IP range cannot
ping the VR or use it for routing.  They also will not be able to contact
VMs deployed by CloudStack because there is no routing available, and the
CloudStack VMs inherit the /25 netmask from the VR.

To resolve this I think the following changes would be required:

Right now it seems that the /etc/init.d/postinit script configures the VR
interfaces using the details in '/var/cache/cloud/cmdline':

# cat /var/cache/cloud/cmdline
template=domP name=r-236-VM eth2ip=162.223.12.140 eth2mask=255.255.255.128
gateway=162.223.12.129 eth0ip=10.1.1.1 eth0mask=255.255.255.128 domain=
cs2dv.tqcloud.net cidrsize=25 dhcprange=10.1.1.1 eth1ip=169.254.2.4
eth1mask=255.255.0.0 type=router disable_rp_filter=true dns1=8.8.8.8
dns2=8.8.4.4 useextdns=true

I believe whatever is generating the data in '/var/cache/cloud/cmdline'
should be changed.  It should pull the 'eth0mask' from the 'Network CIDR'
instead of the 'Guest CIDR'.  This will allow for routing and communication
between CloudStack VMs, and hosts on the reserved portion of the network.

The remaining issue is ensuring the VR doesn't issue IPs from the reserved
range.  I don't think this is a problem anyway since CloudStack seems to
manually set up the static DHCP reservations (with /etc/dhcphosts.txt), but
the following change could still be made:

- Instead of using the VR IP in the dhcp-range (ex:
dhcp-range=10.1.1.1,static), it could be set as the inverse of the reserved
network (ex: dhcp-range=10.1.1.2,10.1.1.126,255.255.255.0,infinite).  I
believe the dhcp-range is also pulled from '/var/cache/cloud/cmdline'.


Am I misunderstanding how this feature is supposed to work, or should I go
ahead and create a bug report for this?


Thank You,

Logan Barfield
Tranquil Hosting

Reply via email to