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.
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.
We are pleased to announce availability of Beta software for 16.6.3.
16.6.3 will be the second rebuild on the 16.6 release train targeted
towards Catalyst 9500/9400/9300/3850/3650 switching platforms. We are
looking for early feedback from customers befor...
Introduction Featured Speakers Luis Espejel is the Telecommunications
Manager of IENova, an Oil & Gas company. Currently he works with Cisco
IOS® and Cisco IOS XE platforms, and NX to some extent. He has also
worked as a Senior Engineer with the Routing P...
In this session you can learn more about Layer 3 multicast and the best
practices to identify possible threats and take security measures. It
provides an overview of basic multicast, the best security practices for
use of this technology, and recommendati...