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

 Problem Description: Clearly explain the issue.

While parsing packets, OVS only recognizes a few Ethernet packet formats: Ethernet II, LLC and SNAP. When a packet doesn't match any of the header formats we support, Open vSwitch and OpenFlow set the dl_type field to 0x5ff (OFP_DL_TYPE_NOT_ETH_TYPE).

When such a frame hits OVN, it seems to be broadcasted, or otherwise loops through the logical network and likely ends up dropped due to resubmit limit if the switch has many routers attached. The handling is similar to how broadcast traffic is treated because the frame has a multicast destination Ethernet address in our case. An example of such a packet being dropped by OVS is in the first comment (private).

OVN should probably handle this kind of traffic explicitly. Some options:
1. Always drop. Maybe a little too harsh, as some systems are known to use frames of 0x05ff for their own purposes, I found some mentions of ESX using such frames.
2. Forward to LSPs, but don't forward to routers.  This may be the most reasonable option as OVN routers wouldn't know what to do with this traffic anyway, but nothing prevents us from forwarding the packet within L2 domain of a Logical Switch.
3.  Maybe make the behavior configurable as in the case of broadcast ARP forwarding. Doesn't sound like we need to have this configurable though.
 

 Impact Assessment: Describe the severity and impact (e.g., network down,availability of a workaround, etc.).

The impact is that this traffic can eat some OVS resources to pass it through all the logical routers, just to drop the frame in the end. External network may generate quite a few of such frames.
 

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

New issue.
 

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

Seen in logs from a customer's setup.