Search
SupportConsoleDevelopersStart a trialContact

Chapter 11. Configuring bridge mappings

download PDF

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

  1. 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).

    Note

    When the NeutronBridgeMappings parameter is not used, the default maps the external bridge on hosts (br-ex) to a physical name (datacentre).

  2. 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

  3. You are ready for the next steps, which are the following:

    1. 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.)
    2. Connect the external networks to your tenant networks with router interfaces.

Additional resources

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-$external_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

  1. 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

  2. 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.

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

  1. Run the neutron-ovs-cleanup command with the --ovs_all_ports flag.

    Important

    Perfoming 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

  2. 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

Red Hat logoGithubRedditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

© 2024 Red Hat, Inc.