Open Stack

We handle this a different way, I want to look to see if we can redo it, so it requires less pre-configuration on the host.  However, this is what we currently do (and have been doing for ~4 years):
http://www.dorm.org/blog/wp-content/uploads/2015/10/ovs-wiring-676x390.png

From there inside neutron ml2.  You just specify bridge mapping entries for br<vlan>:<flat_network_name_in_neutron>.

We have the HV vlan being the native vlan.  However, you can simply change to the config for mgmt0 to have tag=<hv vlan>.  If I were to change this I would think about using vlan networks instead of flat networks for everything VM related.  So that OVS, would create the vlan specific interfaces, instead of us doing it ahead of time and telling neutron to use what we created.


Under redhat we use the following network-scripts to make this happen on boot:
/etc/sysconfig/network-scripts/ifcfg-eth0:
DEVICE=eth0
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
# The next 2 lines are required on first
# boot to work around some kudzu stupidity.
ETHTOOL_OPTS="wol g autoneg on"
HWADDR=F0:4D:A2:0A:E4:26
unset HWADDR

/etc/sysconfig/network-scripts/ifcfg-eth2:
DEVICE=eth2
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
ETHTOOL_OPTS="wol g autoneg on"
# The next 2 lines are required on first
# boot to work around some kudzu stupidity.
HWADDR=F0:4D:A2:0A:E4:2A
unset HWADDR

/etc/sysconfig/network-scripts/ifcfg-bond0:
DEVICE=bond0
TYPE=OVSBond
DEVICETYPE=ovs
USERCTL=no
ONBOOT=yes
BOOTPROTO=none
BOND_IFACES="eth0 eth2"
OVS_BRIDGE=br-ext
OVS_EXTRA="set interface eth0 other-config:enable-vlan-splinters=true -- set interface eth2 other-config:enable-vlan-splinters=true"
/etc/sysconfig/network-scripts/ifcfg-br-ext:
DEVICE=br-ext
TYPE=OVSBridge
DEVICETYPE="ovs"
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
BOOTPROTO=static

/etc/sysconfig/network-scripts/ifcfg-mgmt0:
DEVICE=mgmt0
TYPE=OVSIntPort
DEVICETYPE="ovs"
ONBOOT=yes
USERCTL=no
OVS_OPTIONS="vlan_mode=native-untagged"
OVS_EXTRA=""
OVS_BRIDGE=br-ext
IPADDR=<compute node IP>
NETMASK=<netmask>

/etc/sysconfig/network-scripts/ifcfg-ext-vlan-499:
DEVICE=ext-vlan-499
TYPE=OVSPort
DEVICETYPE="ovs"
ONBOOT=yes
USERCTL=no
OVS_OPTIONS="tag=499"
OVS_EXTRA="set interface $DEVICE type=patch -- set interface $DEVICE options:peer=br499-ext"
OVS_BRIDGE=br-ext
/etc/sysconfig/network-scripts/ifcfg-br499-ext:
DEVICE=br499-ext
TYPE=OVSIntPort
DEVICETYPE="ovs"
ONBOOT=yes
USERCTL=no
OVS_EXTRA="set interface $DEVICE type=patch -- set interface $DEVICE options:peer=ext-vlan-499"
OVS_BRIDGE=br499
/etc/sysconfig/network-scripts/ifcfg-br499:
DEVICE=br499
TYPE=OVSBridge
DEVICETYPE="ovs"
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
/etc/sysconfig/network-scripts/ifcfg-ext-vlan-500:
DEVICE=ext-vlan-500
TYPE=OVSPort
DEVICETYPE="ovs"
ONBOOT=yes
USERCTL=no
OVS_OPTIONS="tag=500"
OVS_EXTRA="set interface $DEVICE type=patch -- set interface $DEVICE options:peer=br500-ext"
OVS_BRIDGE=br-ext
/etc/sysconfig/network-scripts/ifcfg-br500-ext:
DEVICE=br500-ext
TYPE=OVSIntPort
DEVICETYPE="ovs"
ONBOOT=yes
USERCTL=no
OVS_EXTRA="set interface $DEVICE type=patch -- set interface $DEVICE options:peer=ext-vlan-500"
OVS_BRIDGE=br500
/etc/sysconfig/network-scripts/ifcfg-br500:
DEVICE=br500
TYPE=OVSBridge
DEVICETYPE="ovs"
BOOTPROTO=none
ONBOOT=yes
USERCTL=no
/etc/sysconfig/network-scripts/ifcfg-br-int:
DEVICE=br-int
TYPE=OVSBridge
DEVICETYPE="ovs"
BOOTPROTO=none
ONBOOT=yes
USERCTL=no


___________________________________________________________________
Kris Lindgren
Senior Linux Systems Engineer
GoDaddy

From: Ignazio Cassano <ignaziocassano at gmail.com>
Date: Wednesday, April 19, 2017 at 1:06 PM
To: Dan Sneddon <dsneddon at redhat.com>
Cc: OpenStack Operators <openstack-operators at lists.openstack.org>
Subject: Re: [Openstack-operators] Openvswitch flat and provider in the same bond

Hi Dan, on the physical  switch the 567 is not the native vlan but is tagged like 555 and 556.
I know I could set 567 as a native vlan to receive it untagged.
But if I would like more than one flat network ?
I am not skilled in networking but I think only one native vlan can be set in switch.
Any further solution or suggestion ?
Regards
Ignazio

Il 19/Apr/2017 20:19, "Dan Sneddon" <dsneddon at redhat.com<mailto:dsneddon at redhat.com>> ha scritto:
On 04/19/2017 09:02 AM, Ignazio Cassano wrote:
> Dear All,  in my openstack Newton installation compute e controllers
> node have e separate management network nic and a lacp bond0 where
> provider vlan (555,556) and flat vlan (567) are trunked.
> Since I cannot specify the vlan id (567) when I create a flat network, I
> need to know how I can create the bridge for flat network in openvswitch.
> For providers network I created a bridge br-ex and added bond0 to that
> bridge and configured openvswitch agent and ml2 for mapping br-ex.
> I don't know what can I do for flat network : must I create another
> bridge ? What interface I must add to the bridge for flat (567) network ?
> I configured the same scenario with linuxbridge mechanism driver  and it
> seems more easy to do.
> Sorry for my bad english.
> Regards
> Ignazio
I assume that the VLAN 567 is the native (untagged) VLAN on the port in
question? If that's so, you can do the following:

Create two provider networks of "provider:network_type vlan", plus one
provider network with "provider:network_type flat", with all three using
the same physical network.


neutron net-create --provider:physical_network datacentre \
--provider:network_type vlan --provider:segmentation_id 555 \
--shared <net-name1>

neutron net-create --provider:physical_network datacentre \
--provider:network_type vlan --provider:segmentation_id 556 \
--shared <net-name2>

neutron net-create --provider:physical_network datacentre \
--provider:network_type flat --shared <net-name3>


Of course, remove shared if you don't want tenants directly attaching to
any of the above networks, and add "--router:external" if any of these
are to be used for SNAT/floating IP.

--
Dan Sneddon         |  Senior Principal Software Engineer
dsneddon at redhat.com<mailto:dsneddon at redhat.com> |  redhat.com/openstack<http://redhat.com/openstack>
dsneddon:irc        |  @dxs:twitter

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20170419/c49b5be5/attachment.html>