Allow operators to provision multiple physical networks

Bug #1626259 reported by OpenStack Infra on 2016-09-21
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
Your project "openstack/kolla" is set up so that we directly report the documentation bugs against it. If this needs changing, the docimpact-group option needs to be added for the project. You can ask the OpenStack infra team (#openstack-infra on freenode) for help if you need to.

commit d1673ad173ea96c0e018946f54caa99776855cc1
Author: Paul Bourke <email address hidden>
Date: Tue Sep 20 17:07:55 2016 +0100

    Allow operators to provision multiple physical networks

    Currently Kolla operators are restricted to configuring one physical
    network (physnet1).

    This change along with ml2_conf.ini augmentation can be used to setup
    multiple physical networks in openvswitch.

    E.g. To configure two physical networks, physnet1 and physnet2, with
    ports eth1 and eth2 associated respectively:

    In /etc/kolla/globals.yml, set

    neutron_bridge_name: "br-ex,br-ex2"
    neutron_external_interface: "eth1,eth2"

    In /etc/kolla/config/neutron/ml2_conf.ini

    bridge_mappings = physnet1:br-ex,physnet2:br-ex2

    Co-Authored-By: Mick Thompson <email address hidden>
    Closes-Bug: #1625700

    Change-Id: I9454ca98d9b058368129123109ccc56f95519874

Tags: doc Edit Tag help
Changed in kolla:
status: New → Confirmed
importance: Undecided → Low
importance: Low → Wishlist
milestone: none → ocata-1
Changed in kolla:
milestone: ocata-1 → ocata-2
Changed in kolla:
milestone: ocata-2 → ocata-3
Chris L (onyx4) wrote :

Is there a way currently to manually do this?

For example can I create the br-ex2 bridge manually in the OVS container on each compute and controller and add the port for eth2 ?

Then use the /etc/kolla/config to propagate the changes that you described.

Will the OVS changes be permanent or we would need a way to re-create the br-ex2 after a restart?

I already have SRIOV working on my setup for internal networks with VLAN tagging (segmentation ID), but I'm trying to find a way for hosts on virtIO to get on the same network using VLAN provider but on an internal interface instead of the external bridge interface used for Internet access.


Mark Goddard (mgoddard) wrote :

If you add this to globals.yml:

neutron_bridge_name: "br-ex,br-ex2"
neutron_external_interface: "eth1,eth2"

Then all you need to do is ensure that eth1 and eth2 exist. Kolla ansible will handle creating the br-ex and br-ex2 bridges and plugging eth1 and eth2 into them.

Chris L (onyx4) wrote :

Thanks for your response, I will try that right away.

If an interface is used for SRIOV with many VF created, can we use the PF itself for VirtIO for VLAN based provider network, or would I need to create a veth pair and put the PF into a linux bridge along with one of the veth since OVS takes over the whole port. I'm trying to not have to use another physical port if possible that I could share for SRIOV VF and VirtIO based VLAN provider network.

Some of my compute nodes have ens3 or ens1, I assume this cannot be a bridge interface since it will be taken over by OVS for Neutron, how do we map to different interfaces for different compute hosts again?


Mark Goddard (mgoddard) wrote :

I'm not sure about using the PF - you would need to test this. If it does not work, could you use a VF instead?

If I need to use the same network for non-neutron traffic (e.g. a control plane VLAN), I typically use the method you described - create a bridge with a veth pair between it and OVS. Kayobe (which uses kolla ansible) provides automation for this. More info here:

If you have different interfaces on different hosts, use host_vars or group_vars instead of globals.yml to define the variable.

tags: removed: kolla
David Rabel (rabel-b1) wrote :

Am I right, that this feature has been implemented two years ago and this bug report is only for the documentation?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers