After the recent upgrade of the proxmox hypervisors, which included an update of openvswitch to 2.5.0 (from 2.3.2), we can no longer push the MP-VPN multicast fanout flows to the OVS switches. These flows take a packet from a VLAN interface and fan it out to multiple VLAN interfaces. Generally these VLAN interfaces are all on the same switch port.
openvswitch will not output a packet to the same port it arrived on, so we rely on a documented hack in openvswitch to munge the inport metadata for a packet to a non-existent port (OFP_NONE), so that we can send it to any output packet we need to. Starting in openvswitch 2.4.0, this method no longer works.
The most likely solution is to use a different mechanism to forward packets to their same output port (possibly on a different VLAN), which is the use the special IN_PORT output port number to indicate this.
As I write this, I have this change coded up but not tested yet. Filing an issue to capture that this is an issue actively being worked on, and we need this immediately to deploy the MP-VPN application on the SDN testbed.
After the recent upgrade of the proxmox hypervisors, which included an update of openvswitch to 2.5.0 (from 2.3.2), we can no longer push the MP-VPN multicast fanout flows to the OVS switches. These flows take a packet from a VLAN interface and fan it out to multiple VLAN interfaces. Generally these VLAN interfaces are all on the same switch port.
openvswitch will not output a packet to the same port it arrived on, so we rely on a documented hack in openvswitch to munge the inport metadata for a packet to a non-existent port (OFP_NONE), so that we can send it to any output packet we need to. Starting in openvswitch 2.4.0, this method no longer works.
The most likely solution is to use a different mechanism to forward packets to their same output port (possibly on a different VLAN), which is the use the special IN_PORT output port number to indicate this.
As I write this, I have this change coded up but not tested yet. Filing an issue to capture that this is an issue actively being worked on, and we need this immediately to deploy the MP-VPN application on the SDN testbed.