<div dir="ltr"><div><div><div>Hi Neil,<br><br></div>Well that explains... <br></div>My networking setup does not conform to the commit message in such a way that there are multiple subnets on the network, however the instance does not have an IP address in all of them but only in one.<br></div><div>I guess the only option for now is to patch this code, as a workaround.The reason for having multiple subnets on the same L2 segment is a migration scenario. So I guess I'll just patch this as the situation will disappear in the near future as normally subnets are separated by L2 domains (vlans) in our setup.<br><br></div><div>Thanks!<br></div><div>Remco<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Apr 22, 2016 at 1:16 PM, Neil Jerram <span dir="ltr"><<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 22/04/16 12:03, Remco wrote:<br>
> Hi Neil,<br>
><br>
> Thanks.<br>
> The ip route output is as following, i guess the 0.0.0.0 gateway is only<br>
> listed by cloud-init:<br>
><br>
> debian@instance:/$ ip route<br>
> default via 192.168.10.1 dev eth0<br>
</span>> <a href="http://192.168.10.0/24" rel="noreferrer" target="_blank">192.168.10.0/24</a> <<a href="http://192.168.10.0/24" rel="noreferrer" target="_blank">http://192.168.10.0/24</a>> dev eth0 scope link<br>
<span class="">> 169.254.169.254 via 192.168.10.1 dev eth0<br>
</span>> <a href="http://192.168.11.0/24" rel="noreferrer" target="_blank">192.168.11.0/24</a> <<a href="http://192.168.11.0/24" rel="noreferrer" target="_blank">http://192.168.11.0/24</a>> dev eth0 scope link<br>
> <a href="http://192.168.12.0/24" rel="noreferrer" target="_blank">192.168.12.0/24</a> <<a href="http://192.168.12.0/24" rel="noreferrer" target="_blank">http://192.168.12.0/24</a>> dev eth0 proto kernel scope<br>
<span class="">> link src 192.168.10.2<br>
><br>
> (ip addresses are altered for security reasons).<br>
<br>
</span>Thanks for these clarifications.<br>
<span class=""><br>
> I'm not sure what creates these routes. I have two suspects: cloud-init<br>
> and DHCP. As the same issue is observed on instances without cloud-init<br>
> this rules out cloud-init.<br>
> We see the same issue on both Windows and Linux instances.<br>
<br>
</span>OK, I think you're seeing the effect of this DHCP agent code, from<br>
neutron/agent/linux/dhcp.py:<br>
<br>
host_routes.extend(["%s,0.0.0.0" % (s.cidr) for s in<br>
self.network.subnets<br>
if (s.ip_version == 4 and<br>
s.cidr != subnet.cidr)])<br>
<br>
AFAICS there is no obvious knob for suppressing this logic.<br>
<br>
The code was added in commit 6dce817c7c2, and the commit message says:<br>
<br>
=============8<=================<br>
Provide routes for neighbor IPv4 subnets<br>
<br>
Network may contain several Subnets. In this case all these subnets are<br>
accessible via same link and two VMs with addresses from different<br>
Subnets may talk to each other directly, bypassing default router. For<br>
this to work, "neighbour Subnets" should have entry in VM's routing<br>
tables. RFC3442 describes this situation:<br>
<br>
In some cases more than one IP subnet may be configured on a link.<br>
In such cases, a host whose IP address is in one IP subnet in the<br>
link could communicate directly with a host whose IP address is in a<br>
different IP subnet on the same link. In cases where a client is<br>
being assigned an IP address on an IP subnet on such a link, for each<br>
IP subnet in the link other than the IP subnet on which the client<br>
has been assigned the DHCP server MAY be configured to specify a<br>
router IP address of 0.0.0.0.<br>
<br>
When network contains more that one IPv4 subnets, report these subnets<br>
in 'classless-static-routes' DHCP option.<br>
<br>
DocImpact<br>
<br>
Change-Id: Ifcf1d99e0f0136bf52b8d13675b7ccfd48005fab<br>
Closes-Bug: #1372885<br>
=============8<=================<br>
<br>
So I guess the next question is: in what way does your networking setup<br>
not conform to the assumptions in that commit message?<br>
<br>
Regards,<br>
Neil<br>
<br>
</blockquote></div><br></div>