openstack/ovn-bgp-agent
Code Issues Proposed changes

Fixes at the documentation

Browse Source 
This is a follow up of [1]

[1] https://review.opendev.org/c/openstack/ovn-bgp-agent/+/903407

Change-Id: Ifda13d090b1e298ae8b5393a313c2ea4df105fcb
This commit is contained in:
Luis Tomas Bolivar 2024-02-19 09:14:31 +01:00
parent 5cb7349091
commit 921e39ba02
9 changed files with 49 additions and 51 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
doc/source/bgp_supportability_matrix.rst
View File

@ -34,9 +34,10 @@ BGP Driver (SB)
BGP Driver (NB)
---------------
OVN version 23.09 is required to expose tenant networks and ovn-lb, because
CR-LRP port chassis information in the NB DB is only available in that
version (https://bugzilla.redhat.com/show_bug.cgi?id=2107515).
OVN version 23.09 is required to expose tenant networks and ovn Load Balancers,
because Distributed Gateway port (cr-lrp) chassis information in the NB DB is
only available in that version
(https://bugzilla.redhat.com/show_bug.cgi?id=2107515).
The following table lists the various methods you can use to expose the
networks/IPS, how they expose the IPs and the tenant networks, and whether

9
doc/source/contributor/agent_deployment.rst
View File

@ -19,10 +19,11 @@ allocated):
needs to be running on the networker nodes. In OpenStack, with OVN
networking, the N/S traffic to the tenant VMs (without FIPs) needs to go
through the networking nodes, more specifically the one hosting the
chassisredirect OVN port (cr-lrp), connecting the provider network to the
OVN virtual router. Hence, the VM IPs are advertised through BGP in that
node, and from there it follows the normal path to the OpenStack compute
node where the VM is located — through the tunnel.
Distributed Gateway Port (chassisredirect OVN port (cr-lrp)),
connecting the provider network to the OVN virtual router.
Hence, the VM IPs are advertised through BGP in that node, and from there it
follows the normal path to the OpenStack compute node where the VM is
located — through the tunnel.
- Similarly, for OVN load balancer the IPs are exposed on the networker node.
In this case the ARP request for the VIP is replied by the OVN router

2
doc/source/contributor/bgp_advertising.rst
View File

@ -61,6 +61,6 @@ the route:
As we also want to be able to expose VM connected to tenant networks
(when ``expose_tenant_networks`` or ``expose_ipv6_gua_tenant_networks``
configuration options are enabled), there is a need to expose the Neutron
router gateway port (CR-LRP on OVN) so that the traffic to VMs in tenant
router gateway port (cr-lrp on OVN) so that the traffic to VMs in tenant
networks is injected into OVN overlay through the node that is hosting
that port.

6
doc/source/contributor/bgp_traffic_redirection.rst
View File

@ -45,9 +45,9 @@ Then, either upon events or due to (re)sync (regularly or during start up), it:
*IP dev br-ex scope link* # IPs on provider or FIPs
- Adds a static ARP entry for the OVN router gateway ports (CR-LRP) so that the
traffic is steered to OVN via br-int -- this is because OVN does not reply
to ARP requests outside its L2 network:
- Adds a static ARP entry for the OVN Distributed Gateway Ports (cr-lrps) so
that the traffic is steered to OVN via br-int -- this is because OVN does
not reply to ARP requests outside its L2 network:
.. code-block:: ini

24
doc/source/contributor/drivers/bgp_mode_design.rst
View File

@ -24,8 +24,8 @@ it is common to use pure Layer 3 spine and leaf network deployments in data
centers. The benefits of this practice reduce scaling complexities,
failure domains, and broadcast traffic limits.
The southbound OVN BGP agent is a Python-based daemon that runs on each
OpenStack Controller and Compute node.
The Southbound driver for OVN BGP Agent is a Python-based daemon that runs on
each OpenStack Controller and Compute node.
The agent monitors the Open Virtual Network (OVN) southbound database
for certain VM and floating IP (FIP) events.
When these events occur, the agent notifies the FRR BGP daemon (bgpd)
@ -137,11 +137,11 @@ watched for BGP use as the base (inherit from).
The BGP watcher reacts to the following events:
- ``PortBindingChassisCreatedEvent``: Detects when a port of type
``""`` (empty double-qoutes), ``virtual``, or ``chassisredirect`` gets
``""`` (empty double-quotes), ``virtual``, or ``chassisredirect`` gets
attached to the OVN chassis where the agent is running. This is the case for
VM or amphora LB ports on the provider networks, VM or amphora LB ports on
tenant networks with a FIP associated, and neutron gateway router ports
(CR-LRPs). It calls ``expose_ip`` driver method to perform the needed
(cr-lrps). It calls ``expose_ip`` driver method to perform the needed
actions to expose it.
- ``PortBindingChassisDeletedEvent``: Detects when a port of type
@ -149,7 +149,7 @@ The BGP watcher reacts to the following events:
detached from the OVN chassis where the agent is running. This is the case
for VM or amphora LB ports on the provider networks, VM or amphora LB ports
on tenant networks with a FIP associated, and neutron gateway router ports
(CR-LRPs). It calls ``withdraw_ip`` driver method to perform the needed
(cr-lrps). It calls ``withdraw_ip`` driver method to perform the needed
actions to withdraw the exposed BGP route.
- ``FIPSetEvent``: Detects when a Port_Binding entry of type ``patch`` gets
@ -301,10 +301,10 @@ The following limitations apply:
- In OpenStack with OVN networking the N/S traffic to the ovn-octavia VIPs on
the provider or the FIPs associated to the VIPs on tenant networks needs to
go through the networking nodes (the ones hosting the Neutron Router Gateway
Ports, i.e., the chassisredirect cr-lrp ports, for the router connecting the
load balancer members to the provider network). Therefore, the entry point
into the OVN overlay needs to be one of those networking nodes, and
consequently the VIPs (or FIPs to VIPs) are exposed through them. From those
nodes the traffic follows the normal tunneled path (Geneve tunnel) to
the OpenStack compute node where the selected member is located.
go through the networking nodes (the ones hosting the Distributed Router
Gateway Ports, i.e., the chassisredirect cr-lrp ports, for the router
connecting the load balancer members to the provider network). Therefore,
the entry point into the OVN overlay needs to be one of those networking
nodes, and consequently the VIPs (or FIPs to VIPs) are exposed through them.
From those nodes the traffic follows the normal tunneled path (Geneve
tunnel) to the OpenStack compute node where the selected member is located.

4
doc/source/contributor/drivers/bgp_mode_stretched_l2_design.rst
View File

@ -89,7 +89,7 @@ The driver react specifically to the following events:
attached to the OVN chassis where the agent is running. This is the case for
VM or amphora LB ports on the provider networks, VM or amphora LB ports on
tenant networks with a FIP associated, and neutron gateway router ports
(CR-LRPs). It calls ``expose_ip`` driver method to perform the needed
(cr-lrps). It calls ``expose_ip`` driver method to perform the needed
actions to expose it.
- ``PortBindingChassisDeletedEvent``: Detects when a port of type
@ -97,7 +97,7 @@ The driver react specifically to the following events:
detached from the OVN chassis where the agent is running. This is the case
for VM or amphora LB ports on the provider networks, VM or amphora LB ports
on tenant networks with a FIP associated, and neutron gateway router ports
(CR-LRPs). It calls ``withdraw_ip`` driver method to perform the needed
(cr-lrps). It calls ``withdraw_ip`` driver method to perform the needed
actions to withdraw the exposed BGP route.
- ``SubnetRouterAttachedEvent``: Detects when a patch port gets created.

6
doc/source/contributor/drivers/evpn_mode_design.rst
View File

@ -180,14 +180,14 @@ The specific defined events to react to are:
- ``PortBindingChassisCreatedEvent`` (set gateway port for router):
Detects when a port of type ``chassisredirect`` gets attached to the OVN
chassis where the agent is running. This is the case for neutron gateway
router ports (CR-LRPs). It calls ``expose_ip`` driver method to decide if
router ports (cr-lrps). It calls ``expose_ip`` driver method to decide if
it needs to expose it through EVPN (in case it has related EVPN info
annotated).
- ``PortBindingChassisDeletedEvent`` (unset gateway port for router):
Detects when a port of type ``chassisredirect`` gets detached from the OVN
chassis where teh agent is running. This is the case for neutron gateway
router ports (CR-LRPs). It calls ``withdraw_ip`` driver method to decide if
router ports (cr-lrps). It calls ``withdraw_ip`` driver method to decide if
it needs to withdraw the exposed EVPN route (in case it had EVPN info
annotated).
@ -426,7 +426,7 @@ gateway port (cr-lrp on OVN).
However this is not enough as the traffic needs to be redirected to the OVN
Overlay. To do that the VRF is added to the br-ex OVS provider bridge (br-ex),
and two routes are added to the VRF routing table to redirect the traffic
going to the network (20.0.0.0/24) through the CR-LRP port to the br-ex OVS
going to the network (20.0.0.0/24) through the cr-lrp port to the br-ex OVS
bridge.
That injects the traffic properly into the OVN overlay, which will redirect
it through the geneve tunnel (by the br-int ovs flows) to the compute node

29
doc/source/contributor/drivers/nb_bgp_mode_design.rst
View File

@ -25,17 +25,18 @@ it is common to use pure Layer 3 spine and leaf network deployments in
data centers. The benefits of this practice reduce scaling complexities,
failure domains, and broadcast traffic limits
The northbound OVN BGP agent is a Python-based daemon that runs on each
OpenStack Controller and Compute node.
The Northbound driver for OVN BGP agent is a Python-based daemon that runs
on each OpenStack Controller and Compute 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.
Unlike its predecessor, the (southbound) OVN BGP agent, the northbound OVN BGP
agent uses the northbound database API which is more stable than the southbound
database API because the former is isolated from internal changes to core OVN.
Unlike its predecessor, the Southbound driver for OVN BGP agent, the
Northbound driver uses the northbound database API which is more stable than
the southbound database API because the former is isolated from internal
changes to core OVN.
.. note::
@ -120,7 +121,7 @@ for now you can select:
as supported by the driver at :ref:`bgp_driver`.
- ``ovn``: using an extra OVN cluster per node to perform the routing at
OVN/OVS level instead of kernel, therefore enabling datapath acceleration
OVN/OVS level instead of kernel, enabling datapath acceleration
(Hardware Offloading and OVS-DPDK). More information about this mechanism
at :ref:`bgp_driver`.
@ -204,23 +205,25 @@ The specific defined events to react to are:
- ``ChassisRedirectCreateEvent``: Similar to
``LogicalSwitchPortProviderCreateEvent`` but with the focus on logical router
ports, such as the OVN gateway ports (cr-lrps), instead of logical switch
ports. The driver calls ``expose_ip`` which performs additional steps to also
ports, such as the Distributed Router Ports (cr-lrps), instead of logical
switch ports.
The driver calls ``expose_ip`` which performs additional steps to also
expose IPs related to the cr-lrps, such as the ovn-lb or IPs in tenant
networks. The watcher ``match`` checks the chassis information in the
``status`` field, which must be ovn23.09 or later.
- ``ChassisRedirectDeleteEvent``: Similar to
``LogicalSwitchPortProviderDeleteEvent`` but with the focus on logical router
ports, such as the OVN gateway ports (cr-lrps), instead of logical switch
ports. The driver calls ``withdraw_ip`` which performs additional steps to
ports, such as the Distributed Router Ports (cr-lrps), instead of logical
switch ports.
The driver calls ``withdraw_ip`` which performs additional steps to
also withdraw IPs related to the cr-lrps, such as the ovn-lb or IPs in tenant
networks. The watcher ``match`` checks the chassis information in the
``status`` field, which must be ovn23.09 or later.
- ``LogicalSwitchPortSubnetAttachEvent``: Detects Logical Switch Ports of type
``router`` (connecting Logical Switch to Logical Router) and checks if the
associated router is associated to the local chassis, i.e., if the CR-LRP of
associated router is associated to the local chassis, i.e., if the cr-lrp of
the router is located in the local chassis. If that is the case, the
``expose_subnet`` driver method is called which is in charge of the wiring
needed for the IPs on that subnet (set of IP routes and rules).
@ -274,8 +277,8 @@ exposed.
.. note::
To be able to expose tenant networks a ovn version ovn23.09 or newer is
needed
To be able to expose tenant networks a OVN version OVN 23.09 or newer is
required.
To accomplish the network configuration and advertisement, the driver ensures:

13
doc/source/contributor/drivers/ovn_bgp_mode_design.rst
View File

@ -11,13 +11,6 @@ relying on Kernel routing.
Purpose
-------
The addition of a BGP driver enables the OVN BGP agent to expose virtual
machine (VMs) and load balancer (LBs) IP addresses through the BGP dynamic
protocol when these IP addresses are either associated with a floating IP
(FIP) or are booted or created on a provider network.
The same functionality is available on project networks, when a special
flag is set.
This document presents the design decision behind the extensions on the
NB OVN BGP Driver to support OVN routing instead of kernel routing,
and therefore enabling datapath acceleartion.
@ -250,10 +243,10 @@ Limitations
The following limitations apply:
- OVN 23.06 or later is needed
- OVN 23.06 or later is required
- Tenant networks, subnet and ovn-loadbalancer are not yet supported, and will
require OVN 23.09 or nlaterewer.
- Tenant networks, subnet and OVN load balancers are not yet supported, and
will require OVN vesion 23.09 or newer.
- IPv6 not yet supported