<div dir="ltr">I think you might have uncovered an edge-case that should probably be filed as a bug against Neutron.<div><br></div><div>If a router interface is attached using a reference to a subnet, it always tries to use the address in the "gateway_ip" of the subnet: </div><div><a href="https://github.com/openstack/neutron/blob/282d3da614f24a6385c63a926a48845d3f6d72a3/neutron/db/l3_db.py#L797-L798">https://github.com/openstack/neutron/blob/282d3da614f24a6385c63a926a48845d3f6d72a3/neutron/db/l3_db.py#L797-L798</a><br></div><div><br></div><div>My opinion is that Neutron probably shouldn't allow grabbing the default gateway if you aren't the owner of the subnet, but that is a fix that might not land for a while depending on their priorities (I'm no longer an active developer).</div><div><br></div><div><br></div><div>In the meantime, I recommend that you create a neutron port as an admin on the public network using the gateway_ip of the network to represent your real gateway router. This will prevent anyone from being able to attach a router using the subnet as a reference since the gateway_ip address will already be in use.</div><div><br></div><div>Cheers,</div><div>Kevin Benton</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Mar 17, 2018 at 4:10 PM, Chris Apsey <span dir="ltr"><<a href="mailto:bitskrieg@bitskrieg.net" target="_blank">bitskrieg@bitskrieg.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br>
<br>
Had a strange incident the other day that seems like it shouldn't be possible inside of neutron...<br>
<br>
We are currently running Queens on Ubuntu 16.04 w/ the linuxbridge ml2 plugin with vxlan overlays.  We have a single, large provider network that we have set to 'shared' and 'external', so people who need to do things that don't work well with NAT can connect their instances directly to the provider network.  Our 'allocation range' as defined in our provider subnet is dedicated to tenants, so there should be no conflicts.<br>
<br>
The other day, one of our users connected a neutron router to the provider network (not via the 'external network' option, but rather via the normal 'add interface' option) and neglected to specify an IP address.  The neutron router decided that it was now the gateway for the entire provider network and began arp'ing as such (I'm sure you can imagine the results).<br>
<br>
To me, this seems like it should be disallowed inside of neutron (you shouldn't be able to specify an IP address for a router interface that isn't explicitly part of your allocation range on said subnet).  Does neutron just expect issues like this to be handled by the physical provider infrastructure (spoofing prevention, etc.)?<br>
<br>
Thanks,<br>
<br>
---<br>
v/r<br>
<br>
Chris Apsey<br>
<a href="mailto:bitskrieg@bitskrieg.net" target="_blank">bitskrieg@bitskrieg.net</a><br>
<a href="https://www.bitskrieg.net" rel="noreferrer" target="_blank">https://www.bitskrieg.net</a><br>
<br>
______________________________<wbr>_________________<br>
OpenStack-operators mailing list<br>
<a href="mailto:OpenStack-operators@lists.openstack.org" target="_blank">OpenStack-operators@lists.open<wbr>stack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi<wbr>-bin/mailman/listinfo/openstac<wbr>k-operators</a><br>
</blockquote></div><br></div></div>