Reviewed: https://review.opendev.org/c/openstack/ovn-octavia-provider/+/816868
Committed:
https://opendev.org/openstack/ovn-octavia-provider/commit/ee800e165469dec8c492893c5ba64d4be7cc3170
Submitter: "Zuul (22348)"
Branch: master
commit ee800e165469dec8c492893c5ba64d4be7cc3170
Author: Slawek Kaplonski <skapl...@redhat.com>
Date: Fri Nov 5 18:48:34 2021 +0100
Check gateway IP while looking for LR plugged to LS
When LB or member is created, driver looks for the Logical Router which
is plugged to the Logical Switch (Neutron network). As there can be more
than one router connected to one network, we should always store in
Loadbalancer's external_ids ID of the router which is used as default
gateway for the VIP's subnet.
This patch changes _find_lr_of_ls() method of the
ovn_octavia_provider.helper.OvnProviderHelper class so it checks
subnet's gateway IP while looks for the logical router.
Closes-bug: #1949059
Change-Id: I771f39ba190623857af208e23d8228c4bdc0db20
** 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/1949059
Title:
ovn-octavia-provider: incorrect router association in NB when network
is linked to more than 1 router
Status in neutron:
Fix Released
Bug description:
LB does not work when creating an Octavia LB with OVN provider in a
network containing multiple router interfaces.
When creating a loadbalancer using ovn provider, the OVN octavia driver agent
creates a Load_Balancer entry and add several external ids, one of those being
the Logical Router ID (lr_ref) to have the OVN LB properly work with an
associated floating IP. This lr_ref association is repeated multiple times
during the lifecycle of a LB : at create time (helper.py:lb_create) or when
adding a listener,pool or pool member.
During LB creation, the driver agent tries to find the associated LR of every
LS linked with the LB with helper.py:_find_lr_of_ls to add the LR IDs to the
lr_ref external id field in OVN. The linked LS are the vip_network or the LS in
which the pool members are.
The problem is the function _find_lr_of_ls incorrectly assumes that
there is only one router port, by returning the LR associated with the
FIRST port of type 'router' in the whole LS. This causes an unexpected
behavior as the first port can be either the router port of the
default gateway router, but it can also be any other router port
having an interface in that LS.
The use case of having multiple router interfaces in one LS in to be able to
route between other internal networks without NAT, using static routes
installed in the neutron default router.
This is a standard way of routing between internal networks in neutron and it
works perfectly with OVN.
For a quick example, say we have a LS "ls1" containing the 192.168.1.0/24
network attached to its "lr1" router. We want all the traffic to go to the
default gateway (192.168.1.1), SNATted by going through the public interface of
the router lr1. For traffic going to 192.168.2.0/24, we want it to go to router
"lr2". For this to happen, we add an interface from lr2 (192.168.1.2) in the
ls1 network, and add a static route in lr1 (route: 192.168.2.0/24 next-hop
192.168.1.2). The network ls1 now has two routers attached.
We cannot do the same by interconnecting directly multiple routers (neutron
does not supports router-to-router links), and we cannot use a dedicated
interconnect neutron network to do that, because all the flows routed by lr1 to
lr2 through a dedicated network cannot be then SNATted by lr2. But this
behavior is out of the present topic, it's just a way of demonstrating that
there is no workaround to route traffic the way neutron allows us to without
having two routers having both an interface in the initial LS.
The correct logic for helper.py:_find_lr_of_ls would be to first
gather all ports with type=router, then check if the port IP matches
the default gateway specified in neutron subnet definition. If it
matches, then return the associated LR. Another way to make sure that
the LB can work through all the attached routers in a LS would be to
add all the lr_refs of all routers found in a LS (and have an event
listening for all router ports added to the LS after LB creation).
Tested on latest Xena build.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1949059/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
