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

 Problem Description: Clearly explain the issue.

We are creating ARP responder flows for VIFs with higher priority than the ARP proxy flows. However the VIF responder flows do match on "eth.dst == ff:ff:ff:ff:ff:ff", so if the ARP request is unicast it will be responded by the ARP proxy instead.

  Issue Type: Indicate whether this is a new issue or a regression (if a regression, state the last known working version).

It has been there since the introduction of ARP proxy.

 Reproducibility: Confirm if the issue can be reproduced consistently. If not, describe how often it occurs.

100%

 Reproduction Steps: Provide detailed steps or scripts to replicate the issue.

1) Create LS with VIF and router port.
2) Set ARP proxy for given router port.
3) Send unicast ARP request for VIF.

 Expected Behavior: Describe what should happen under normal circumstances.

We will get the VIF MAC.

 Observed Behavior: Explain what actually happens.

We will get the ARP proxy mac.

 Troubleshooting Actions: Outline the steps taken to diagnose or resolve the issue so far.

Conversation on https://github.com/ovn-kubernetes/ovn-kubernetes/issues/5497

The problem has probably 2 fairly easy solutions:
1) More conservative match on "eth.dst == {ff:ff:ff:ff:ff:ff, $VIF_MAC}" instead of "eth.dst == ff:ff:ff:ff:ff:ff".
2) Remove the eth.dst match completely as we are already matching on "arp.tpa == $VIF_MAC".

We need a flow with the same priority as the broadcast responder flow, that will forward the unicast to the VIF.

The solution should have appropriate test with unicast ARP request.