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