ovn-octavia-provider: incorrect router association in NB when network is linked to more than 1 router
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
Fix Released
|
Medium
|
Slawek Kaplonski |
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.
During LB creation, the driver agent tries to find the associated LR of every LS linked with the LB with helper.
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.
Tested on latest Xena build.
Changed in neutron: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
tags: | added: ovn |
Changed in neutron: | |
assignee: | nobody → Slawek Kaplonski (slaweq) |
Looks like a bug and the correct fix. The only problem I see is that the ovn-octavia- provider isn't currently being maintained (sorry, I'm working on other things). Don't know if you're using a distro where you can also file a bug to get some attention on this. Good luck!