IGMP Multicast router overrun

Question

THE SYSTEM:

I have a L2 Managed 1Gbps switch with IGMP snooping (the switch I'm testing with is a TP-Link TL-SG3216). I have several identical devices (these are embedded devices that we are developing) attached to the switch, and this system is NOT connected to any other network.

While all devices send some data to all other devices, most of the time they spend in pairs (these pairs change with time). When paired, they utilise close to the full-bandwidth of the connection in one direction. I now have a situation where there are cases in which a device has to send the 1Gbps data stream to two or three devices at once: I need multicasting.

If I were to broadcast this data the other ports would become congested and would effectively prevent other pairs from effectively communicating?

The only way that I know of to achieve multicasting (as opposed to broadcasting) on a switch such as this, is via IGMP snooping (PLEASE CORRECT ME IF THIS STATEMENT IS INCORRECT).

IGMP snooping requires a device to act as a multicast router in respect to IGMP. I have added IGMPv2 capabilities to the devices: whichever device on the switch has the lowest MAC address becomes the multicast router.

This system works: devices can join and leave groups as they wish, and the multicast data is correctly directed by the switch. So far so good.

THE PROBLEM:

In IGMP the multicast router is a member of EVERY multicast group, and receives all data sent to any multicast address. Once more than one multicast group is established in this network then the full 1Gbps data streams from multiple devices is sent to the multicast router completely overrunning the link from the switch resulting in huge packet loss. The device acting as multicast router must also perform its regular (non-router) duties.

Is there a way for the multicast router to not be a member of a multicast group, or at least not be sent every packet? I've been told by others that this is not possible.

Is there a different solution to achieving multicasting on this switch?

---

Edit:

It appears the solution is to use a different switch: one with a multicast querier built in. This avoids the problem of there being insufficient bandwidth for a multicast router.

Will a switch with multicast querier suffer from the same problem as the multicast router in the original system? Specifically that all multicast frames (not just the IGMP reports) are sent to the multicast router (in this case the switch querier), and with the high traffic the querier will be swamped.

Answer 1

Quoting 'cpt_fink':

You need something acting as the multicast querier, but not the multicast router. I do not know if this is possible on a TP-Link device. – cpt_fink Feb 18 '15 at 5:19

A workaround is possible: Add whatever cheap network device (cheap router, old network card in linux PC, etc) and send IGMP v2 or v3 queries to switch. Switch will detect that a querier is available, and send all multicast traffic to the cheap device. The eth hw of device will filter and reject the multicasts packets. In my network I captured IGMP v3 queries, and send the packets using tcpdump.

When a IGMP querier is not found, probably the switch broadcasts the multicast packets to all ports. Success Zajo Bajo

Answer 2

Unless you want to configure your switch ports statically, you need a multicast router and this one will always receive the multicast traffic. Theoretically you could use an L3 interface on the switch to act as multicast router, but your switch is L2, so I'm afraid you're out of luck with it.

Finally, please take into account the backplane bandwidth of the switch, and that some switches use the same ASIC for groups of (normally 8) ports, effectively sharing limited bandwidth between them. What I'm saying is that the switch's total bandwidth might be far from 1Gbps x # of ports. So even if you could work around the multicast router issue you might still have another bandwidth problem.