Switch VLAN Multicast Operation

[doug.c.gruver]

I am a switch user and by no means an expert. I have a small test network consisting of a unit under test sourcing 2 different multicast data addresses, 1 @ 16Mbps and the other @ 5.4Mbps to a Cisco 2960-S switch with a small 4 port VLAN. The ports of the VLAN go to two ports in a test computer which are the sinks for the two multicast addresses while the other port goes to a NTP server sending out time messages every 16secs.  After many hours of operation we got a drop out on one of the multicast receive ports. We observe this by using Wireshark in promiscuous mode. The multicast data has 3 fragments due to its size of around 3.8K. The middle packet is dropped while the first and last packet are not but are correct for offset and fragment flags along with content/CRC. What I've noticed is when this failure occurs the switch is not copying one of the multicast packets to all the ports but the other multicast address is being copied to all the ports. My understanding is that all multicast traffic should be copied to all ports just from observation on the other two test systems and the assurance from our configuration management  the switches are all configured the same. After looking at the Wireshark data on this switch over time this switch is always behaving this way so it looks like a configuration issue. All my other test sets Cisco switches duplicate all the multicast packets. Is there a command to alter this behavior or is my switch just broken?  In the past we've been able to exonerate our unit under test by using this copied data to prove it sent it and the switch dropped it. I want to keep this behavior for this reason but want to understand if this could be the reason the switch drops packets in the first place since it's copying all the data to all the ports and could be overtaxing the switch processor.

[paul driver]

Hello

Does the M/C need to be routed, Its not clear if it does or not?

If not, Have you tried enabling igmp snooping to negate such flooding? - if it is routed what pim mode are you using?

res
Paul

[doug.c.gruver]

Hi Paul,

Thanks for responding. The M/C destination is the test PCs mentioned and they're on the output of the switch so no further routing is required. I was under the impression that the igmp snooping was on by default but I need to check. 

I take it the pim mode is not applicable due to no further routing required? 

Any thoughts on the igmp non snooping mode (if that's what's wrong) possibly being the cause of the dropped packets? I have other identical test sets with the same switch config that show data very late >60usec on the required destination of the m/c packet while the copied packet is arriving sooner on the non needed port! These have been obvious switch problems and they occur also at a very low rate and can be explained. However the dropped middle packet fragment has proved more vexing since I don't have a copy of the missing data.

Thanks for your time.

Doug