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 <ignaziocass...@gmail.com> Date: Wednesday, April 19, 2017 at 1:06 PM To: Dan Sneddon <dsned...@redhat.com> Cc: OpenStack Operators <openstack-operators@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" <dsned...@redhat.com<mailto:dsned...@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 dsned...@redhat.com<mailto:dsned...@redhat.com> | redhat.com/openstack<http://redhat.com/openstack> dsneddon:irc | @dxs:twitter
_______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators