Open Stack

Thanks, Kevin.  I agree that it seems like a bug.  I'll go ahead and file.

Chris

On March 22, 2018 05:10:08 Kevin Benton <kevin at benton.pub> wrote:
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/899b1520/attachment.html>