[Bridge] Multicast

[Bridge] Multicast

[Tomo Ceferin]

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

Re: [Bridge] Multicast

[Stephen Hemminger]

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.

RE: [Bridge] Multicast

[Tomo Ceferin]

> 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

Re: [Bridge] Multicast

[Ted Deppner]

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/

Re: [Bridge] Multicast

[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

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
>  
>

RE: [Bridge] Multicast

[Tomo Ceferin]

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

Re: [Bridge] Multicast

[Stephen Hemminger]

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.

RE: [Bridge] Multicast

[Tomo Ceferin]

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.
>