On Thu, Dec 17, 2015 at 4:09 PM, Vladimir Eremin <vere...@mirantis.com> wrote: > Hi Carl, > > I’ll fil RFE for sure, thank you for the link to the process ) > > So actually, we should announce all SUBNETS we’ve attached to router. > Otherwise is will not work, because external network router will have no > idea, where the traffic should be routed back. It is an actual viability > discriminator: subnets, that doesn’t attached are counting as unviable to the > external network context.
The subnets attached to the router which are not controlled by a subnet pool come straight from the user and there is no validation of the addresses used, no overlap prevention, nor any other kind of control. We can't leave it up to tenants to advertise whatever subnets they want to to the external network. The advertisements must be limited to subnets allocated to the tenant by the operator of the cloud with some mechanism for preventing overlap of addresses between subnets. A subnet that has an address scope was allocated from a pool defined under that scope. We know where the address came from and that it will not overlap any other subnet in the same scope. For subnets that don't meet this criteria, their traffic should not even be routed out to the external network in the first place let alone get a route back to the router. The address pools blueprint covers this too. > BTW, could you please point me to the spec for address scopes. Sure: https://blueprints.launchpad.net/neutron/+spec/address-scopes Carl __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
