Dynamic routing

Red Hat OpenStack Services on OpenShift (RHOSO) supports ML2/OVN dynamic routing with border gateway protocol (BGP). RHOSO dynamic routing provides a mechanism for load balancing and high availability which differs from the traditional approaches employed by most internet service providers today.

With RHOSO dynamic routing you can expose IP addresses for VMs and load balancers on provider networks during creation and startup or whenever they are associated with a floating IP address. The same functionality is available on project networks, when a special flag is set.

RHOSO dynamic routing also provides these benefits:

  • Improved management of data plane traffic.
  • Simplified configuration with fewer differences between roles.
  • Distributed L2 provider VLANs and floating IP (FIP) subnets across L3 boundaries with no requirement to span VLANs across racks for non-overlapping CIDRs only.
  • Failover of the whole subnet for public provider IPs or FIPs from one site to another.
  • Next-generation data center and hyperscale fabric support.

BGP components for dynamic routing
Copy link

Red Hat OpenStack Services on OpenShift (RHOSO) relies on several components to provide dynamic routing to the Layer 3 data center.

Figure 1. RHOSO dynamic routing components

RHOSO dynamic routing components

OVN agent (ovn_agent container)
A Python-based daemon that runs in the ovn_agent container on each Compute and Networker node. The agent monitors the Open Virtual Network (OVN) northbound database for certain VM and floating IP (FIP) events. When these events occur, the agent notifies the FRR BGP daemon (bgpd) to advertise the IP address or FIP associated with the VM. The agent also triggers actions that route the external traffic to the OVN overlay.
Free Range Routing (FRRouting, or FRR) (frr container)
An IP routing protocol suite of daemons that run in the frr container on both Computes and Networker nodes and work together to build the routing table. FRR supports equal-cost multipath routing (ECMP), although each protocol daemon uses different methods to manage ECMP policy. The FRR suite, supplied with Red Hat Enterprise Linux (RHEL), provides several daemons. RHOSO uses the FRR bgpd, bfdd, and Zebra daemons.
BGP daemon (frr container)
A daemon (bgpd) that runs in the frr container to implement version 4 of Border Gateway Protocol (BGP). The bgpd daemon uses capability negotiation to detect the remote peer’s capabilities. If a peer is exclusively configured as an IPv4 unicast neighbor, bgpd does not send capability negotiation packets. The BGP daemon adds routes or IP addresses that causes the Zebra daemon to expose the IP addresses.
BFD daemon (frr container)
An optional, daemon (bfdd) in the FRR suite that implements Bidirectional Forwarding Detection (BFD), and is enabled by default. This protocol provides failure detection between adjacent forwarding engines.
Zebra daemon (frr container)
A daemon that coordinates information from the various FRR daemons, and communicates routing decisions directly to the kernel routing table.
VTY shell (frr container)
A shell for FRR daemons, VTY shell (vtysh) aggregates all the CLI commands defined in each of the daemons and presents them in a single shell.

BGP route advertisement and traffic flow
Copy link

In RHOSO deployments that use dynamic routing, network traffic flows to and from VMs and floating IPs (FIPs) using advertised routes.

After the traffic arrives at the node, the neutron OVN agent adds the IP rules, routes, and OVS flow rules to redirect traffic to the OVS provider bridge (br-ex) by using Red Hat Enterprise Linux (RHEL) kernel networking.

These are the steps performed to advertise a network route:

  1. Configure FRR to advertise routes from a specific VRF whose default name is ovnvrf42.
  2. Configure FRR to learn routes from a specific VRF whose default name is ovnvrf10.

    OVN reads ECMP default routes from this VRF for egress traffic.

  3. OVN adds blackhole routes to the VRF.
  4. FRR advertises those routes to its BGP peers.