Chapter 11. Configuring bridge mappings This chapter contains information about configuring bridge mappings in Red Hat OpenStack Platform. 11.1. Overview of bridge mappings A bridge mapping associates a physical network name (an interface label) to a bridge created with OVS or OVN. In this example, the physical name (datacentre) is mapped to the external bridge (br-ex): Bridge mappings allow provider network traffic to reach the physical network. Traffic leaves the provider network from the qg-xxx interface of the router and arrives at br-int . For OVS, a patch port between br-int and br-ex then allows the traffic to pass through the bridge of the provider network and out to the physical network. OVN creates a patch port on a hypervisor only when there is a VM bound to the hypervisor that requires the port. You configure bridge mappings on the network node on which the router is scheduled. Router traffic can egress using the correct physical network, as represented by the provider network. 11.2. Traffic flow Each external network is represented by an internal VLAN ID, which is tagged to the router qg-xxx port. When a packet reaches phy-br-ex , the br-ex port strips the VLAN tag and moves the packet to the physical interface and then to the external network. The return packet from the external network arrives on br-ex and moves to br-int using phy-br-ex <-> int-br-ex . When the packet is going through br-ex to br-int , the packet's external vlan ID is replaced by an internal vlan tag in br-int , and this allows qg-xxx to accept the packet. In the case of egress packets, the packet's internal vlan tag is replaced with an external vlan tag in br-ex (or in the external bridge that is defined in the network_vlan_ranges parameter). 11.3. Configuring bridge mappings Red Hat OpenStack Platform (RHOSP) director uses predefined NIC templates to install and configure your initial networking configuration. You can customize aspects of your initial networking configuration, such as bridge mappings, by using the NeutronBridgeMappings parameter in a customized environment file. You call the environment file in the openstack overcloud deploy command. Prerequisites You must configure bridge mappings on the network node on which the router is scheduled. For both ML2/OVS and ML2/OVN DVR configurations, you must configure bridge mappings for the compute nodes, too. Procedure Create a custom environment file and add the NeutronBridgeMappings heat parameter with values that are appropriate for your site. The NeutronBridgeMappings heat parameter associates a physical name ( datacentre ) to a bridge ( br-ex ). Note When the NeutronBridgeMappings parameter is not used, the default maps the external bridge on hosts (br-ex) to a physical name (datacentre). To apply this configuration, deploy the overcloud, adding your custom environment file to the stack along with your other environment files. You are ready for the steps, which are the following: Using the network VLAN ranges, create the provider networks that represent the corresponding external networks. (You use the physical name when creating neutron provider networks or floating IP networks.) Connect the external networks to your project networks with router interfaces. Additional resources Network environment parameters in the Advanced Overcloud Customization guide Including Environment Files in Overcloud Creation in the Advanced Overcloud Customization guide 11.4. Maintaining bridge mappings for OVS After removing any OVS bridge mappings, you must perform a subsequent cleanup to ensure that the bridge configuration is cleared of any associated patch port entries. You can perform this operation in the following ways: Manual port cleanup - requires careful removal of the superfluous patch ports. No outages of network connectivity are required. Automated port cleanup - performs an automated cleanup, but requires an outage, and requires that the necessary bridge mappings be re-added. Choose this option during scheduled maintenance windows when network connectivity outages can be tolerated. Note When OVN bridge mappings are removed, the OVN controller automatically cleans up any associated patch ports. 11.4.1. Cleaning up OVS patch ports manually After removing any OVS bridge mappings, you must also remove the associated patch ports. Prerequisites The patch ports that you are cleaning up must be Open Virtual Switch (OVS) ports. A system outage is not required to perform a manual patch port cleanup. You can identify the patch ports to cleanup by their naming convention: In br-USDexternal_bridge patch ports are named phy-<external bridge name> (for example, phy-br-ex2). In br-int patch ports are named int-<external bridge name> (for example, int-br-ex2 ). Procedure Use ovs-vsctl to remove the OVS patch ports associated with the removed bridge mapping entry: Restart neutron-openvswitch-agent : 11.4.2. Cleaning up OVS patch ports automatically After removing any OVS bridge mappings, you must also remove the associated patch ports. Note When OVN bridge mappings are removed, the OVN controller automatically cleans up any associated patch ports. Prerequisites The patch ports that you are cleaning up must be Open Virtual Switch (OVS) ports. Cleaning up patch ports automatically with the neutron-ovs-cleanup command causes a network connectivity outage, and should be performed only during a scheduled maintenance window. Use the flag --ovs_all_ports to remove all patch ports from br-int , cleaning up tunnel ends from br-tun , and patch ports from bridge to bridge. The neutron-ovs-cleanup command unplugs all patch ports (instances, qdhcp/qrouter, among others) from all OVS bridges. Procedure Run the neutron-ovs-cleanup command with the --ovs_all_ports flag. Important Perfoming this step will result in a total networking outage. Restore connectivity by redeploying the overcloud. When you rerun the openstack overcloud deploy command, your bridge mapping values are reapplied. Note After a restart, the OVS agent does not interfere with any connections that are not present in bridge_mappings. So, if you have br-int connected to br-ex2 , and br-ex2 has some flows on it, removing br-int from the bridge_mappings configuration does not disconnect the two bridges when you restart the OVS agent or the node. Additional resources Network environment parameters in the Advanced Overcloud Customization guide Including Environment Files in Overcloud Creation in the Advanced Overcloud Customization guide

Commands:
bridge_mappings = datacentre:br-ex
parameter_defaults: NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"
(undercloud) USD openstack overcloud deploy --templates -e [your environment files] -e /home/stack/templates/<custom-environment-file>.yaml
ovs-vsctl del-port br-ex2 datacentre ovs-vsctl del-port br-tenant tenant
service neutron-openvswitch-agent restart
/usr/bin/neutron-ovs-cleanup --config-file /etc/neutron/plugins/ml2/openvswitch_agent.ini --log-file /var/log/neutron/ovs-cleanup.log --ovs_all_ports