Yes!, The problem was that we are snooping packets on the external side of networks, and eventually we not only see the gARPs or packets we are looking for, but we also see other ARP requests of external ports (used for tunneling) looking for each othes. This didn't happen to me on my system but when I changed to an Ubuntu VM that must have different sysctl timers for ARP.
Also for gARPs we most of the time found 2 packets, and sometimes 1. I looked like machine/timing reasons, so I decided to make it less strict: 1 or more packets would mean the specific chassis is positive on sending gARPs now (uniq filter) 0 packets == the chassis is not sending gARPs for a router. El 19 jul. 2017 4:40 a. m., "Russell Bryant" <[email protected]> escribió: > On Tue, Jul 18, 2017 at 10:55 AM, Miguel Angel Ajo <[email protected]> > wrote: > > An specific ovn/l3ha test looks for port releases in the MASTER > > gateway when another gateway on the Gateway_Chassis list is gone. > > > > But we didn't clean the log before taking out the chassis, so > > any previous unrelated occurrence could make the test fail > > while it was ok. > > > > Signed-off-by: Miguel Angel Ajo <[email protected]> > > --- > > tests/ovn.at | 2 ++hy > > 1 file changed, 2 insertions(+) > > Thanks, I applied this patch series to master. > > While I was OK with applying patch 3 as it is to make the test more > reliable, can you expand on why you had to filter out packets? Why > can't we have the test know exactly what packets to expect? > > -- > Russell Bryant > _______________________________________________ > dev mailing list > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
