Loadbalancer missing logical switch association

Bug #1794260 reported by Luis Tomas Bolivar on 2018-09-25
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
networking-ovn
Undecided
Reedip

Bug Description

When a port (P1) in a Subnet (S1) tries to reach a member (P2 on S2) of a loadbalancer (LB1) through the loadbalancer VIP (P3 on S3), the traffic gets lost in it's way back from the member (P2) to the caller (P1).

The problem raises from the loadbalancer not being associated to the caller's subnet switch. For instance, the next command with make the request successful:

ovn-nbctl set logical_switch S1_logical_switch_id load_balancer=LB1_id

Reedip (reedip-banerjee) on 2018-09-25
Changed in networking-ovn:
assignee: nobody → Reedip (reedip-banerjee)
Reedip (reedip-banerjee) wrote :

As per the discussion with Numan yesterday, an ideal way to handle the above issue might be to track the changes in a router.

- Use case #1: Members, VIPs and user are in the same subnet
- Use case #2: Network 1 and Network 2 are created , followed by router.After that LB is created on Network 1, Network 1 has VIP, Network 2 has Member and User putting the Curl Request.
- Use case #3: Network 1 followed by router.After that LB is created on Network 1, Network 1 has VIP. Network 2 is now created, connected to the router . Network 2 now has a Member for the VIP. User can be on Network 1/Network 2.
- Use case #4: Network 1 followed by router.After that LB is created on Network 1, Network 1 has VIP. Network 2 is now created, connected to the router . Network 2 now has a Member for the VIP. Network 3 is now created and connected to the router. Network 3 has the User for the curl request.

In Use Case 2-4 , router will know about all the changes in the network, so it would be easier if we can track all the networks associated to a router. In case a network has a LB and is associated with a new router, the LB can be associated with the router and any NEW network connected to the router.

NOTE: the same process has to be considered if the network interfaces are removed from a router :)

Daniel Alvarez (dalvarezs) wrote :

This can be tricky at scale. Imagine an scenario where we have a Logical Router with a large number of networks connected to it. One of that networks has an LB which is main use case is that Members, VIPS and user are in the same subnet. Still, because we don't know that this is the use case, we're going to add the load balancer to *all* of the networks connected to that router. Not sure how this can impact at scale but I'd say it's something to keep in mind.

Daniel Alvarez (dalvarezs) wrote :

So the idea is to tackle this by applying the LB to all LS connected to the LR and if this is a problem at scale we'll look at how to enhance it in core OVN so that the LB is only applied to the LR.

Daniel Alvarez (dalvarezs) wrote :

Plan is to monitor the Logical_Router table and on every update/delete event:

1. Calculate which LS are connected to it through the lrps present in the router.
2. Make sure that all LBs present in those LS are also added to the router.
3. Make sure that all those LBs are present also in every LS connected to the router.

Note: This ^ has to be also done on CREATE event (at connection/reconnection time because we'll get a dump from OVSDB for all existing LRs).

Miguel Angel Ajo (mangelajo) wrote :

You can also monitor the LSP/LRP tables to find out when a router port on a network is created.

Changed in networking-ovn:
status: New → In Progress

Change abandoned by Maciej Józefczyk (<email address hidden>) on branch: master
Review: https://review.opendev.org/667642

Change abandoned by Reedip (<email address hidden>) on branch: master
Review: https://review.opendev.org/608862
Reason: Abandoning in favor of the new patch

Reviewed: https://review.opendev.org/668397
Committed: https://git.openstack.org/cgit/openstack/networking-ovn/commit/?id=aa4268a09470aea28f4a8c9f1062f32f057cb151
Submitter: Zuul
Branch: master

commit aa4268a09470aea28f4a8c9f1062f32f057cb151
Author: reedip <email address hidden>
Date: Thu Jun 27 14:12:56 2019 +0000

    Add a new Event Handler for Octavia

    This patch adds a new event handler for Octavia so that in
    the event that a network is added to a router, the loadbalancer
    on the network are also applied to the router and vice versa.

    The process involves:
    - Adding a new connection class for Octavia to communicate with
      OVN NB DB, setting up the connection and communicating with
      the IDL.
    - Setting up events for Router interface addition and deletion
    - Updating Loadbalancer tables and Router/Switch tables based
      upon the generated events.
    - Add network UUID to LRP external_ids

    Co-Authored-By: Terry Wilson <email address hidden>
    Co-Authored-By: Maciej Józefczyk <email address hidden>

    Change-Id: If10016325517e4a1fc5f7cfac7f7bd58deb09b54
    Closes-Bug: #1794260

Changed in networking-ovn:
status: In Progress → Fix Released

Reviewed: https://review.opendev.org/672645
Committed: https://git.openstack.org/cgit/openstack/networking-ovn/commit/?id=c5169327ec13e7fb02ee2346a70f8666c725ab2a
Submitter: Zuul
Branch: stable/stein

commit c5169327ec13e7fb02ee2346a70f8666c725ab2a
Author: reedip <email address hidden>
Date: Thu Jun 27 14:12:56 2019 +0000

    Add a new Event Handler for Octavia

    This patch adds a new event handler for Octavia so that in
    the event that a network is added to a router, the loadbalancer
    on the network are also applied to the router and vice versa.

    The process involves:
    - Adding a new connection class for Octavia to communicate with
      OVN NB DB, setting up the connection and communicating with
      the IDL.
    - Setting up events for Router interface addition and deletion
    - Updating Loadbalancer tables and Router/Switch tables based
      upon the generated events.
    - Add network UUID to LRP external_ids

    Co-Authored-By: Terry Wilson <email address hidden>
    Co-Authored-By: Maciej Józefczyk <email address hidden>

    Change-Id: If10016325517e4a1fc5f7cfac7f7bd58deb09b54
    Closes-Bug: #1794260
    (cherry picked from commit aa4268a09470aea28f4a8c9f1062f32f057cb151)

tags: added: in-stable-stein
tags: added: networking-ovn-proactive-backport-potential
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers