2 Catalysts 6509 connected through a trunk (dot1q). On both catalysts I have stations with a multicast application .All stations are in the same VLAN and they see each other correctly.
Both switches have igmp enabled in their conf.
When I configure the application to use an multicast IP address such A.0.0.x where A is (224-239) everything works fine.
Stations on both switches send and receive correctly multicast data.
If I do the same tests but using an address such A.B.C.x where (B, C != 0) , it stops working . Only stations connected to the same switch see multicast traffic ( traffic stops being flooded thru the trunk).
The only way to make it work using such an address is disabling igmp on both switches ( means that traffic is flooded thru all ports of the VLAN : not desired).
65xx are running CatOs 6.3.x ( several versions tested with same results)
IP groups used : 220.127.116.11, 18.104.22.168, 22.214.171.124 --> works
Not sure what SUP you are running but the PFC2 handles snooping slightly differently.
Firstly remember there is a 32:1 overlap when mapping IP class D to MAC layer, this due to more IP bit and less MAC..:)) (Was a money thing years ago)
You will notice that if you do a sh cam system you will see 00.5e.xx.xx.xxx and you will find those get sent to the switch NMP hence when you send to 126.96.36.199 it will hit the NMP has it ovelaps with 188.8.131.52 which is registered to PIM.
There are ways around this and this is either get a MSFC (Expensive) or if you have 7.1 you can use the igmp querier command, however i have not lab'd this at all.
The cleanest and neatest adn easiest to manage and control is having a router even if it is external, and then config the switch to with set multicast router mod/port command.
With regards to my previous posting, i mentioned the querier command which kinda makes the switch a proxy IGMP Querier/Reporter.
If you can post a sh multicast group, sh cam static (Believe it or not M/cast entries are placed in here) and a sh cam system.. The pure fact that the NMP has no M/cast router to fwd these packets to seems to be proving a problem, also look at the IGMP statistics .
I know there are some issues with M/cast and 6.3(x) which was a result of programming the LTL incorrectly..
You must bear in mind that an IGMP packet has to be terminated by a router interface.
I am not sure if you can do a bug search, if not contact me off line via mail as posting that info here is not desirable
Well if its not in the CAM then it will most definately be flooded... as for IGMP snooping it does not terminate an IGMP report at all, it will only LISTEN and it also suppresses some reports to the multicast router port, so kinda leaks IGMP through but definately does not terminate an IGMP packet.
Another way around this is to place a static entry into the cam
set cam static 01-00-5E-00-00-08
This will instruct the switch and hence should stop the flooding.
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...