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 2213892

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: Francois Palin <fpalin>
Component: openvswitch2.15Assignee: Mike Pattrick <mpattric>
Status: CLOSED CURRENTRELEASE QA Contact: Zhiqiang Fang <zfang>
Severity: high Docs Contact:
Priority: unspecified    
Version: RHEL 8.0CC: bcafarel, broose, ctrautma, fleitner, ggrimaux, jhsiao, jveiraca, mlaniel, mpattric, ralongi, rcernin, tarcher, tschaibl, zfang
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2024-08-26 14:32:02 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Francois Palin 2023-06-09 19:12:15 UTC
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