Re-opened since bug 1774019 seems to be a duplicate. In that case a user was able to add a router to a shared external network and it got the .1 address. Looks like there is an edge case here we need to cover.
** Changed in: neutron Status: Expired => Confirmed ** Changed in: neutron Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1757482 Title: IP address for a router interface allowed outside the allocation range of subnet Status in neutron: Confirmed Bug description: Currently running Queens on Ubuntu 16.04 with 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. 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. 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). Unless neutron just expect issues like this to be handled by the physical provider infrastructure (spoofing prevention, etc.)? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1757482/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp