On Fri, Jul 31, 2026 at 11:23 AM Dumitru Ceara <[email protected]> wrote:
> On 7/31/26 10:08 AM, Ales Musil wrote:
> > The test could fail if there was enough time for the gARP to arrive
> > before we would check the pcap file. Disable the gARP annoucement
> > for the VIF to prevent that.
> >
> > Fixes: d533ac4793d3 ("Revert "northd: Fix HM reply lflow for
> type=external backends on localnet LS."")
> > Signed-off-by: Ales Musil <[email protected]>
> > ---
>
> Hi Ales,
>
> Thanks for the fix!
>
Hi Dumitru.
>
> > tests/ovn.at | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/tests/ovn.at b/tests/ovn.at
> > index a88ea9650..310ad501a 100644
> > --- a/tests/ovn.at
> > +++ b/tests/ovn.at
> > @@ -46661,8 +46661,9 @@ check ovn-nbctl ls-add sw \
> > -- lsp-set-addresses sw-ln unknown \
> > -- lsp-set-options sw-ln network_name=phys mcast_flood_reports=true
> >
> > -check ovn-nbctl lsp-add sw sw-p1 \
> > - -- lsp-set-addresses sw-p1 "00:00:00:00:00:10 10.0.0.10"
> > +check ovn-nbctl lsp-add sw sw-p1 \
> > + -- lsp-set-addresses sw-p1 "00:00:00:00:00:10 10.0.0.10" \
> > + -- lsp-set-options sw-p1 disable_garp_rarp=true
> >
> > check ovn-nbctl lsp-add sw sw-ext \
> > -- lsp-set-type sw-ext external \
>
> Lower we do:
>
> # Wait for pinctrl to fully process the IGMP/MLD reports and sync them
> # to the SB database. This guarantees that pinctrl has also re-injected
> # the reports for flooding to mrouters (where the loopback would occur).
> # The unicast unknown packet (sent first) was processed synchronously in
> # the datapath, so it is certainly done by now.
> wait_row_count IGMP_Group 1 address=239.1.2.3
> wait_row_count IGMP_Group 1 address='"ff0a:dead:beef::1"'
>
> # None of the packets must have been sent back to the localnet port.
> AT_CHECK([$PYTHON "$ovs_srcdir/utilities/ovs-pcap.in" \
> hv1/br-phys_n1-tx.pcap > tx_packets.txt])
> AT_CHECK([test ! -s tx_packets.txt])
>
> Would it make sense to change the check here and just grep for the 3
> packets we don't expect to be received on br-phys_n1-tx.pcap? I'm
> worried that in the future other packets (not the GARPs) might be caught
> here.
>
> What do you think?
>
Yeah that is reasonable, this is probably the safer option. I will post v2
with that instead.
>
> Also, there's a small race as we don't know for sure whether the packet
> has actually been forwarded by the time we check the pcap but I'm not
> sure we can do anything better about that.
>
Unfortunately I'm not sure what could we do about that, it would be handy
to have some ovs-appctl call that would tell us all packets were delivered.
>
> Regards,
> Dumitru
>
>
Regards,
Ales
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
