I don't think this is an opinion, I think this is actually a bug since
this means if you add a second subnet to your primary "public" external
network, you may have scenarios where load balancers are not reachable
from one subnet or the other.
This could also be because of something inside OVN provider for Octavia
as well.
** Changed in: neutron
Status: Opinion => Confirmed
** Tags added: ovn-octavia-provider
** Tags added: ovn
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/2110225
Title:
Floating IPs attached to Octavia LB VIPs are not reachable across
routers using different external subnets (OVN + Octavia)
Status in neutron:
Confirmed
Bug description:
Hi Everyone!
We were facing an issue when extending the Openstack public network
range by adding a new subnet, by looking the comments of that
launchpad bug:
https://bugs.launchpad.net/neutron/+bug/1605343
Seems like the way to do it is to add a newer subnet, but doing so we
encounter the following issue:
When using Openstack with OVN networking and Octavia LBaaS, creating routers
with different external gateway subnets (e.g.. public-subnet and
public-subnet-2) causes load balancer VIPs to become unreachable across subnets
from VMs on the same public-subnet
Reproduction Steps:
1) Create two public subnets (public-subnet, public-subnet-2) on the same
external network
2) Create two routers
router1 with external gateway set to public-subnet-2
router2 with external gateway set to public-subnet
3) Attach internal networks (private, private-2) to each router
4) Launch VMs in each subnet and deploy web servers
5) Create two Octavia load balancers:
subnet1_lb1 in private network
subnet2_lb1 in private-2 network
Assign floating IPs to the VIP ports of both load balancers
6) From each VM, try accessing subnet1_lb1 and subnet2_lb1
Observed Behavior:
From subnet1_node1 (172.24.4.100) behind router R1 (172.24.5.X subnet) we are
able to reach the Octavia LB subnet1_lb1 (172.24.4.200) ✅
From subnet1_node1 (172.24.4.100) behind router R1 (172.24.5.X subnet) we are
not able to reach the Octavia LB subnet1_lb2 (172.24.5.200) ❌
From subnet2_node1 (172.24.5.100) behind router R2 (172.24.4.X subnet) we are
able to reach the Octavia LB subnet2_lb1 (172.24.5.200) ✅
From subnet2_node1 (172.24.5.100) behind router R2 (172.24.4.X subnet) we are
not able to reach the Octavia LB subnet1_lb1 (172.24.4.200) ❌
If we put those in a matrix:
Source VM Router (Gateway Subnet) Target LB VIP
Expected Observed Result
subnet1_node1 R1 (public-subnet-2 / 172.24.5.X) subnet1_lb1 (172.24.4.200)
Reachable 200. ✅
subnet1_node1 R1 (public-subnet-2 / 172.24.5.X) subnet2_lb1 (172.24.5.200)
Reachable Timeout ❌
subnet2_node1 R2 (public-subnet / 172.24.4.X) subnet2_lb1 (172.24.5.200)
Reachable 200. ✅
subnet2_node1 R2 (public-subnet / 172.24.4.X). subnet1_lb1 (172.24.4.200)
Reachable Timeout ❌
We clearly see that a VM from a different subnet tries to reach a
loadbalancer via the LB floating IP, the LB is not reachable if the
router (connecting the LB to the public network) external IP is in a
different range than the LB floating IP.
Expected Behavior:
All VMs, regardless of which subnet/router they are connected to, should be
able to reach any VIP exposed via floating IP
Environment:
OpenStack with OVN (replicable on latest version with Devstack)
Below i'll attach the scripts to replicate it on a freshly created
Devstack instance
Feel free to reach out for any further detail
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/2110225/+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
