[ovn] safely change bridge_mappings

Rodolfo Alonso Hernandez ralonsoh at redhat.com
Mon Mar 13 10:27:45 UTC 2023


Hi Tomáš:

The ml2 config option "bridge_mappings" is used by ML2/OVS. The mechanism
driver ML2/OVN read this config from the local OVS DB, reading the
"ovn-bridge-mappings"
option from the Open vSwitch register. In other words, this is not needed
in ML2/OVN.

NeutronFlatNetworks --> ml2_type_flat.flat_networks
NeutronNetworkVLANRanges --> ml2_type_vlan.network_vlan_ranges
NeutronBridgeMappings --> that will set "ovn_bridge_mappings" on the OVS
register during the installation (when using ML2/OVN)

Regards.


On Sat, Mar 11, 2023 at 12:02 AM Tomáš Bredár <tomas.bredar at gmail.com>
wrote:

>   Hi Rodolfo,
>
> you helped a lot. I managed configure this, manually. Just for future
> reference let me write down what I did.
> - First I already had the interface br-ex2 configured and correctly
> assigned physical interfaces in it
> - I added the bridge mappings to the OVN DB:
> ovs-vsctl set open .
> external-ids:ovn-bridge-mappings=datacentre:br-ex,m-storage:br-ex2
>
> - I added my nw m-storage to ml2_conf.ini:
> [ml2_type_vlan]
> network_vlan_ranges=datacentre:1:2700,m-storage:3700:4000
>
> [ml2_type_flat]
> flat_networks=datacentre,m-storage
>
> - I restarted the neutron service
> - since I already had the m-storage nw created in openstack, but as
> provider "datacenter" and I already had instance ports using it (but it was
> not working), I had to create a new network and subnet. Delete the original
> ports and recreate and reassign it to the instances.
>
> If I may, now I have two questions:
> 1. Shouldn't I also define this in ml2_conf.ini
> [ovs]
> bridge_mappings = datacentre:br-ex,m-storage:br-ex2
>
> or is the setting of the vswitch register via ovs-vsctl persistent between
> redeployments or reboots?
>
> 2. Which parameters in tripleo-heat-templates sets the above ml2_conf.ini?
> I found these params:
> NeutronFlatNetworks
> NeutronNetworkVLANRanges
> NeutronBridgeMappings
>
> Thanks for your help
>
> Tomas
>
>
> ut 7. 3. 2023 o 10:13 Rodolfo Alonso Hernandez <ralonsoh at redhat.com>
> napísal(a):
>
>> Hello Tomáš:
>>
>> You need to follow the steps in [1]:
>> * You need to create the new physical bridge "br-ex2".
>> * Then you need to add to the bridge the physical interface.
>> * In the compute node you need to add the bridge mappings to the OVN
>> database Open vSwitch register
>> * In the controller, you need to add the reference for this second
>> provider network in "flat_networks" and "network_vlan_ranges" (in the
>> ml2.ini file). Then you need to restart the Neutron server to read these
>> new parameters (this step is not mentioned in this link).
>>   $ cat ./etc/neutron/plugins/ml2/ml2_conf.ini
>>   [ml2_type_flat]
>>   flat_networks = public,public2
>>   [ml2_type_vlan]
>>   network_vlan_ranges = public:11:200,public2:11:200
>>
>> Regards.
>>
>> [1]
>> https://docs.openstack.org/networking-ovn/pike/admin/refarch/provider-networks.html
>>
>> On Tue, Mar 7, 2023 at 12:33 AM Tomáš Bredár <tomas.bredar at gmail.com>
>> wrote:
>>
>>> Hi,
>>>
>>> I have a running production OpenStack deployment - version Wallaby
>>> installed using TripleO. I'm using the default OVN/OVS networking.
>>> For provider networks I have two bridges on the compute nodes br-ex and
>>> br-ex2. Instances mainly use br-ex for provider networks, but there are
>>> some instances which started using a provider network which should be
>>> mapped to br-ex2, however I didn't specify "bridge_mappings" on
>>> ml2_conf.ini, so the traffic wants to flow through the default
>>> datacentre:br-ex.
>>> My questions is, what services should I restart on the controller and
>>> compute nodes after defining bridge_mappings in [ovs] in ml2_conf.ini. And
>>> if this operation is safe and if the instances already using br-ex will
>>> lose connectivity?
>>>
>>> Thanks for your help
>>>
>>> Tomas
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230313/fdd7a001/attachment.htm>


More information about the openstack-discuss mailing list