[Bridge] R: IGMP snooping not filtering multicast messages

maxd at inwind.it maxd at inwind.it
Thu Jun 2 07:27:32 PDT 2011


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 at inwind.it
>Data: 31/05/2011 19.48
>A: <bridge at 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 at lists.linux-foundation.org
>https://lists.linux-foundation.org/mailman/listinfo/bridge
>




More information about the Bridge mailing list