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 >> >> >
