Description of problem: After creating an external provider network under default policy as admin with: $ neutron net-create net-ext0 --provider:network_type=... --provider:physical_network=... --router:external=true $ neutron subnet-create ... Then it is possible as a tenant: $ neutron router-create router-test0 $ neutron router-gateway-set net-ext0 So although the external provider network is not shared, any tenant is able to connect their routers to it and start consuming its resources like IPs and bandwidth. It would be better if by default only an admin would be able to do this on non-shared networks. Version-Release number of selected component (if applicable): openstack-neutron-2014.1.3-7.el7ost.noarch
Hi, That's the way Neutron is designed: By marking a network as external you are actually sharing it among all other tenants to be used as default GW and a source for floating IPs. Marking a network as "shared" is allowing other tenants to connect VMs (and not router GWs) to the network. Creating an external network that's limited to a single tenant doesn't make much sense, as VMs in this tenant can already connect directly to the network without needing floating IPs Marking an external network as "shared" would allow VMs of all tenants to connect to a network as well as pull floating ips from it (via router GW). While this is possible in Neutron, it is also redundant, as with the case above - There isn't much sense in pulling a floating IP from a network that you can connect to directly. I did look at the neutron manual and I understand where the confusion is coming from. I filed a bug against that manual https://bugs.launchpad.net/openstack-manuals/+bug/1405403 You are welcome to contact me for further details.
Hi Martin, Can you please take a look at this from docs perspective? Thanks, Nir
(In reply to yfried from comment #3) > > By marking a network as external you are actually sharing it among all other > tenants to be used as default GW and a source for floating IPs. > > Marking a network as "shared" is allowing other tenants to connect VMs (and > not router GWs) to the network. > > Creating an external network that's limited to a single tenant doesn't make > much sense, as VMs in this tenant can already connect directly to the > network without needing floating IPs > > I did look at the neutron manual and I understand where the confusion is > coming from. > I filed a bug against that manual > https://bugs.launchpad.net/openstack-manuals/+bug/1405403 > > You are welcome to contact me for further details. Thanks for the explanation. The clarification is certainly helpful but perhaps while at it we could also document and provide examples how to set up networking for tenants A, B, and C who are all allowed to make connections to outer networks but A is not entitled to floating IPs, B is entitled to floating IPs 10.0.0.10-10.0.0.20 and C is entitled to floating IPs 10.0.0.30-10.0.0.40 (the rationale for this scheme is that floating IPs are sometimes a scarce resource and some tenants do not need floating IPs). Thanks.
Hi Marko, Current design of Neutron gives all tenants floating ips from the same range/CIDR. You can control it by setting different neutron quotas for different tenants. (setting default to 10 to serve B and C while specifically setting A's quotas to 0)
(In reply to yfried from comment #6) > > Current design of Neutron gives all tenants floating ips from the same > range/CIDR. > You can control it by setting different neutron quotas for different tenants. > (setting default to 10 to serve B and C while specifically setting A's > quotas to 0) This sounds like a good approach, so far I'm not aware of any real world scenarios where tenants would actually require certain ranges. Martin, perhaps a sentence or two about this approach could also be added to the docs. Thanks.
Note: OpenStack Networking allocates floating IP addresses to all projects (tenants) from the same IP ranges/CIDRs. Meaning that every subnet of floating IPs is consumable by any and all projects. You can manage this behavior using quotas for specific Projects. For example, you can set the default to '10' for ProjectB and ProjectC, while setting ProjectA's quota to '0'.
Hi @Martin, I posted my version on comment 9.
Updated note will be located here at next docs respin: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux_OpenStack_Platform/6/html-single/Administration_Guide/index.html#IPAddressing