Since no one has responded I am considering this to be a bug, and created an issue in JIRA: https://issues.apache.org/jira/browse/CLOUDSTACK-7844
We are willing to pay someone to help us determine if this behavior is intended, and if not to come up with some patches to correct it. Thank You, Logan Barfield Tranquil Hosting On Mon, Nov 3, 2014 at 10:23 AM, Logan Barfield <lbarfi...@tqhosting.com> wrote: > Has anyone else had any luck replicating this issue? > > > Thank You, > > Logan Barfield > Tranquil Hosting > > On Fri, Oct 31, 2014 at 9:58 AM, Logan Barfield <lbarfi...@tqhosting.com> > wrote: > >> Hi Jayapal, >> >> Can you try destroying/redeploying the Virtual Router after the IP >> reservation is set up? I didn't encounter the issue until I restarted the >> network with 'cleanup' checked. >> >> >> Thank You, >> >> Logan Barfield >> Tranquil Hosting >> >> On Fri, Oct 31, 2014 at 2:08 AM, Jayapal Reddy Uradi < >> jayapalreddy.ur...@citrix.com> wrote: >> >>> Hi, >>> >>> I tried it in my environment (cloudstack 4.5), this issue is not seen. >>> >>> Here is the output from the router. >>> >>> root@r-19-QA:~# cat /var/cache/cloud/cmdline >>> root=UUID=fa9e76eb-51fd-4435-93e9-77bc9498ff09 ro debian-installer=en_US >>> quiet -- quiet console=hvc0 template=domP name=r-19-QA eth2ip=10.147.52.112 >>> eth2mask=255.255.255.0 gateway=10.147.52.1 eth0ip=10.1.1.1 >>> eth0mask=255.255.255.0 domain=cs2sandbox.kvm cidrsize=25 dhcprange=10.1.1.1 >>> eth1ip=169.254.0.148 eth1mask=255.255.0.0 type=router >>> disable_rp_filter=true dns1=10.223.240.232 >>> baremetalnotificationsecuritykey=7etJP5jUoAnrdFkoS0CSQxlvq2czPImMPBRDmwpxY-3NOxHjOCBUsOiW3gItvK7aXj-8HUmB7laezUUpn9SIRw >>> baremetalnotificationapikey=06Mpn82EU3LZcq_dJlHRi6nKWD8xkKieDpnCUwOuwSecUZRDJWQUTNjeJ0SaNq2YJzL0qrNVUtphtBEDv_YVOQ >>> host=10.252.192.48 port=8080 >>> root@r-19-QA:~# route -n >>> Kernel IP routing table >>> Destination Gateway Genmask Flags Metric Ref Use >>> Iface >>> 0.0.0.0 10.147.52.1 0.0.0.0 UG 0 0 0 >>> eth2 >>> 10.1.1.0 0.0.0.0 255.255.255.0 U 0 0 0 >>> eth0 >>> 10.147.52.0 0.0.0.0 255.255.255.0 U 0 0 0 >>> eth2 >>> 169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 >>> eth1 >>> root@r-19-QA:~# >>> >>> >>> Thanks, >>> Jayapal >>> >>> On 31-Oct-2014, at 12:25 AM, Logan Barfield <lbarfi...@tqhosting.com> >>> wrote: >>> >>> > 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 >>> >>> >> >
