[openstack-dev] [Openstack-operators] [nova] [neutron] Re: How do your end users use networking?

Neil Jerram Neil.Jerram at metaswitch.com
Wed Jun 17 10:35:05 UTC 2015

Hi Sam,

On 17/06/15 01:31, Sam Morrison wrote:
> We at NeCTAR are starting the transition to neutron from nova-net and neutron almost does what we want.
> We have 10 “public" networks and 10 “service" networks and depending on which compute node you land on you get attached to one of them.
> In neutron speak we have multiple shared externally routed provider networks. We don’t have any tenant networks or any other fancy stuff yet.
> How I’ve currently got this set up is by creating 10 networks and subsequent subnets eg. public-1, public-2, public-3 … and service-1, service-2, service-3 and so on.
> In nova we have made a slight change in allocate for instance [1] whereby the compute node has a designated hardcoded network_ids for the public and service network it is physically attached to.
> We have also made changes in the nova API so users can’t select a network and the neutron endpoint is not registered in keystone.
> That all works fine but ideally I want a user to be able to choose if they want a public and or service network. We can’t let them as we have 10 public networks, we almost need something in neutron like a "network group” or something that allows a user to select “public” and it allocates them a port in one of the underlying public networks.

This begs the question: why have you defined 10 public-N networks, 
instead of just one "public" network?

> I tried going down the route of having 1 public and 1 service network in neutron then creating 10 subnets under each. That works until you get to things like dhcp-agent and metadata agent although this looks like it could work with a few minor changes. Basically I need a dhcp-agent to be spun up per subnet and ensure they are spun up in the right place.

Why the 10 subnets?  Is it to do with where you actually have real L2 
segments, in your deployment?


More information about the OpenStack-dev mailing list