* VLAN aware bridge multicast and quierer problems
@ 2024-03-13 15:40 Andrew Lunn
2024-03-13 16:03 ` Nikolay Aleksandrov
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Lunn @ 2024-03-13 15:40 UTC (permalink / raw)
To: Nikolay Aleksandrov, Ido Schimmel; +Cc: netdev
Hi Nikolay, Ido
I have a colleague who is using a VLAN aware bridge with
multicast. IGMP snooping is causing problems in this setup. The setup
periodically sends IPv6 router solicitations towards the router and
expects router advertisements back. After a while, the router
solicitations were no longer forwarded/flooded by the bridge.
The bridge doesn't drop the RS frames, but instead of forwarding them
using br_flood(), it calls br_mulricast_flood() with an empty
destination list. MC snooping is on by default and is VLAN-aware by
default, so it should work in this context. If he disable it for
testing purposes, the RS get forwarded.
We then checked how the destination list gets computed. Not very
surprisingly, this is based on MC group membership reports in
combination with MC querier tracking (no querier -> no MC snooping,
i.e. br_flood() instead of br_multicast_flood()). So far, so good. We
don't have a querier on the VLAN in question but we do have one on
another VLAN running over the same bridge. And then he noticed that
br_multicast_querier_exists() which is called by
br_handle_frame_finish() to decide whether it can rely on snooped MC
groups doesn't get any VLAN information, only the global bridge
multicast context. So it can't possibly know whether there's a querier
on the VLAN the frame to be forwarded is on. As soon as there's a
querier on one VLAN, the code seems to assume that there are queriers
on all of them. And on those without an actual querier, this means
that destination lists are empty because there are no membership
reports on these VLANs (at least not after the initial reports right
after joining a group).
It seems odd that you spent a lot of time adding code to track group
memberships by VLAN but then left our the last tiny bit to also track
queriers by VLAN? So we are wondering if we are missing something,
some configuration somewhere?
We have a test script which sets up a bridge in a network name space,
and uses scapy and tcpdump to show the problem. I can send it to you
if you are interested.
Thanks
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VLAN aware bridge multicast and quierer problems
2024-03-13 15:40 VLAN aware bridge multicast and quierer problems Andrew Lunn
@ 2024-03-13 16:03 ` Nikolay Aleksandrov
2024-03-13 16:36 ` Andrew Lunn
2024-03-13 16:56 ` Andrew Lunn
0 siblings, 2 replies; 6+ messages in thread
From: Nikolay Aleksandrov @ 2024-03-13 16:03 UTC (permalink / raw)
To: Andrew Lunn, Ido Schimmel; +Cc: netdev
On 3/13/24 17:40, Andrew Lunn wrote:
> Hi Nikolay, Ido
>
> I have a colleague who is using a VLAN aware bridge with
> multicast. IGMP snooping is causing problems in this setup. The setup
> periodically sends IPv6 router solicitations towards the router and
> expects router advertisements back. After a while, the router
> solicitations were no longer forwarded/flooded by the bridge.
>
> The bridge doesn't drop the RS frames, but instead of forwarding them
> using br_flood(), it calls br_mulricast_flood() with an empty
> destination list. MC snooping is on by default and is VLAN-aware by
> default, so it should work in this context. If he disable it for
> testing purposes, the RS get forwarded.
>
> We then checked how the destination list gets computed. Not very
> surprisingly, this is based on MC group membership reports in
> combination with MC querier tracking (no querier -> no MC snooping,
> i.e. br_flood() instead of br_multicast_flood()). So far, so good. We
> don't have a querier on the VLAN in question but we do have one on
> another VLAN running over the same bridge. And then he noticed that
> br_multicast_querier_exists() which is called by
> br_handle_frame_finish() to decide whether it can rely on snooped MC
> groups doesn't get any VLAN information, only the global bridge
> multicast context. So it can't possibly know whether there's a querier
> on the VLAN the frame to be forwarded is on. As soon as there's a
> querier on one VLAN, the code seems to assume that there are queriers
> on all of them. And on those without an actual querier, this means
> that destination lists are empty because there are no membership
> reports on these VLANs (at least not after the initial reports right
> after joining a group).
>
> It seems odd that you spent a lot of time adding code to track group
> memberships by VLAN but then left our the last tiny bit to also track
> queriers by VLAN? So we are wondering if we are missing something,
> some configuration somewhere?
>
> We have a test script which sets up a bridge in a network name space,
> and uses scapy and tcpdump to show the problem. I can send it to you
> if you are interested.
>
> Thanks
> Andrew
Hi Andrew,
Please check again, br_multicast_rcv() which is called before
br_multicast_querier_exists() should set brmctx and pmctx to
the proper vlan contexts. If vlan igmp snooping is enabled then
the call to br_multicast_querier_exists() is done with the vlan's
contexts. I'd guess per-vlan igmp snooping is not enabled (it is not
enabled by default).
Cheers,
Nik
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VLAN aware bridge multicast and quierer problems
2024-03-13 16:03 ` Nikolay Aleksandrov
@ 2024-03-13 16:36 ` Andrew Lunn
2024-03-13 16:46 ` Nikolay Aleksandrov
2024-03-13 16:56 ` Andrew Lunn
1 sibling, 1 reply; 6+ messages in thread
From: Andrew Lunn @ 2024-03-13 16:36 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: Ido Schimmel, netdev
> Hi Andrew,
> Please check again, br_multicast_rcv() which is called before
> br_multicast_querier_exists() should set brmctx and pmctx to
> the proper vlan contexts. If vlan igmp snooping is enabled then
> the call to br_multicast_querier_exists() is done with the vlan's
> contexts. I'd guess per-vlan igmp snooping is not enabled (it is not
> enabled by default).
I will check. However, if per-vlan igmp snooping is not enabled i
would expect it to flood, but it is not.
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VLAN aware bridge multicast and quierer problems
2024-03-13 16:36 ` Andrew Lunn
@ 2024-03-13 16:46 ` Nikolay Aleksandrov
0 siblings, 0 replies; 6+ messages in thread
From: Nikolay Aleksandrov @ 2024-03-13 16:46 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Ido Schimmel, netdev
On 3/13/24 18:36, Andrew Lunn wrote:
>> Hi Andrew,
>> Please check again, br_multicast_rcv() which is called before
>> br_multicast_querier_exists() should set brmctx and pmctx to
>> the proper vlan contexts. If vlan igmp snooping is enabled then
>> the call to br_multicast_querier_exists() is done with the vlan's
>> contexts. I'd guess per-vlan igmp snooping is not enabled (it is not
>> enabled by default).
>
> I will check. However, if per-vlan igmp snooping is not enabled i
> would expect it to flood, but it is not.
>
> Andrew
>
There is a querier in another vlan connected to the bridge as you
mentioned, that is considered global if per-vlan igmp is not enabled.
Why should it flood in that case?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VLAN aware bridge multicast and quierer problems
2024-03-13 16:03 ` Nikolay Aleksandrov
2024-03-13 16:36 ` Andrew Lunn
@ 2024-03-13 16:56 ` Andrew Lunn
2024-03-13 16:58 ` Nikolay Aleksandrov
1 sibling, 1 reply; 6+ messages in thread
From: Andrew Lunn @ 2024-03-13 16:56 UTC (permalink / raw)
To: Nikolay Aleksandrov; +Cc: Ido Schimmel, netdev
> Hi Andrew,
> Please check again, br_multicast_rcv() which is called before
> br_multicast_querier_exists() should set brmctx and pmctx to
> the proper vlan contexts. If vlan igmp snooping is enabled then
> the call to br_multicast_querier_exists() is done with the vlan's
> contexts. I'd guess per-vlan igmp snooping is not enabled (it is not
> enabled by default).
So i have the test running, and i see:
# bridge vlan global show
port vlan-id
brtest0 1
mcast_snooping 1 mcast_querier 0 mcast_igmp_version 2 mcast_
mld_version 1 mcast_last_member_count 2 mcast_last_member_interval 100 mcast_sta
rtup_query_count 2 mcast_startup_query_interval 3125 mcast_membership_interval 2
6000 mcast_querier_interval 25500 mcast_query_interval 12500 mcast_query_respons
e_interval 1000
100
mcast_snooping 1 mcast_querier 0 mcast_igmp_version 2 mcast_
mld_version 1 mcast_last_member_count 2 mcast_last_member_interval 100 mcast_sta
rtup_query_count 2 mcast_startup_query_interval 3125 mcast_membership_interval 2
6000 mcast_querier_interval 25500 mcast_query_interval 12500 mcast_query_respons
e_interval 1000
200
mcast_snooping 1 mcast_querier 0 mcast_igmp_version 2 mcast_
mld_version 1 mcast_last_member_count 2 mcast_last_member_interval 100 mcast_sta
rtup_query_count 2 mcast_startup_query_interval 3125 mcast_membership_interval 2
6000 mcast_querier_interval 25500 mcast_query_interval 12500 mcast_query_respons
e_interval 1000
The fact that 'mcast_snooping 1' indicates to me snooping is enabled
by default? The test case does not change any snooping configuration.
I will send you off list the test script.
Andrew
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: VLAN aware bridge multicast and quierer problems
2024-03-13 16:56 ` Andrew Lunn
@ 2024-03-13 16:58 ` Nikolay Aleksandrov
0 siblings, 0 replies; 6+ messages in thread
From: Nikolay Aleksandrov @ 2024-03-13 16:58 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Ido Schimmel, netdev
On 3/13/24 18:56, Andrew Lunn wrote:
>> Hi Andrew,
>> Please check again, br_multicast_rcv() which is called before
>> br_multicast_querier_exists() should set brmctx and pmctx to
>> the proper vlan contexts. If vlan igmp snooping is enabled then
>> the call to br_multicast_querier_exists() is done with the vlan's
>> contexts. I'd guess per-vlan igmp snooping is not enabled (it is not
>> enabled by default).
>
> So i have the test running, and i see:
>
> # bridge vlan global show
> port vlan-id
> brtest0 1
> mcast_snooping 1 mcast_querier 0 mcast_igmp_version 2 mcast_
> mld_version 1 mcast_last_member_count 2 mcast_last_member_interval 100 mcast_sta
> rtup_query_count 2 mcast_startup_query_interval 3125 mcast_membership_interval 2
> 6000 mcast_querier_interval 25500 mcast_query_interval 12500 mcast_query_respons
> e_interval 1000
> 100
> mcast_snooping 1 mcast_querier 0 mcast_igmp_version 2 mcast_
> mld_version 1 mcast_last_member_count 2 mcast_last_member_interval 100 mcast_sta
> rtup_query_count 2 mcast_startup_query_interval 3125 mcast_membership_interval 2
> 6000 mcast_querier_interval 25500 mcast_query_interval 12500 mcast_query_respons
> e_interval 1000
> 200
> mcast_snooping 1 mcast_querier 0 mcast_igmp_version 2 mcast_
> mld_version 1 mcast_last_member_count 2 mcast_last_member_interval 100 mcast_sta
> rtup_query_count 2 mcast_startup_query_interval 3125 mcast_membership_interval 2
> 6000 mcast_querier_interval 25500 mcast_query_interval 12500 mcast_query_respons
> e_interval 1000
>
>
> The fact that 'mcast_snooping 1' indicates to me snooping is enabled
> by default? The test case does not change any snooping configuration.
>
> I will send you off list the test script.
>
> Andrew
Oh there's a misunderstanding - this is the per-vlan control of
snooping. You have to enable the global per-vlan snooping for
these to take effect (mcast_vlan_snooping).
e.g.:
$ ip l set dev br0 type bridge vlan_filtering 1 mcast_vlan_snooping 1
You should verify in ip -d link sh dev <bridge> that mcast_vlan_snooping
is 1 (enabled), it is 0 (disabled) by default.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2024-03-13 16:58 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-13 15:40 VLAN aware bridge multicast and quierer problems Andrew Lunn
2024-03-13 16:03 ` Nikolay Aleksandrov
2024-03-13 16:36 ` Andrew Lunn
2024-03-13 16:46 ` Nikolay Aleksandrov
2024-03-13 16:56 ` Andrew Lunn
2024-03-13 16:58 ` Nikolay Aleksandrov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox