Bug 1908719 - [RFE] Create FRRouting Container For BGP Routing
Summary: [RFE] Create FRRouting Container For BGP Routing
Status: POST
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo
Version: 17.0 (Wallaby)
Hardware: Unspecified
OS: Unspecified
Target Milestone: beta
: ---
Assignee: Michele Baldessari
QA Contact: Joe H. Rahme
Depends On:
TreeView+ depends on / blocked
Reported: 2020-12-17 12:25 UTC by Dan Sneddon
Modified: 2021-07-21 12:16 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 763087 0 None MERGED Frr image support 2021-02-17 15:00:21 UTC
Red Hat Bugzilla 1896551 0 medium NEW [RFE][Tracker] Enable BGP Routing For Spine-Leaf Deployments 2021-11-18 15:15:16 UTC

Internal Links: 1896551 1997510 1997518 2012965

Description Dan Sneddon 2020-12-17 12:25:28 UTC
Description of problem:
We need to create a TripleO service that creates a container with the Free Range Routing (FRRouting or FRR) software in order to enable BGP routing for OpenStack overcloud nodes.

Version-Release number of selected component (if applicable):

Expected results:
This BZ will track the implementation of a new TrpileO service that creates a container for running FRR daemons. Specifically the FRR daemons that we need are the management daemon frr-watchfrr that starts and monitors the other daemons, the vtysh daemon that presents the configuration UI, the zebra daemon that reads and writes routes to and from the kernel, the BGP daemon, and optionally the BFD (bi-directional forwarding) daemon that enables route viability detection.

There will be some basic configuration parameters supplied by the installer, and the configuration will be placed on the server using Ansible. A route filter will be configured that defines that any host addresses on the node with a /32 (IPv4) or /128 (IPv6) subnet mask will be redistributed into BGP and advertised to BGP peers (routers) running on the network infrastructure.

Additional info:
There is an upstream spec that describes the requirement for the TripleO service here:

Comment 1 Dan Sneddon 2020-12-17 13:02:37 UTC
There are several use cases for BGP, but all of them depend on having a TripleO service that installs and configures the FRR container. We may enable these use cases separately, and it is possible that we will not implement all use cases. These use cases include:

* High-availability for virtual IP addresses managed by Pacemaker using BGP instead of ARP for routing traffic to API endpoints.

* Advertising Neutron floating IP addresses using BGP so that floating IP addresses hosted by Neutron routers can be portable across routed networks. Either network controllers or compute nodes would advertise the floating IP depending on whether DVR is used in the Neutron configuration.

* Advertising Neutron provider IP addresses for VM instances running on compute nodes using BGP. In this model it is not necessary to trunk a VLAN directly to the compute node hosting the instance, instead BGP will be used to route traffic destined to the VM instance IP to the compute node.

* BGP VPN that allows traffic to be routed to a particular datacenter gateway node for a given network. In this model either VXLAN VNIs or MPLS labels can be advertised via BGP routes.

* Advertise reachability to tenant networks via networking gateway nodes using BGP. These nodes may be compute nodes hosting Neutron routers if DVR is used, or network controllers where Neutron routers are hosted.

* Advertise reachability to tenant networks running in per-tenant IP namespaces and separate virtual routing and forwarding (VRF) instances.

Implementation details for individual use cases will be tracked in separate BZs.

Note You need to log in before you can comment on or make changes to this bug.