cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1190
Views
0
Helpful
3
Replies

2960 Drops multicast receiver

mc-cdpearce
Level 1
Level 1

A 2960G switch is doing IGMP snooping and is configured as the querier. There is no multicast routing.

Port 1 - Video Set Top Box A

Port 2 - Video Set Top Box B

Port 3 - Multicast Source

Both Set Top Boxes A & B are set to receive the video delivered in the same multicast group.

Every 60 seconds the switch generates an IGMP General Query message which is sent out all the ports in the VLAN.

There is a 10 second timeout in the Query message. Devices that wish to join (or remain joined) to the multicast group have this amount of time to respond with a Join Message directed at the multicast group. Devices deliberately wait a random duration within the timeout time before replying.

For some reason (which I don't understand), if the switch receives a Join request message from a Set Top Box, it forwards that messages out of the port to the other Set Top Box. So, let's say Box A responded with the Join Message first. Box B now sees the Join message and now thinks there is another multicast receiver on its branch of the network, so it suppresses its Join Message to avoid sending an unnecessary message.

If by chance Box A responds first 2 or 3 times in a row, the switch will not have seen a response from port 2 for awhile, so it prunes that port from the multicast.

Eventually, Box B responds first and gets re-joined onto the multicast. It is now Box A that may get pruned if it is consecutively slower.

How do I prevent the switch from replicating the Join message out to the other Set Top Box? I have verified this behavior with Wireshark. But, I believe the Join message is only supposed to be forwarded to a multicast router (if there is one - and there isn't), not to other ports.

The 2960 is running 12.2(58) SE2

Any ideas?

3 Replies 3

smehrnia
Level 7
Level 7

Hi,

Could u post your multicast config?

There is definitely something wrong with ur configuration, because this behaviour (forwarding igmp msg) only happenes

when a switch receives a general query from a router (or a multicast source), then it forwards the query to all ports in the VLAN, not join messages.

Soroush.

Hope it Helps!

Soroush.

I now realize that this is being caused by enabling MVR so that the multicast can be received in other VLANs. I'm going to have to figure out how MVR interacts with IGMP snooping.

Apparently I can have a source of multicast data in the MVR VLAN and have it be received by devices in other VLANs if their interfaces are configured as mvr type receive. I had read that ports in the MVR VLAN configured to be mvr type source could be used to both send and receive multicast data.

However, I think my problem was caused by putting the STBs in the MVR VLAN and hoping they would be able to receive the multicast broadcasts by configuring their ports as mvr type source. It apparently causes the behavior I described.

If I don't configure mvr type, then I don't get any multicast data at all. I guess when a group gets made into a MVR group then it cannot work with regular igmp snooping.

I guess I'm going to have to rethink my VLANs and see if I can put ALL my multicast receivers outside the mvr vlan. But, that will be problematic because I have devices that want to be both a source and receiver. Hmmm.

Review Cisco Networking for a $25 gift card