David Marchand <[email protected]> writes:
> On Thu, Nov 9, 2023 at 4:33 PM Paolo Valerio <[email protected]> wrote:
>>
>> David Marchand <[email protected]> writes:
>>
>> > When multicast snooping is enabled and a reporter is known, it is still
>> > possible to flood associated packets to some other port via the
>> > mcast-snooping-flood option.
>> >
>> > Test this combination.
>> >
>> > Signed-off-by: David Marchand <[email protected]>
>> > ---
>> > tests/mcast-snooping.at | 88 +++++++++++++++++++++++++++++++++++++++++
>> > 1 file changed, 88 insertions(+)
>> >
>> > diff --git a/tests/mcast-snooping.at b/tests/mcast-snooping.at
>> > index d5b7c4774c..21c806ef63 100644
>> > --- a/tests/mcast-snooping.at
>> > +++ b/tests/mcast-snooping.at
>> > @@ -105,6 +105,94 @@ AT_CHECK([ovs-appctl mdb/show br0], [0], [dnl
>> > OVS_VSWITCHD_STOP
>> > AT_CLEANUP
>> >
>> > +
>> > +AT_SETUP([mcast - check flooding on ports])
>> > +OVS_VSWITCHD_START([])
>> > +
>> > +AT_CHECK([
>> > + ovs-vsctl set bridge br0 \
>> > + datapath_type=dummy \
>> > + mcast_snooping_enable=true \
>> > + other-config:mcast-snooping-disable-flood-unregistered=false
>> > +], [0])
>> > +
>>
>> in the case flood unregistered is disabled packets are supposed to
>> be sent to flood ports. While at it, it might also be worth testing that
>> like in the quick example at the end I used to test it.
>> WDYT?
>
> It sounds reasonable yes.
>
> I was also considering testing reports flooding.
> WDYT?
>
if you mean testing mcast-snooping-flood-reports, that would be nice.
This way that flag as well will have some coverage.
>
>>
>> > +AT_CHECK([ovs-ofctl add-flow br0 action=normal])
>> > +
>> > +AT_CHECK([
>> > + ovs-vsctl add-port br0 p1 \
>> > + -- set Interface p1 type=dummy other-config:hwaddr=aa:55:aa:55:00:01
>> > ofport_request=1 \
>> > + -- add-port br0 p2 \
>> > + -- set Interface p2 type=dummy other-config:hwaddr=aa:55:aa:55:00:02
>> > ofport_request=2 \
>> > + -- add-port br0 p3 \
>> > + -- set Interface p3 type=dummy other-config:hwaddr=aa:55:aa:55:00:03
>> > ofport_request=3 \
>> > +], [0])
>> > +
>> > +ovs-appctl time/stop
>> > +
>> > +# send report packets
>> > +AT_CHECK([
>> > + ovs-appctl netdev-dummy/receive p1 \
>> > +
>> > '01005E010101000C29A027A108004500001C000100004002CBAEAC10221EE001010112140CE9E0010101'
>> > +], [0])
>> > +
>> > +AT_CHECK([ovs-appctl mdb/show br0], [0], [dnl
>> > + port VLAN GROUP Age
>> > + 1 0 224.1.1.1 0
>> > +])
>> > +
>> > +AT_CHECK([ovs-appctl ofproto/trace
>> > "in_port(3),eth(src=aa:55:aa:55:00:ff,dst=01:00:5e:5e:01:01),eth_type(0x0800),ipv4(src=10.0.0.1,dst=224.1.1.1,proto=17,tos=0,ttl=64,frag=no),udp(src=0,dst=8000)"],
>> > [0], [dnl
>> > +Flow:
>> > udp,in_port=3,vlan_tci=0x0000,dl_src=aa:55:aa:55:00:ff,dl_dst=01:00:5e:5e:01:01,nw_src=10.0.0.1,nw_dst=224.1.1.1,nw_tos=0,nw_ecn=0,nw_ttl=64,nw_frag=no,tp_src=0,tp_dst=8000
>> > +
>>
>> I think the mac for 224.1.1.1 maps to 01:00:5e:01:01:01.
>
> Argh.. indeed, wrong copy/paste.
> Thanks for the review!
>
thank you for working on this!
>>
>> > +bridge("br0")
>> > +-------------
>> > + 0. priority 32768
>> > + NORMAL
>> > + -> forwarding to mcast group port
>
>
> --
> David Marchand
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
