Ce contenu n'est pas disponible dans la langue sélectionnée.
Chapter 2. Planning a deployment that uses RHOSP dynamic routing
As you plan to implement dynamic routing in your Red Hat OpenStack Platform environment, evaluate the supported features, dependencies, constraints, and necessary network topologies.
The topics included in this section are:
2.1. RHOSP dynamic routing support matrix
The following table lists dynamic routing features supported in Red Hat OpenStack Platform (RHOSP) 17.1.
If the feature is not listed, then RHOSP 17.1 does not support the feature.
| Feature | Supported in RHOSP 17.1? |
|---|---|
| Kernel routing | Yes |
| IPv6 | Yes |
| EVPN | No |
| OVS-DPDK routing | No |
| SR-IOV routing | No |
| Overlapping CIDRs | No |
| Selective exposure for floating IPs | No |
2.2. Requirements for RHOSP dynamic routing
Dynamic routing Red Hat OpenStack Platform (RHOSP) requires the following network topology and software:
- A spine-leaf network topology.
An environment that runs RHOSP version 17.0 or later with:
- ML2/OVN mechanism driver.
- Border Gateway Protocol (BGP) and VIPs configured on the RHOSP undercloud on a loopback interface.
- OVN BGP agent deployed on the RHOSP overcloud.
- The network devices that peer with BGP must have an implementation of BGP installed. BGP is standard on most devices, and provided by the device vendor.
2.3. Constraints for RHOSP dynamic routing
When planning for dynamic routing in your Red Hat OpenStack Platform (RHOSP) environment, consider the following constraints:
-
You cannot control which VMs and load balancers (LBs) are exposed. All VMs and LBs on that are on provider networks or haveFloating IPs are exposed. In addition, if the
expose_tenant_networkflag is enabled, the VMs in project networks are exposed. - You must use address scopes and subnet pools because there is no support for overlapping CIDRs.
- BGP steers network traffic by using kernel routing through IP routes and rules. For this reason, OVS-DPDK, which does not use the kernel space, is not supported.
In RHOSP networking, for the router connecting the load-balancer members to the provider network, the north-south traffic to OVN-octavia VIPs on the provider or the FIPs associated with the VIPs on project networks must go through the networking nodes that host the neutron router gateway.
NoteThe ports on these nodes are referred to as the
chassisredirectlogical router ports (cr-lrp).For this reason, the entry point into the OVN overlay needs to be one of those networking nodes, and consequently the VIPs and the FIPs to VIPs are exposed through these nodes. From the networking nodes, the traffic follows the normal tunneled path (Geneve tunnel) to the RHOSP Compute node where the selected member is located.
- There is currently a known issue where forwarding to ports on floating IP (FIP) addresses fail. Instead, the network traffic intended for the FIPs is being forwarded to a tenant port IP address that is contained on the list of ports configured to perform the port forwarding. The cause for this failure is that the OVN BGP agent is not exposing routes to FIPs. Currently, there is no workaround. For more information, see BZ 2160481.
- There is currently a known issue where the Red Hat OpenStack Platform Compute service cannot route packets sent to a multicast IP address destination. Therefore, VM instances subscribed to a multicast group fail to receive the packets sent to them. The cause is that BGP multicast routing is not properly configured on the overcloud nodes. Currently, there is no workaround. For more information, see BZ 2163477.
During updates between two RHOSP 17.1 versions there is connectivity downtime because the FRR component on every node must be restarted, and the following events occur:
- Each node reestablishes the BGP session with its peer routers, which affects both control plane and data plane traffic.
- After the BGP session is reestablished, FRR obtains and re-advertises the routes to and from the node, which means that the routes are unavailable for a few seconds.
-
Finally, the
ovn-bgp-agentadds the VRF configuration to the running FRR service to advertise routes for data plane traffic by using BGP.
- When adding storage nodes to a RHOSP dynamic environment, you must use the provisioning network. RHOSP director requires Red Hat Ceph Storage to be present before the routers that establish connectivity are created.
2.4. Sample RHOSP dynamic routing topology
The following diagram illustrates a sample network topology that uses dynamic routing in a Red Hat OpenStack Platform (RHOSP) ML2/OVN environment.
This sample network topology shows a spine with three leaves. The top of rack switch-routers are BGP peers with the switches on the spine.
Figure 2.1. BGP peering of overcloud hosts to leaf routers
