yahoo-eng-team team mailing list archive

[Gabriel Barazer <1966052@xxxxxxxxxxxxxxxxxx>]

Public bug reported:

Hi all,

When a loadbalancer is created with a VIP in a network having multiple
routers, the LogicalRouterPortEvent event sent by OVN NB associates the
floating VIP to all the routers' external ports, which in turn causes
the FIP to be ARP announced on all these external ports. This causes
traffic disruption because the floating VIP traffic can be then routed
to the wrong router. This can be verified by looking at the ARP replies
on the (public) network on which the external router interfaces are
located, where we can see the wrong MAC address is sent.

This is caused by the LogicalRouterPortEvent event handler (event.py:25)
which in turn calls lb_create_lrp_assoc_handler
(https://opendev.org/openstack/ovn-octavia-
provider/src/commit/d6adbcef86e32bc7befbd5890a2bc79256b7a8e2/ovn_octavia_provider/helper.py#L237)
and then sends a request to https://opendev.org/openstack/ovn-octavia-
provider/src/commit/d6adbcef86e32bc7befbd5890a2bc79256b7a8e2/ovn_octavia_provider/helper.py#L248

When the event is fired for a Logical Router Port not owned by the router owning the default gateway, lb_create_lrp_assoc adds all the load balancers having a VIP in the associated network to the router by calling _update_lb_to_lr_association which uses the lr_lb_add method and updates the load balancer external ids "lr_refs" key.
This behavior can be verified by looking a the load balancer external ids and the "load_balancer" key of the router owning the logical router port event fired.

During a logical router port event, the load balancer ids must be added
only if the router is the router owning the default gateway for the
network, using the same logic found in method _find_lr_of_ls.

** Affects: neutron
     Importance: Undecided
         Status: New

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

Title:
  ovn-octavia-provider associates to wrong logical router when
  LogicalRouterPortEvent is fired and network has multiple routers

Status in neutron:
  New

Bug description:
  Hi all,

  When a loadbalancer is created with a VIP in a network having multiple
  routers, the LogicalRouterPortEvent event sent by OVN NB associates
  the floating VIP to all the routers' external ports, which in turn
  causes the FIP to be ARP announced on all these external ports. This
  causes traffic disruption because the floating VIP traffic can be then
  routed to the wrong router. This can be verified by looking at the ARP
  replies on the (public) network on which the external router
  interfaces are located, where we can see the wrong MAC address is
  sent.

  This is caused by the LogicalRouterPortEvent event handler
  (event.py:25) which in turn calls lb_create_lrp_assoc_handler
  (https://opendev.org/openstack/ovn-octavia-
  provider/src/commit/d6adbcef86e32bc7befbd5890a2bc79256b7a8e2/ovn_octavia_provider/helper.py#L237)
  and then sends a request to https://opendev.org/openstack/ovn-octavia-
  provider/src/commit/d6adbcef86e32bc7befbd5890a2bc79256b7a8e2/ovn_octavia_provider/helper.py#L248

  When the event is fired for a Logical Router Port not owned by the router owning the default gateway, lb_create_lrp_assoc adds all the load balancers having a VIP in the associated network to the router by calling _update_lb_to_lr_association which uses the lr_lb_add method and updates the load balancer external ids "lr_refs" key.
  This behavior can be verified by looking a the load balancer external ids and the "load_balancer" key of the router owning the logical router port event fired.

  During a logical router port event, the load balancer ids must be
  added only if the router is the router owning the default gateway for
  the network, using the same logic found in method _find_lr_of_ls.

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