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

Reply via email to