Thanks Alex! Please see inlined: On Thu, Jun 12, 2014 at 1:30 PM, Alex Wang <al...@nicira.com> wrote: > > > For OVS-2.0, we still use facet and subfacet in ofproto-dpif to keeps record > of the flows. And the flow revalidation logic is quite different from later > branches. So, the fix in later branches does not apply here. > What was the revalidation logic in OVS2.0? Why is it retrying for 10 minutes and switch to the next one? I should check the 2.0 code myself but just have no time yet.
> > What you saw likely indicates the following scenario: e.g. > a datapath flow could be dumped -> but ovs could not find corresponding > subfacet (due to bug) -> so, ovs deleted the datapath flow -> later when > the subfacet is to be deleted, it tries deleting the datapath flow -> but > the datapath flow does not exist and you saw the warning in log. > I can still dump the flows with ovs-dpctl dump-flows, but can not delete them by ovs-dpctl del-flow system@ovs-system "...", the same error (No such file or directory) returned. Would it be helpful and safe to do ovs-dpctl del-flows (to delete all datapath flows)? > > But, it surprised me that you saw 60+ flows in datapath that should be > deleted. Did those 'Zombie' flows get hit? Could you provide more info > about how to reproduce it? > These flows are learned from standalone bridge: they are for STT tunnel between hypervisors (TCP dst 7471). The "used" field is "never". The STT port was already changed long time ago, because when I do tcpdump for port 7471 I can see the new port with the peer IP. So these are really zombie flows. And for now I just want to clean them up to stop the logs flooding. It is not easy to be reproduced because I checked several other hypervisors there is no such issue. Best regards, Han _______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
