[Openstack-operators] [openstack operators][neutron] Neutron Router getting address not inside allocation range on provider network
kevin at benton.pub
Thu Mar 22 09:02:23 UTC 2018
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:
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
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.
On Sat, Mar 17, 2018 at 4:10 PM, Chris Apsey <bitskrieg at bitskrieg.net>
> 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.)?
> Chris Apsey
> bitskrieg at bitskrieg.net
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-operators