Chapter 11. Configure Bridge Mappings
This chapter describes how to configure bridge mappings in Red Hat OpenStack Platform.
11.1. What are bridge mappings used for?
Bridge mappings allow provider network traffic to reach the physical network. Traffic leaves the provider network from the router’s qg-xxx interface and arrives at br-int. 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.
11.1.1. Configure bridge mappings
Below is an example of a patch-peer between br-int and br-ex:
int-br-ex <-> phy-br-ex
This connection is configured in the bridge_mappings setting. For example:
bridge_mappings = physnet1:br-ex,physnet2:br-ex2
If the bridge_mapping entry is missing, no network connection exists, and communication to physical networks will not work.
This configuration’s first entry creates a connection between br-int and br-ex using patch peer cable. The second entry creates a patch peer for br-ex2.
11.1.2. Configure the controller node
The bridge_mappings configuration must correlate with that of the network_vlan_ranges option on the controller node. For the example given above, the controller node is configured as follows:
network_vlan_ranges = physnet1:10:20,physnet2:21:25
These values create the provider networks that represent the corresponding external networks; the external networks are then connected to the tenant networks via router interfaces. As a result, it is necessary to configure bridge_mappings on the network node on which the router is scheduled. This means that the router traffic is able to egress using the correct physical network, as represented by the provider network (for example: physnet1).
11.1.3. Traffic flow
In addition to creating the connection, this setting also configures the OVS flow in br-int and br-ex to allow the network traffic to traverse to and from the external network. Each external network is represented by an internal VLAN id, which is tagged to the router’s 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 external network arrives on br-ex and is moved to br-int using phy-br-ex <→ int-br-ex. When the packet reaches int-br-ex, another flow in br-int adds internal vlan tag to the packet. This allows the packet to be accepted by qg-xxx.
11.2. Maintaining Bridge Mappings
After removing any mappings, a subsequent patch-port cleanup is required. This action ensures that the bridge configuration is cleared of erroneous entries, with two options available for performing this task:
- Manual port cleanup - requires careful removal of the superfluous ports. No outage is required to network connectivity.
- Automated port cleanup using neutron-ovs-cleanup - performs an automated cleanup, but requires an outage, and requires that the necessary mappings be re-added. Choose this option if you don’t mind having an outage to network connectivity.
Examples are given below for each of these two options:
11.2.1. Manual port cleanup
The manual port cleanup process removes unneeded ports, and doesn’t require a system outage. You can identify these ports by their naming convention: in br-$external_bridge they are named as "phy-"$external_bridge and in br-int they are named "int-"$external_bridge.
This example procedure removes a bridge from bridge_mappings, and cleans up the corresponding ports. 1. Edit openvswitch_agent.ini and remove the entry for physnet2:br-ex2 from bridge_mappings:
bridge_mappings = physnet1:br-ex,physnet2:br-ex2
Remove the entry for physnet2:br-ex2. The resulting bridge_mappings resembles this:
bridge_mappings = physnet1:br-ex
2. Use ovs-vsctl to remove the patch ports associated with the removed physnet2:br-ex2 entry:
# ovs-vsctl del-port br-ex2 phy-br-ex2 # ovs-vsctl del-port br-int int-br-ex2
If the entire bridge_mappings entry is removed or commented out, cleanup commands will need to be run for each entry,
3. Restart neutron-openvswitch-agent:
# service neutron-openvswitch-agent restart
11.2.2. Automated port cleanup using ‘neutron-ovs-cleanup’
This action is performed using the neutron-ovs-cleanup command combined with the --ovs_all_ports flag. Restart the neutron services or the entire node to then restore the bridges back to their normal working state. This process requires a total networking outage.
The neutron-ovs-cleanup command unplugs all ports (instances, qdhcp/qrouter, among others) from all OVS bridges. Using the flag --ovs_all_ports results in removing all ports from br-int, cleaning up tunnel ends from br-tun, and patch ports from bridge to bridge. In addition, the physical interfaces (such as eth0, eth1) are removed from the bridges (such as br-ex, br-ex2). This will result in lost connectivity to instances until the ports are manually re-added using ovs-vsctl:
# ovs-vsctl add-port br-ex eth1
11.2.2.1. Example usage of neutron-ovs-cleanup:
1. Make a backup of your bridge_mapping entries as found in openvswitch_agent.ini.
2. Run neutron-ovs-cleanup with the --ovs_all_ports flag. Note that 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
3. Restart these OpenStack Networking services:
# systemctl restart neutron-openvswitch-agent # systemctl restart neutron-l3-agent.service # systemctl restart neutron-dhcp-agent.service
4. Restore connectivity by re-adding the bridge_mapping entries to openvswitch_agent.ini.
5. Restart the neutron-openvswitch-agent service:
# systemctl restart neutron-openvswitch-agent
When the OVS agent restarts, it doesn’t touch any connections which 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 it from the bridge_mappings configuration (or commenting it out entirely) won’t disconnect the two bridges, no matter what you do (whether restarting the service, or the node).
