Bug 1608951 - Octavia - floating IP not working with Octavia + OVN + DVR
Summary: Octavia - floating IP not working with Octavia + OVN + DVR
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-networking-ovn
Version: 13.0 (Queens)
Hardware: x86_64
OS: Linux
urgent
high
Target Milestone: z3
: 13.0 (Queens)
Assignee: Daniel Alvarez Sanchez
QA Contact: Alexander Stafeyev
URL:
Whiteboard:
Depends On:
Blocks: 1547478 1627838
TreeView+ depends on / blocked
 
Reported: 2018-07-26 14:23 UTC by broskos
Modified: 2022-09-20 19:38 UTC (History)
28 users (show)

Fixed In Version: python-networking-ovn-4.0.2-3.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1627838 (view as bug list)
Environment:
Last Closed: 2018-11-13 23:32:56 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
sos report from compute node hosting all instances and lbs (12.66 MB, application/x-xz)
2018-07-26 14:45 UTC, broskos
no flags Details


Links
System ID Private Priority Status Summary Last Updated
OpenStack gerrit 592538 0 'None' MERGED Set/unset external MAC addresses for NAT entry when port is up/down 2021-02-19 02:52:51 UTC
OpenStack gerrit 601293 0 'None' MERGED Set/unset external MAC addresses for NAT entry when port is up/down 2021-02-19 02:52:51 UTC
Red Hat Bugzilla 1608343 0 medium CLOSED [OSP13][ODL][Octavia][Netvirt] No flows on compute node for floating IP assigned to amphora instance 2021-02-22 00:41:40 UTC
Red Hat Issue Tracker OSP-11502 0 None None None 2021-12-10 16:54:40 UTC
Red Hat Product Errata RHBA-2018:3614 0 None None None 2018-11-13 23:33:40 UTC

Internal Links: 1608343

Description broskos 2018-07-26 14:23:31 UTC
Description of problem:
I've deployed Octavia + OVN + DVR and floating IPs assigned to Octavia VIPs are not reachable.

Other floating IPs tied to nova instances are working fine.
The octavia vip is reachable and working fine from inside on the private network, however the Floating IP is not reachable at all.

Checked security groups for tenant, they are fine and allow port 80 - access via internal address to instance port 80 returns page as expected.  access via floating ip assigned to instance returns http page as expected.

Found LB security group in service tenant, confirmed in has ingress rule for tcp/80 from 0.0.0.0/0

Director deployment using:
    -e /usr/share/openstack-tripleo-heat-templates/environments/services-docker/octavia.yaml \
    -e  /usr/share/openstack-tripleo-heat-templates/environments/services-docker/neutron-ovn-dvr-ha.yaml \

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
create 2 test webservers, configure fake healthcheck page at /healthcheck
openstack loadbalancer create --name lb1 --vip-subnet-id admin-subnet
openstack loadbalancer listener create --name listener1 --protocol HTTP --protocol-port 80 lb1
openstack loadbalancer pool create --name pool1 --lb-algorithm ROUND_ROBIN --listener listener1 --protocol HTTP
openstack loadbalancer healthmonitor create --delay 5 --max-retries 4 --timeout 10 --type HTTP --url-path /healthcheck pool1
openstack loadbalancer member create --subnet-id admin-subnet --address 192.168.99.6 --protocol-port 80 pool1
openstack loadbalancer member create --subnet-id admin-subnet --address 192.168.99.13 --protocol-port 80 pool1

Now attach floating IP

Actual results:
website is not available via floating ip

Expected results:
website should be available via floating ip

Additional info:

Comment 1 broskos 2018-07-26 14:45:48 UTC
Created attachment 1470799 [details]
sos report from compute node hosting all instances and lbs

Comment 2 Carlos Goncalves 2018-08-01 08:48:14 UTC
Thank you for bug report and for attaching sos reports.
This issue seems to be very similar to rhbz #1608343.

Comment 5 Carlos Goncalves 2018-08-16 10:27:15 UTC
Networking-ovn is setting external_mac on the NAT entry for the floating IP associated to unbound Neutron ports. Unsetting external_mac makes it work for the user to reach the load balancer. A possible solution (verified on an OSP13 environment) is to fallback to non-DVR behavior in such cases (FIPs associated to unbound Neutron ports).

We also confirmed that one can reach a load balancer via a floating IP on Octavia/OVN-non DVR environments.

Thanks a lot to Daniel and Lucas for troubleshooting and brainstorming on possible solutions!

Comment 11 Miguel Angel Ajo 2018-09-04 14:52:21 UTC
Please see this:

Reference implentation has similar (not the same, I believe) issues.

https://bugs.launchpad.net/neutron/+bug/1774459

They have a discussion point on the PTG, On wednesday

2:15 - 3:30 L3 topics
Update permanent ARP entries for allowed_address_pair IPs in DVR Routers (swami / haleyb)

Comment 16 Daniel Alvarez Sanchez 2018-09-11 16:29:57 UTC
Moving it back to ON_DEV until it gets merged upstream.

Comment 51 Bernard Cafarelli 2018-11-08 14:51:20 UTC
Until bug #1630929 gets in, to test this configuration THT env files must be ordered properly (with the OVN one last)

Comment 52 Eran Kuris 2018-11-11 08:54:34 UTC
Look on Bernard  comment 51 
https://bugzilla.redhat.com/show_bug.cgi?id=1608951#c51

Comment 58 errata-xmlrpc 2018-11-13 23:32:56 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3614

Comment 64 swogat pradhan 2022-09-20 19:38:49 UTC
I am currently hitting this issue, 
Openstack wallaby | centos 8

My floating ip attached to octavia lb vip is not working.
Unable to browse or unable to telnet.

Please suggest a solution or workaround if you have any.

Wallaby + OVN DVR


Note You need to log in before you can comment on or make changes to this bug.