Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
The FDP team is no longer accepting new bugs in Bugzilla. Please report your issues under FDP project in Jira. Thanks.

Bug 2237816

Summary: OVS MAC tables on client OVS DPDK not updating correctly upon F5 virtual Load Balancers HA switchover
Product: Red Hat Enterprise Linux Fast Datapath Reporter: ovs-bugzilla <ovs-bugzilla>
Component: openvswitch3.1Assignee: Mike Pattrick <mpattric>
Status: CLOSED ERRATA QA Contact: Zhiqiang Fang <zfang>
Severity: high Docs Contact:
Priority: unspecified    
Version: RHEL 8.0CC: ctrautma, jhsiao, ralongi, zfang
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: openvswitch3.1-3.1.0-53.el9fdp Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2023-10-18 00:27:10 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description ovs-bugzilla 2023-09-07 04:46:58 UTC 
+++ This bug was initially created as a clone of Bug #2213892 +++

Description of problem:
(somewhat similar to BZ 2182549, but this time using a lab setup instead of prod)

Customer has a setup that is using 2 x F5 Load Balancer instances in Active/Standby mode.

Compute 2 is hosting client VMs (from Ixia) to generate traffic directed at the vLBs.
Compute 3 is hosting vLB3 and Compute 4 is hosting vLB4.

The active vLB is owner of a "masquerade MAC". 
Upon switchover, the newly active vLB becomes owner of the masquerade MAC and issues a GARP to announce this change.
Masquerade MAC is an F5 proprietary mechanism which is somewhat the MAC equivalent of a virtual IP address (VIP).

How reproducible:
Always


Steps to Reproduce:
Force vLB switchover.


Actual results:
What is observed on compute 2 (hosting client app from Ixia):
 - using ovs-tcpdump, we see the GARP from newly active vLB is received by OVS DPDK.
 - OVS FDB table doesn't get updated.

What is observed on computes 3 and 4: 
 - the vLB that becomes active issues the GARP
 - FDB tables on both computes get updated with new masquerade MAC port info.


Expected results:
What is expected is that upon receiving the GARP, OVS FDB tables on all computes (2, 3, and 4) get updated.


Additional info:
RHOSP 16.2
compute 2: openvswitch2.15-2.15.0-126.el8fdp.x86_64
compute 3: openvswitch2.15-2.15.0-126.el8fdp.x86_64
compute 4: openvswitch2.15-2.15.0-99.el8fdp.x86_64

compute 2: dpdkbond1:  dpdk0 (ens3f0) and dpdk1 (ens3f1)  balance-tcp  lacp
Comment 1 ovs-bugzilla 2023-09-07 04:47:02 UTC 
* Wed Sep 06 2023 Open vSwitch CI <ovs-ci> - 3.1.0-53
- Merging upstream branch-3.1 [RH git: bb3687599b]
    Commit list:
    2ac4059b9a ofproto-dpif-xlate: Fix recirculation with patch port and controller. (#2170920)
    04b8fe40a5 ofproto-dpif-xlate: Don't reinstall removed XC_LEARN rule. (#2213892)
Comment 7 errata-xmlrpc 2023-10-18 00:27:10 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 (openvswitch3.1 bug fix and enhancement update), 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-2023:5818