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.
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.
Question We run asr9001 with XR 6.1.3, and we have a very long delay to
login w/ SSH 1 or 2 to the device compare to IOS device. After
investigation, the there is 1s delay between the client KEXDH_INIT and
the server (XR) KEXDH_REPLY. After debug ssh serv...
Introduction The purpose of this document is to demonstrate the Open
Shortest Path First (OSPF) behavior when the V-bit (Virtual-link bit) is
present in a non-backbone area. The V-bit is signaled in Type-1 LSA only
if the router is the endpoint of one or ...
Hi, I am seeing quite a few issues with patch install and wanted to
share my experience and workaround to this. Login to admin via CLI, then
access root with the “shell” command Issue “df –h” and you’ll probably
see the following directory full or nearly ...