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 -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : [email protected] Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
