yahoo-eng-team team mailing list archive

[OpenStack Infra <2002687@xxxxxxxxxxxxxxxxxx>]

Reviewed:  https://review.opendev.org/c/openstack/neutron/+/899402
Committed: https://opendev.org/openstack/neutron/commit/0199a8457b4e813fa1eb6235ad68b49a71725b8f
Submitter: "Zuul (22348)"
Branch:    master

commit 0199a8457b4e813fa1eb6235ad68b49a71725b8f
Author: Frode Nordahl <frode.nordahl@xxxxxxxxxxxxx>
Date:   Thu Oct 26 15:52:18 2023 +0200

    Add documentation for aa-l3-gw-multihoming
    
    Closes-Bug: #2002687
    Depends-On: I4e69bdf2ac9da1154d3847f3191b110f09130e02
    Signed-off-by: Frode Nordahl <fnordahl@xxxxxxxxxx>
    Change-Id: I717ca97164eb9a34bb1095c6222f9879017af5ca


** Changed in: neutron
       Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2002687

Title:
  [RFE] Active-active L3 Gateway with Multihoming

Status in neutron:
  Fix Released

Bug description:
  Some network designs include multiple L3 gateways to:

  * Share the load across different gateways;
  * Provide independent network paths for the north-south direction (e.g. via
    different ISPs).

  Having multi-homing implemented at the instance level imposes additional burden
  on the end user of a cloud and support requirements for the guest OS, whereas
  utilizing ECMP and BFD at the router side alleviates the need for instance-side
  awareness of a more complex routing setup.

  Adding more than one gateway port implies extending the existing data model
  which was described in the multiple external gateways spec (https://specs.openstack.org/openstack/neutron-specs/specs/xena/multiple-external-gateways.html). However, it left
  adding additional gateway routes out of scope leaving this to future
  improvements around dynamic routing. Also the focus of neutron-dynamic-routing
  has so far been around advertising routes, not accepting new ones from the
  external peers - so dynamic routing support like this is a very different
  subject. However, manual addition of extra routes does not utilize the default
  gateway IP information available from subnets in Neutron while this could be
  addressed by implementing an extra conditional behavior when adding more than
  one gateway port to a router.

  ECMP routes can result in black-holing of traffic should the next-hop of a
  route becomes unreachable. BFD is a standard protocol adopted by IETF
  for next-hop failure detection which can be used for route eviction. OVN
  supports BFD as of v21.03.0 (https://github.com/ovn-org/ovn/commit/6e0a69ad4bcdf9e4cace5c73ef48ab06065e8519) with a data model that allows enabling
  BFD on a per next-hop basis by associating BFD session information with routes,
  however, it is not modeled at the Neutron level even if a backend supports it.

  From the Neutron data model perspective, ECMP for routes is already a supported
  concept since ECMP support spec got implemented (https://specs.openstack.org/openstack/neutron-specs/specs/wallaby/l3-router-support-ecmp.html) in Wallaby (albeit the
  spec focused on the L3-agent based implementation only).

  As for OVN and BFD, the OVN database state needs to be populated by Neutron
  based on the data from the Neutron database, therefore, data model changes to
  the Neutron DB are needed to represent the BFD session parameters.

  ---

  The previous work on multiple gateway ports did not get completed and
  the neutron-lib changes were reverted. Likewise, the scope of this RFE
  is bigger with some overlap and augmentation compared to prior art.
  The spec will follow for this RFE with more details as to how the data
  model and API changes are proposed to be made.

  Upd: https://review.opendev.org/c/openstack/neutron-specs/+/870030

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2002687/+subscriptions