Fixes FDB learning

Commit f978967 caused a regression in performance. As the below issue
describes, the egress traffic from OVN will now use NORMAL action, which
will cause an FDB lookup and then FLOOD if not found. This always ends
up being the case because the reply ARP packet from the physical port is
flooded to the patch port and the LOCAL port. This causes an increase in
CPU and unnecessarily flooding packets.

We need layer 2 packets destined to the shared gateway mac to go to both
the host and OVN. This is so both can receive ARP replies, etc. However,
we also need the FDB entry in OVS to get updated, for our new
functionality with using the NORMAL action.

To fix this, add a static FDB entry for LOCAL, then modify the layer 2
flooding flow actions from "output:patch,LOCAL" to
"output:patch,NORMAL". Since the FDB entry is bound in the table to
LOCAL, it is effectively forwarding the packets the same as before, but
with the added bonus of FDB learning on ingress.

Fixes: #5318

Signed-off-by: Tim Rozet <[email protected]>

Author: trozet

go-controller/pkg/node/gateway_shared_intf.go

@@ -1897,7 +1897,7 @@ func commonFlows(hostSubnets []*net.IPNet, bridge *bridgeConfiguration) ([]strin
 		for _, netConfig := range bridge.patchedNetConfigs() {
 			actions += "output:" + netConfig.ofPortPatch + ","
 		}
-		actions += strip_vlan + "output:" + ofPortHost
+		actions += strip_vlan + "NORMAL"
 		dftFlows = append(dftFlows,
 			fmt.Sprintf("cookie=%s, priority=10, table=0, in_port=%s, %s dl_dst=%s, actions=%s",
 				defaultOpenFlowCookie, ofPortPhys, match_vlan, bridgeMacAddress, actions))