Red Hat SummitChapter 2. Planning a deployment that uses RHOSO dynamic routing
As you plan to implement dynamic routing in your Red Hat OpenStack Services on OpenShift (RHOSO) environment, evaluate the supported features, dependencies, constraints, and necessary network topologies.
The topics included in this section are:
2.1. RHOSO dynamic routing support matrix
The following table lists dynamic routing features supported in Red Hat OpenStack Services on OpenShift (RHOSO) 18.0.
If the feature is not listed, then RHOSO 18.0 does not support the feature.
| Feature | Supported in RHOSO 18.0? |
|---|---|
| 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 RHOSO dynamic routing
Dynamic routing Red Hat OpenStack Services on OpenShift (RHOSO) requires the following network topology and software:
An environment that runs RHOSO version 18.0 or later with:
- ML2/OVN mechanism driver.
- Border Gateway Protocol (BGP) and VIPs configured on a loopback interface.
- OVN BGP agent deployed.
- 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 RHOSO dynamic routing
When planning for dynamic routing in your Red Hat OpenStack Services on OpenShift (RHOSO) environment, consider the following constraints:
- RHOSO dynamic routing does not support the RHOSO Load-balancing service (octavia).
- IPv6 has not been officially tested with dynamic routing.
- In dynamic routing environments, the RHOSO control plane cannot be distributed.
-
In dynamic routing environments, you cannot control which VMs and load balancers (LBs) are exposed. All VMs and LBs that are on provider networks or have Floating IPs are exposed. In addition, if the
expose_tenant_networkflag is enabled, the VMs in project networks are exposed. You should not associate ports from the exposed tenant network with floating IPs because the port private IP addresses are already 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 RHOSO 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 RHOSO 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.
2.4. Sample RHOSO dynamic routing topology
The following diagram illustrates a sample network topology that uses dynamic routing in a Red Hat OpenStack Services on OpenShift (RHOSO) ML2/OVN environment.
Figure 2.1. BGP peering of data plane hosts to leaf routers
- Top of rack (TOR) switch-routers are BGP peers.
- Host to leaf router eBGP peering.
'%20d='M201.5%20305.5c-13.8%200-24.9-11.1-24.9-24.6%200-13.8%2011.1-24.9%2024.9-24.9%2013.6%200%2024.6%2011.1%2024.6%2024.9%200%2013.6-11.1%2024.6-24.6%2024.6zM504%20256c0%20137-111%20248-248%20248S8%20393%208%20256%20119%208%20256%208s248%20111%20248%20248zm-132.3-41.2c-9.4%200-17.7%203.9-23.8%2010-22.4-15.5-52.6-25.5-86.1-26.6l17.4-78.3%2055.4%2012.5c0%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.3%2024.9-24.9s-11.1-24.9-24.9-24.9c-9.7%200-18%205.8-22.1%2013.8l-61.2-13.6c-3-.8-6.1%201.4-6.9%204.4l-19.1%2086.4c-33.2%201.4-63.1%2011.3-85.5%2026.8-6.1-6.4-14.7-10.2-24.1-10.2-34.9%200-46.3%2046.9-14.4%2062.8-1.1%205-1.7%2010.2-1.7%2015.5%200%2052.6%2059.2%2095.2%20132%2095.2%2073.1%200%20132.3-42.6%20132.3-95.2%200-5.3-.6-10.8-1.9-15.8%2031.3-16%2019.8-62.5-14.9-62.5zM302.8%20331c-18.2%2018.2-76.1%2017.9-93.6%200-2.2-2.2-6.1-2.2-8.3%200-2.5%202.5-2.5%206.4%200%208.6%2022.8%2022.8%2087.3%2022.8%20110.2%200%202.5-2.2%202.5-6.1%200-8.6-2.2-2.2-6.1-2.2-8.3%200zm7.7-75c-13.6%200-24.6%2011.1-24.6%2024.9%200%2013.6%2011.1%2024.6%2024.6%2024.6%2013.8%200%2024.9-11.1%2024.9-24.6%200-13.8-11-24.9-24.9-24.9z'/%3e%3c/svg%3e){kind=small}