This is tracking the upstream effort needed to deliver the solution to the bug described below.

Steps to reproduce:

DUT (ARM system):

• echo "sslverify=false" >> /etc/yum.conf
• dnf -y install http://download.devel.redhat.com/brewroot/packages/openvswitch-selinux-extra-policy/1.0/36.el9fdp/noarch/openvswitch-selinux-extra-policy-1.0-36.el9fdp.noarch.rpm http://download.devel.redhat.com/brewroot/vol/rhel-9/packages/openvswitch3.1/3.1.0/137.el9fdp/aarch64/openvswitch3.1-3.1.0-137.el9fdp.aarch64.rpm
• systemctl start openvswitch
• ovs-vsctl add-br ovsbr0
• ovs-vsctl add-port ovsbr0 enP2p2s0f0np0
• ovs-vsctl add-port ovsbr0 enP2p2s0f1np1
• ovs-vsctl set Bridge ovsbr0 other_config:forward-bpdu=true
• ovs-vsctl list Bridge ovsbr0 | grep other_config

Peer system directly connected to DUT:

• dnf -y install wireshark-cli
• dnf -y install scapy

Capture packets on receiving interface of peer system:

• tshark -a duration:100 -nV -i enp130s0f1np1 -f 'ether host 01:80:c2:00:00:01' -c1 -T fields -e eth.dst | tee ~/tshark.log &
• /usr/libexec/platform-python -c 'from scapy.all import *; sendp(Ether(dst='\''01:80:c2:00:00:01'\'')/IP()/ICMP(), iface='\''enp130s0f0np0'\'')'

kill tshark

• pkill tshark

check results of packet capture:

• cat ~/tshark.log --> should contain 01:80:c2:00:00:01 but does not

Notes:

• This issue does not occur with any of the other mcast MAC addresses (such as 01:80:c2:00:00:00) with ARM
• This issue is not seen at all when using two x86_64 systems.
• This has been observed when using OVS 3.1 and 3.4 (these were the two versions checked)
• sos report: https://netqe-infra01.knqe.eng.rdu2.dc.redhat.com/sosreports/sosreport-netqe49-2024-12-18-zbevvew.tar.xz
• OVS logs to be attached to this bug

  ---