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 = datacentre: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.parameter_defaults: NeutronBridgeMappings: "datacentre:br-ex,tenant:br-tenant"
The
NeutronBridgeMappings
heat parameter associates a physical name (datacentre
) to a bridge (br-ex
).NoteWhen 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.
(undercloud) $ openstack overcloud deploy --templates \ -e [your environment files] -e /home/stack/templates/<custom-environment-file>.yaml
You are ready for the next 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.
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-$external_bridge
patch ports are namedphy-<external bridge name>
(for example, phy-br-ex2). -
In
br-int
patch ports are namedint-<external bridge name>
(for example,int-br-ex2
).
-
In
Procedure
Use
ovs-vsctl
to remove the OVS patch ports associated with the removed bridge mapping entry:# ovs-vsctl del-port br-ex2 datacentre # ovs-vsctl del-port br-tenant tenant
Restart
neutron-openvswitch-agent
:# service neutron-openvswitch-agent restart
11.4.2. Cleaning up OVS patch ports automatically
After removing any OVS bridge mappings, you must also remove the associated patch ports.
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 frombr-int
, cleaning up tunnel ends frombr-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.ImportantPerfoming this step will result in a total networking outage.
# /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
Restore connectivity by redeploying the overcloud.
When you rerun the
openstack overcloud deploy
command, your bridge mapping values are reapplied.NoteAfter 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 tobr-ex2
, andbr-ex2
has some flows on it, removingbr-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