* [Bridge] R: IGMP snooping not filtering multicast messages
@ 2011-06-02 14:27 maxd
2011-06-02 23:29 ` Herbert Xu
0 siblings, 1 reply; 2+ messages in thread
From: maxd @ 2011-06-02 14:27 UTC (permalink / raw)
To: maxd, bridge; +Cc: herbert
As suggested by Herbert Xu (we exchanged a few private emails), I did a few
tests on a simpler network scenario, with a three hosts setup like this:
A e1 B e2 C
where e1/e2 are ports on B. e1 and e2 are bridged, and there is hence just one
bridge in the network.
Here, I have done the following actions:
1) Setup a listener on A.
When I do this, an IGMP report is generated by A and seen on node B.
2) Send some multicast packets to the group subscribed by A from B
In this case, I get that multicast packets are seen by A but not by C. So, B
is properly filtering the multicast messages, as expected.
I have also tried a few variations of this test:
-starting the listener on C, and I get that multicast messages are not
received by A (maybe this is a too trivial test!)
-changing the order in which the listener and the multicast source are
started: I get that multicast messages are initially flooded (both A and B
receive the messages), up to the point in which the listener starts on A, and C
does not receive the messages anymore
-setting the multicast_router flag to 0 -> no effect, IGMP snooping works as
in the original test
-setting the multicast_snooping flag to 0 -> multicast messages are received
on A and C (as expected).
I have also tested a scenario with 4 nodes
A eb1 B eb2 ec1 C ec2 D
where eb1/eb2 are ports on B, ec1/ec2 are ports on C. eb1/eb2 are bridged
together as well as ec1/ec2, so there are now two bridges in the network, on
node B and on node C.
I have repeated the same test on the 3 nodes scenario, i.e.,
1) setup a listener on A
The IGMP report generated by A is seen on B and C (not on D)
2) Send some multicast packets to the group subscribed by A from B
Multicast messages are seen on A and C, not on D.
Is this correct? I would expect messages just on A, not on C. I have also
repeated the test with the multicast_router flag set to 0, but I get the same
behaviour.
>----Messaggio originale----
>Da: maxd@inwind.it
>Data: 31/05/2011 19.48
>A: <bridge@lists.linux-foundation.org>
>Ogg: [Bridge] IGMP snooping not filtering multicast messages
>
>Hi. I have a partial mesh network composed by Linux nodes. Each linux node
may
>have up to 4 ethernet interfaces, which are exploited to create point-to-
point
>connections with other linux nodes. I have bridged the ethernet interfaces
in
>each node, so that the whole network, which is physically composed by a set
of
>network segments, appears as a single layer-2 domain. I have enabled
spanning
>tree to avoid loops. In this scenario, I would like to exploit the IGMP
>snooping functionality, but it seems that it is not working properly. I am
>using iperf to set a multicast source (iperf client) and a few multicast
sinks
>in the network (iperf servers). I am using tcpdump, instead, to check where
>multicast messages are received. What I notice is that there is apparently
no
>filtering of the multicast messages, that are always flooded in the network.
I
>tried to repeat the test varying the multicast address (paying attention not
to
>get reserved addresses), with and without multicast clients set, with the
>multicast_router option set to 1 (default) and to 0. To double check that
IGMP
>is working, I have also tried to disable it; the only difference I see is
that
>tcpdump does not show IGMP query messages when the IGMP snooping is
disabled.
>So, I am wondering if the IGMP snooping implementation currently available
can
>deal with my scenario. In particular, I would stress the following points
that
>I think might be relevant:
>-I have no multicast router in my network (it looks like a single stand-
alone
>lan)
>-Each node acts as a bridge, so I have multiple bridges in my network,
>connected each other.
>Any idea would be greatly appreciated!
>
>Massimiliano
>_______________________________________________
>Bridge mailing list
>Bridge@lists.linux-foundation.org
>https://lists.linux-foundation.org/mailman/listinfo/bridge
>
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [Bridge] R: IGMP snooping not filtering multicast messages
2011-06-02 14:27 [Bridge] R: IGMP snooping not filtering multicast messages maxd
@ 2011-06-02 23:29 ` Herbert Xu
0 siblings, 0 replies; 2+ messages in thread
From: Herbert Xu @ 2011-06-02 23:29 UTC (permalink / raw)
To: maxd@inwind.it; +Cc: bridge
On Thu, Jun 02, 2011 at 04:27:32PM +0200, maxd@inwind.it wrote:
>
> I have also tested a scenario with 4 nodes
>
> A eb1 B eb2 ec1 C ec2 D
>
> where eb1/eb2 are ports on B, ec1/ec2 are ports on C. eb1/eb2 are bridged
> together as well as ec1/ec2, so there are now two bridges in the network, on
> node B and on node C.
> I have repeated the same test on the 3 nodes scenario, i.e.,
> 1) setup a listener on A
> The IGMP report generated by A is seen on B and C (not on D)
> 2) Send some multicast packets to the group subscribed by A from B
> Multicast messages are seen on A and C, not on D.
> Is this correct? I would expect messages just on A, not on C. I have also
> repeated the test with the multicast_router flag set to 0, but I get the same
> behaviour.
This is expected because C would have generated queries so B will
mark it as a router and send all multicast packets to it.
Ideally we should end up with just a single querier in a network
so only it needs to see everything.
Right now this doesn't happen because we only send IPv4 queries
with a zero source address. I'm working on changing this so that
a real IP address can be used. When that happens whoever has the
lowest IP address numerically out of B/C will be designated as the
querier and the other bridge(s) will then stop sending queries and
will in time stop receiving unsubscribed groups.
I'll let you know when the patch is ready.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2011-06-02 23:29 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-06-02 14:27 [Bridge] R: IGMP snooping not filtering multicast messages maxd
2011-06-02 23:29 ` Herbert Xu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.