All of lore.kernel.org
 help / color / mirror / Atom feed
From: "maxd@inwind.it" <maxd@inwind.it>
To: maxd@inwind.it, bridge@lists.linux-foundation.org
Cc: herbert@gondor.hengli.com.au
Subject: [Bridge] R:  IGMP snooping not filtering multicast messages
Date: Thu, 2 Jun 2011 16:27:32 +0200 (CEST)	[thread overview]
Message-ID: <13241740.548471307024852060.JavaMail.defaultUser@defaultHost> (raw)

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
>



             reply	other threads:[~2011-06-02 14:27 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-06-02 14:27 maxd [this message]
2011-06-02 23:29 ` [Bridge] R: IGMP snooping not filtering multicast messages Herbert Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=13241740.548471307024852060.JavaMail.defaultUser@defaultHost \
    --to=maxd@inwind.it \
    --cc=bridge@lists.linux-foundation.org \
    --cc=herbert@gondor.hengli.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.