[openstack-dev] [devstack] [neutron] A larger batch of questions about configuring DevStack to use Neutron

Sean M. Collins sean at coreitpro.com
Tue Oct 6 16:41:54 UTC 2015

On Tue, Oct 06, 2015 at 11:25:03AM EDT, Mike Spreitzer wrote:
> [Sorry, but I do not know if the thundering silence is because these 
> questions are too hard, too easy, grossly off-topic, or simply because 
> nobody cares.]

You sent your first e-mail on a Saturday. I saw it and flagged it for
reply, but have not had a chance yet. It's only Tuesday. I do care and
your questions are important. I will say though that it's a little
difficult to answer your e-mail because of formatting and your thoughts
seem to jump around. This is not intended as a personal criticism, it's
just a little difficult to follow your e-mail in order to reply.

> In the section 
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
> there is a helpful display of localrc contents.  It says, among other 
> things,
>        OVS_PHYSICAL_BRIDGE=br-ex
>        PUBLIC_BRIDGE=br-ex
> In the next top-level section, 
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces
> , there is no display of revised localrc contents and no mention of 
> changing either bridge setting.  That is an oversight, right?

No, this is deliberate. Each section is meant to be independent, since
each networking configuration and corresponding DevStack configuration
is different. Of course, this may need to be explicitly stated in the
guide, so there is always room for improvement. For example, There needs
to be some editing done for that doc - the part about disabling the
firewall is just dropped in the middle of the doc and breaks the flow -
among other things. This is obviously not helpful to a new reader and we
need to fix.

> I am 
> guessing I need to set OVS_PHYSICAL_BRIDGEand PUBLIC_BRIDGEto different 
> values, and the exhibited `ovs-vsctl` commands in this section apply to 
> $OVS_PHYSICAL_BRIDGE.  Is that right?  Are there other revisions I need to 
> make to localrc?

No, this is not correct.

What does your networking layout look like on the DevStack node that you
are trying to configure?

> Looking at 
> http://docs.openstack.org/networking-guide/scenario_legacy_ovs.html(or, in 
> former days, the doc now preserved at 
> http://docs.ocselected.org/openstack-manuals/kilo/networking-guide/content/under_the_hood_openvswitch.html
> ) I see the name br-ex used for $PUBLIC_BRIDGE--- not $OVS_PHYSICAL_BRIDGE
> , right?  Wouldn't it be less confusing if 
> http://docs.openstack.org/developer/devstack/guides/neutron.htmlused a 
> name other than "br-ex" for the exhibited commands that apply to 

No, this is deliberate - br-ex is the bridge that is used for external
network traffic - such as floating IPs and public IP address ranges. On
the network node, a physical interface is attached to br-ex so that
traffic will flow.

PUBLIC_BRIDGE is a carryover from DevStack's Nova-Network support and is
used in some places, with OVS_PHYSICAL_BRIDGE being used by DevStack's
Neutron support, for the Open vSwitch driver specifically. They are two
variables that for the most part serve the same purpose. Frankly,
DevStack has a lot of problems with configuration knobs, and

> The section 
> http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch
> builds on 
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-multiple-interfaces
> NOT 
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
> --- right?  Could I stop after reading that section, or must I go on to 
> http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks

See my previous statement - each section is supposed to be independent.

> ?
> The exhibited localrc contents in section 
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
> include both of these:
>        Q_L3_ENABLED=True

Yes they do. They are there for a reason, it's how to configure DevStack
in such a way that you end up with a network configuration in Neutron
that fits the diagram that is shown in the section.

> and nothing gainsays either of them until section 
> http://docs.openstack.org/developer/devstack/guides/neutron.html#neutron-networking-with-open-vswitch-and-provider-networks
> --- where we first see
>        Q_L3_ENABLED=False
> Is it true that all the other sections want both Q_L3_ENABLEDand 

No. If they are omitted from the other sections, that is intentional.

> I tried adding IPv6 support to the recipe of the first section (
> http://docs.openstack.org/developer/devstack/guides/neutron.html#using-neutron-with-a-single-interface
> ).  I added this to my localrc:
>         IP_VERSION=4+6
>         IPV6_PUBLIC_RANGE=fddf:2::/64
>         IPV6_PUBLIC_NETWORK_GATEWAY=fddf:2::1
>         IPV6_ROUTER_GW_IP=fddf:2::231
> At first I had tried setting a different set of IPv6 variables (having 
> only IP_VERSION in common with what I exhibit here), but found those: (a) 
> duplicated the defaults and (b) caused problems due to lack of the ones I 
> mention here.  Even the ones mentioned here led to a problem.  There is a 
> bit of scripging that replaces my setting for IPV6_ROUTER_GW_IP with 
> something dug out of Neutron.  That went wrong.  It replaced my setting 
> with fddf:2::2, but that address was already in use by something else.

OK - I'm not sure what your networking layout is like on your DevStack
node, and frankly I think we need to back up and determine that before
we go into IPv6.

Sean M. Collins

More information about the OpenStack-dev mailing list