IGMP support - prevent delivery of multicast streams to ports that haven't requested them

Switches
1

Hi,

Just replaced most of my network’s TP-Link switches with Alta Labs ones. I saw that a firmware upgrade was released some time ago to support IGMP snooping.

However, if I run Wireshark on my PC, I can see that multicast streams are still being delivered to my PC, despite it not requesting them. I would expect the multicast streams to be held within the switch, and only released to the ports once a client on the machine issues an appropriate IGMP message.

Is there some configuration that needs to be carried out to achieve this?

Edit: I’ve just checked, and IGMP Snooping is enabled on VLAN 1 (the only VLAN in the system).

Thanks

Andy

2

Which IGMP group(s) are you seeing? A limited number are flooded to all ports in the source VLAN by design, like all hosts, and we flood mDNS. If you haven’t yet upgraded to switch firmware 2.1g, there were some others like 239.x.x.x which were flooded on earlier firmware which no longer are.

1 Like
3

Switches are all on 2.1g, The multicast group was in the 239.192.x.x range.

In the network are 4 x Alta 8 port switches, and 1 TP-Link 16 port switch.

Andy

4

Thanks, there is a remaining issue with at least some 239 groups. The RTK switch SDK handles 239./8 oddly IMO, differently from others. IGMP is being setup correctly for those groups, which is what testing verified, but I missed that it may still being flooded despite that. Will take a closer look at that soon, but probably next week after the holiday as I have family in from out of town.

1 Like
5

So if I were to use a 238.x.x.x multicast address would you expect it to work?

Edit: I’ve just tried this and am still seeing the multicasts presented to my PC.

Andy

6

Have you had a chance to look at this at all?

Changing the multicast address to 238.x.x.x didn’t seem to make any difference.

Thanks

Andy

7

Any updates on this?

Andy

8

I revisited this and checked out everything again, and am not seeing any circumstance, regardless of group, where things are going out ports other than those which are joined to the group.

Couple things to check.

  1. The IGMP logs on the switch will show joins. If you’re logging to a syslog server, you can check them there (as the switch has limited log history), but otherwise you can SSH into the switch and run:
grep igmp /var/log/messages
  1. You can check what’s actually programmed into the switch chip, for S8 and S16, by running:
diag 'l2-table dump ip-mcast'

The DIP field (destination IP) is the multicast group. The SIP field should be empty (or 0.0.0.0). VID will have the VLAN ID where that IGMP group exists. And Port will show the list of port(s) which have joined that IGMP group. Port uses a 0-based index, so port 1 of the switch is 0 there, port 2 of the switch is 1, etc.

S24 uses different commands which are slightly more convoluted, but if you have one of those I’ll explain that too.

What are you seeing from that?

9 
root@SwitchOffice:~# diag 'l2-table dump ip-mcast'
Index | SIP             | DIP             | VID  | Port
------+-----------------+-----------------+------+----------------------
  732 | 0.0.0.0         | 239.192.251.251 |    1 |                   15
 4572 | 0.0.0.0         | 224.0.1.187     |    1 |                 9,15
 7132 | 0.0.0.0         | 224.0.0.251     |    1 |                 8-15
 7140 | 0.0.0.0         | 224.0.0.252     |    1 |                 9,12
 7148 | 0.0.0.0         | 224.0.0.253     |    1 |                   12
 7180 | 0.0.0.0         | 224.0.0.1       |    1 |                 8-15
 7636 | 0.0.0.0         | 239.255.255.250 |    1 |              9,12,15

The multicast 239.192.251.251 is being released to my PC, which is connected to port 5.

Andy

10

Thanks. I forgot to note, on the S8, the ports aren’t 0-indexed, they’re 8-15. So port 1 is 8 in l2-table, port 2 is 9, etc.

Are you seeing actual multicast streams, or just IGMP messages? The latter is expected for IGMPv2, their reports are destined to the group address, but are flooded to every port that’s a member of that VLAN in lieu of requiring a router port configuration. That’s needed for routed multicast, and in case there’s an IGMP-enabled switch connected to the port. But that only matches on IGMP type, so no actual multicast stream should match.

What’s generating your multicast traffic? Here I have multiple 4K multicast streaming devices from Blustream and AVPro (which each push 400+ Mbps of jumbo frame multicast, so the entire network would be non-functional if multicast was being flooded, as every port would get >1 Gb of multicast), plus mcjoin for use with arbitrary groups and packet sizes. I also know of hotel customers with IPTV, and others with consumer IPTV services, which also work as expected.

If you could capture some of the multicast you’re seeing on that PC to file, that might be telling. I wouldn’t post it publicly in case you also happen to capture something sensitive, but you can DM me a link, or Google Drive share with .

11

The multicast is coming from a software component running on a VM. It is actual multicast traffic, not just iGMP messages. I’ll do a capture now and send it over via DM.

Andy

1 Like
12

Capture sent via DM a few weeks ago, but other than an initial response had no further updates. Any more information on this?

Andy

13

Still not heard anything on this. Has there been any progress @Alta-cmb ?

Andy

14

Out of curiosity, I just ran that command on my S24-POE and got the following result:

~ # diag ‘l2-table dump ip-mcast’
Index | SIP | DIP | VID | Port
------±----------------±----------------±-----±---------------------
Error (0xf00d): Function is not supported by this chip model

15
16

Hi adhawkins. I would love to know the command for the S24-POE please.

17

I don’t know. It was an Alta employee that I was quoting.

Andy