Open Stack

I think you might have uncovered an edge-case that should probably be filed
as a bug against Neutron.

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:
https://github.com/openstack/neutron/blob/282d3da614f24a6385c63a926a48845d3f6d72a3/neutron/db/l3_db.py#L797-L798

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


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.

Cheers,
Kevin Benton


On Sat, Mar 17, 2018 at 4:10 PM, Chris Apsey <bitskrieg at bitskrieg.net>
wrote:

> All,
>
> Had a strange incident the other day that seems like it shouldn't be
> possible inside of neutron...
>
> 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.
>
> 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).
>
> 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.)?
>
> Thanks,
>
> ---
> v/r
>
> Chris Apsey
> bitskrieg at bitskrieg.net
> https://www.bitskrieg.net
>
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20180322/5a3606b0/attachment.html>