Bug 1163726

Summary:	[Doc] Misleading guidance for Neutron external network
Product:	Red Hat OpenStack	Reporter:	Marko Myllynen <myllynen>
Component:	documentation	Assignee:	Martin Lopes <mlopes>
Status:	CLOSED CURRENTRELEASE	QA Contact:	RHOS Documentation Team <rhos-docs>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	5.0 (RHEL 7)	CC:	chrisw, mlopes, myllynen, nyechiel, oblaut, tfreger, yeylon, yfried
Target Milestone:	---	Keywords:	Documentation
Target Release:	6.0 (Juno)
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2015-03-18 01:10:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1199866

Description Marko Myllynen 2014-11-13 11:04:43 UTC

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

Comment 3 yfried 2014-12-24 12:12:40 UTC

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.

Comment 4 Nir Yechiel 2014-12-24 12:27:53 UTC

Hi Martin,

Can you please take a look at this from docs perspective?

Thanks,
Nir

Comment 5 Marko Myllynen 2014-12-30 11:09:06 UTC

(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.

Comment 6 yfried 2014-12-30 12:53:15 UTC

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)

Comment 7 Marko Myllynen 2014-12-30 13:08:13 UTC

(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.

Comment 9 yfried 2015-03-03 07:12:10 UTC

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'.

Comment 10 yfried 2015-03-03 07:13:11 UTC

Hi @Martin,
I posted my version on comment 9.

Comment 13 Martin Lopes 2015-03-18 01:10:59 UTC

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