Multicast

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.

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

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

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

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.

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

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/