11-05-2002 08:09 AM - edited 03-02-2019 02:38 AM
hello,
I am having strange problems with multicast.
I am in a full layer 2 environment:
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 : 224.0.0.15, 228.0.0.8, 239.0.0.15 --> works
225.1.1.15, 228.8.8.8, 239.150.1.2 --> don't work
If there are any issues concerning this
PS: I don't have any router on this VLAN
11-05-2002 08:30 AM
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 239.0.0.15 it will hit the NMP has it ovelaps with 224.0.0.1 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.
Refer to the following as well
11-05-2002 09:06 AM
Thanks ,
Sup 1A for the switches.
I've just tried with 224.1.1.1 and this doesn't work correctly neither
Adding a router is not desired as we need this multicast in a Layer 2 network without being routed to some other places.
I admit that I should use a 224.0.0.x addressing plan for layer 2 only multicast traffic but I'm getting more curious on why it doesn't want to work when I use a 224.1.1.1 addressing plan .
The normal behaviour of such a configuration ( igmp enabled/ IP 224.1.1.1) should to flood multicast traffic to all ports on which igmp received join requests.
What I'm experiencing could be:
1) I don't receive any requests thru the trunk when I use such addressing plan ! Are the requests dropped when entering the trunk ? or what .?
2) Is there any feature (bug?) in the CatOs code that says that if multicast group address isn't 0's in its middle octets , don't consider it ?
11-05-2002 09:11 AM
Take a look at this link, it should help to explain why 224.1.1.1 won't work with igmp enabled: http://www.cisco.com/en/US/tech/tk648/tk363/technologies_tech_note09186a0080094b62.shtml
11-05-2002 09:25 AM
Hi,
the issue discussed in this document concerns cgmp and the flooding of unwanted packets.
My questions concern igmp and the NOT flooding of wanted packets.
I've found something interesting somewhere else concerning the command igmp querrier Vlan X . That's may be a way to workaround the problem I have.
But I'm still wondering why it doesn't work !!!
11-06-2002 12:54 AM
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
11-06-2002 01:41 AM
Hi,
When I take a look at sh cam static, the Mac for 228.0.0.8 ( which is the group I've finally decided to use untill I find the right version ) doesn't appear .
That leads me to say that this type of address is flooded to all ports of the vlan regardless to igmp running or not.
I'm going to sniff on the vlan to see if my assumption is right.
When you say that an igmp packet has to be terminated by a router, isn't igmp snooping on layer2 equipments supposed to to so ( it maintains a table of groups/ports on which to flood packets).
thanks
11-06-2002 01:50 AM
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.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: