Ethernet Bridge development
 help / color / mirror / Atom feed
* [Bridge] Multicast
@ 2005-06-08  7:43 Tomo Ceferin
  2005-06-08 16:31 ` Stephen Hemminger
  0 siblings, 1 reply; 8+ messages in thread
From: Tomo Ceferin @ 2005-06-08  7:43 UTC (permalink / raw)
  To: bridge

Hi,

I checked archives but I haven't found this subject before.

Does bridge support multicast or not? I checked the code and it would seem
that bridge will flood multicast frames to all but source port.

Rgds, Tomo Ceferin
Active Tools


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bridge] Multicast
  2005-06-08  7:43 [Bridge] Multicast Tomo Ceferin
@ 2005-06-08 16:31 ` Stephen Hemminger
  2005-06-09  8:48   ` Tomo Ceferin
  2005-06-09  9:02   ` Guillermo Ibáñez
  0 siblings, 2 replies; 8+ messages in thread
From: Stephen Hemminger @ 2005-06-08 16:31 UTC (permalink / raw)
  To: Tomo Ceferin; +Cc: bridge

On Wed, 8 Jun 2005 09:43:46 +0200
"Tomo Ceferin" <tomo@activetools.si> wrote:

> Hi,
> 
> I checked archives but I haven't found this subject before.
> 
> Does bridge support multicast or not? I checked the code and it would seem
> that bridge will flood multicast frames to all but source port.
> 
> Rgds, Tomo Ceferin
> Active Tools

Yes, that is what multicast is.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [Bridge] Multicast
  2005-06-08 16:31 ` Stephen Hemminger
@ 2005-06-09  8:48   ` Tomo Ceferin
  2005-06-10 20:14     ` Ted Deppner
  2005-06-09  9:02   ` Guillermo Ibáñez
  1 sibling, 1 reply; 8+ messages in thread
From: Tomo Ceferin @ 2005-06-09  8:48 UTC (permalink / raw)
  To: 'Stephen Hemminger'; +Cc: bridge

> From: Stephen Hemminger [mailto:shemminger@osdl.org] 
> 
> Yes, that is what multicast is.

Then what is broadcast? Multicast should only forward frames to ports that
belong to the multicast groups that frame is designated for. In most networks
replacing multicast with broadcast doesn't present a problem, but when
bandwidth of ports is rather modest (say 10 Mb/s) and you expect video streams
(5 Mb/s) to be distributed via multicast, the topic suddenly becomes rather
important.

Did anyone already have to deal with this? If not, I think it's time bridge
got a proper multicast implementation as well.

Rgds, Tomo



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bridge] Multicast
  2005-06-08 16:31 ` Stephen Hemminger
  2005-06-09  8:48   ` Tomo Ceferin
@ 2005-06-09  9:02   ` Guillermo Ibáñez
  2005-06-09 14:33     ` Tomo Ceferin
  1 sibling, 1 reply; 8+ messages in thread
From: Guillermo Ibáñez @ 2005-06-09  9:02 UTC (permalink / raw)
  To: bridge

Just an explanation to distinguish processing of layer 3 multicast 
packets (by routers) from layer 2 multicast frames (by bridges).  Due to 
the fact that the multicast MAC addresses are not permitted in the 
Ethernet frame as source addresses, multicast MAC addresses can not be 
learnt by the bridges, so the processing of multicast addresses by 
bridges consists in broadcasting, flooding frames in all but source 
port, instead of forwarding them only by ports where these addresses 
were learnt.
Excuse me if it sounds a bit "academic".
GI

Stephen Hemminger wrote:

>On Wed, 8 Jun 2005 09:43:46 +0200
>"Tomo Ceferin" <tomo@activetools.si> wrote:
>
>  
>
>>Hi,
>>
>>I checked archives but I haven't found this subject before.
>>
>>Does bridge support multicast or not? I checked the code and it would seem
>>that bridge will flood multicast frames to all but source port.
>>
>>Rgds, Tomo Ceferin
>>Active Tools
>>    
>>
>
>Yes, that is what multicast is.
>  
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Bridge mailing list
>Bridge@lists.osdl.org
>http://lists.osdl.org/mailman/listinfo/bridge
>  
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [Bridge] Multicast
  2005-06-09  9:02   ` Guillermo Ibáñez
@ 2005-06-09 14:33     ` Tomo Ceferin
  2005-06-09 18:17       ` Stephen Hemminger
  0 siblings, 1 reply; 8+ messages in thread
From: Tomo Ceferin @ 2005-06-09 14:33 UTC (permalink / raw)
  To: bridge

True. However, allow me to make two assumptions (true in our case):
1) Bridge implements set_multicast_list() and uses it to learn multicast
groups.
2) IPv4 or IPv6 is attached to bridge - both provide IGMP snooping which in
turn feeds bridge with multicast lists through set_multicast_list().

With both above assumptions true, bridge now has awareness of which ports
belong to which multicast groups, hence removing the need to flood all ports.

Am I getting something wrong?

Tomo

> -----Original Message-----
> From: Guillermo Ibáñez
> 
> Just an explanation to distinguish processing of layer 3 multicast 
> packets (by routers) from layer 2 multicast frames (by 
> bridges).  Due to 
> the fact that the multicast MAC addresses are not permitted in the 
> Ethernet frame as source addresses, multicast MAC addresses 
> can not be 
> learnt by the bridges, so the processing of multicast addresses by 
> bridges consists in broadcasting, flooding frames in all but source 
> port, instead of forwarding them only by ports where these addresses 
> were learnt.
> Excuse me if it sounds a bit "academic".
> GI



^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bridge] Multicast
  2005-06-09 14:33     ` Tomo Ceferin
@ 2005-06-09 18:17       ` Stephen Hemminger
  2005-06-10  8:39         ` Tomo Ceferin
  0 siblings, 1 reply; 8+ messages in thread
From: Stephen Hemminger @ 2005-06-09 18:17 UTC (permalink / raw)
  To: Tomo Ceferin; +Cc: bridge

On Thu, 9 Jun 2005 16:33:44 +0200
"Tomo Ceferin" <tomo@activetools.si> wrote:

> True. However, allow me to make two assumptions (true in our case):
> 1) Bridge implements set_multicast_list() and uses it to learn multicast
> groups.
> 2) IPv4 or IPv6 is attached to bridge - both provide IGMP snooping which in
> turn feeds bridge with multicast lists through set_multicast_list().
> 
> With both above assumptions true, bridge now has awareness of which ports
> belong to which multicast groups, hence removing the need to flood all ports.
> 
> Am I getting something wrong?

1. Bridge does more than IP and so it knows nothing about IP protocols. Many
   times a bridge has no IP address at all.

2. The bridge machine itself may not be listening the multicast traffic but
   needs to forward it.

3. If you need to do some filtering of multicast, than use netfilter (ebtables)
   to restrict the traffic.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* RE: [Bridge] Multicast
  2005-06-09 18:17       ` Stephen Hemminger
@ 2005-06-10  8:39         ` Tomo Ceferin
  0 siblings, 0 replies; 8+ messages in thread
From: Tomo Ceferin @ 2005-06-10  8:39 UTC (permalink / raw)
  To: bridge

Two mistakes I made:
1) Bridge's set_multicast_list() is never called. Only devices that create
sk_buff-s are notified of changes to mc_list member in their net_device
structure.

2) Even if someone did call it, the information in mc_list is not sufficient
to use it in implementation of multicast.

I have learned however that by implementing IGMP snooping in bridge I could
learn enough to 'properly' support multicast. By monitoring multicast group
joins and leaves I should be able to tell to which ports a multicast frame
should be forwarded.

Tomo

> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@osdl.org] 
> Sent: 9. junij 2005 20:18
> To: Tomo Ceferin
> Cc: bridge@lists.osdl.org
> Subject: Re: [Bridge] Multicast
> 
> 
> On Thu, 9 Jun 2005 16:33:44 +0200
> "Tomo Ceferin" <tomo@activetools.si> wrote:
> 
> > True. However, allow me to make two assumptions (true in our case):
> > 1) Bridge implements set_multicast_list() and uses it to learn 
> > multicast groups.
> > 2) IPv4 or IPv6 is attached to bridge - both provide IGMP snooping 
> > which in turn feeds bridge with multicast lists through 
> > set_multicast_list().
> > 
> > With both above assumptions true, bridge now has awareness of which 
> > ports belong to which multicast groups, hence removing the need to 
> > flood all ports.
> > 
> > Am I getting something wrong?
> 
> 1. Bridge does more than IP and so it knows nothing about IP 
> protocols. Many
>    times a bridge has no IP address at all.
> 
> 2. The bridge machine itself may not be listening the 
> multicast traffic but
>    needs to forward it.
> 
> 3. If you need to do some filtering of multicast, than use 
> netfilter (ebtables)
>    to restrict the traffic.
> 


^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [Bridge] Multicast
  2005-06-09  8:48   ` Tomo Ceferin
@ 2005-06-10 20:14     ` Ted Deppner
  0 siblings, 0 replies; 8+ messages in thread
From: Ted Deppner @ 2005-06-10 20:14 UTC (permalink / raw)
  To: Tomo Ceferin; +Cc: bridge

On Thu, Jun 09, 2005 at 10:48:36AM +0200, Tomo Ceferin wrote:
> Did anyone already have to deal with this? If not, I think it's time bridge
> got a proper multicast implementation as well.

I've dealt with this in the context of a locally generated multicast
source being sent out a bridge interface to two physical ethernet
interfaces.  This was a video stream and ran at various bit rates from
3.5mb up to 20mbit (as single streams).

Everything worked properly until the MTU was raised past 1500 bytes.  Once
the traffic had to be fragmented, then the bridge stopped sending the
packets out both physicial interfaces, and would only send out the first
physical interface that was added to the bridge.

-- 
Ted Deppner
http://www.deppner.us/

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-06-10 20:14 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-06-08  7:43 [Bridge] Multicast Tomo Ceferin
2005-06-08 16:31 ` Stephen Hemminger
2005-06-09  8:48   ` Tomo Ceferin
2005-06-10 20:14     ` Ted Deppner
2005-06-09  9:02   ` Guillermo Ibáñez
2005-06-09 14:33     ` Tomo Ceferin
2005-06-09 18:17       ` Stephen Hemminger
2005-06-10  8:39         ` Tomo Ceferin

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox