Ian/Brent/Matt,

 

We analyze the patch 9671feb related to l2pop. We think that this is not a bug for neutron ovs and suggest not to upstream. Because for the outgoing packet that destination unknown, avs agent may drop the packet while ovs agent will flood it and finally learn the flows. Could you please help to review and comment? Thanks very much!

 

Patch ID: 9671feb

Patch Description: l2pop: allow csnat ports in list of endpoints. Not quite sure why upstream is not impacted by this issue, but we need to have CSNAT ports included in the list of ports that the l2pop driver handles. Without this it is not possible for a VM on one node to reach the CSNAT port because the MAC address of the CSNAT port is not included in the static FDB entries.  Without this our vswitch drops the outgoing packet since that's what it does with packets to unknown destinations while in static mode.

Patch Analysis Report: You can find it in the attachment

Comment: We setup an environment(Openstack: DVR + L3 HA + L2POP) to check the bug exists or not in neutron ovs. Several scenarios are checked and the result shows that the patch 9671feb is not a bug for neutron ovs. In each scenario, we check whether the vm can ping the router’s gateway or not and the flows in the compute node exists or not. In all scenarios, the router’s gateway can be accessed. The flows related to csnat port exists after the csnat port is created except for the third scenario. In the third scenario(a new host is added to the openstack, thus the host don’t have the flows for l2pop), when a vm is created on the new host, all fdbs(except ha and csnat port) should be sent to this host due to that the port created is the first port in this host. And now there are no flows related to csnat port. After ping router’s gateway, the flows related to csnat port appears. This means that ovs agent won’t drop the outgoing packet that destination unknown and will flood it. Below is the result:

 

Before ping router’s gateway(fa:16:3e:72:06:05 is csnat port’s mac address), there are no flows related to csnat port.

This means that the fdb for csnat port is not sent to the host even the first port is created due to a vm creation.

 

After ping router’s gateway, the flow related to csnat port appears.

This means that ovs agent won’t drop the outgoing packet that destination unknown and will flood it.

 

 

 

Best Regards,

Xu, Chenjie