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: RHOSP dynamic routing support matrix Requirements for RHOSP dynamic routing Constraints for RHOSP dynamic routing Sample RHOSP dynamic routing topology 2.1. RHOSP dynamic routing support matrix The following table lists dynamic routing features supported in Red Hat OpenStack Platform (RHOSP) 17.1. Note If the feature is not listed, then RHOSP 17.1 does not support the feature. Table 2.1. RHOSP dynamic routing feature support matrix 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_network flag 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. Note The ports on these nodes are referred to as the chassisredirect logical 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-agent adds 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. Note The topology shown in this diagram is a only sample. There there are many ways to configure your topology. For example, you might decide to use a unique ASN for each rack. Figure 2.1. BGP peering of overcloud hosts to leaf routers

Commands: