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 <[email protected]> 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 > [email protected] > https://www.bitskrieg.net > > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators >
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
