cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
436
Views
0
Helpful
7
Replies

Multicast issues ?

dmc.net
Level 1
Level 1

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

7 Replies 7

DALE FRANCIS
Level 3
Level 3

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

http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a008007ec30.html#xtocid0

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 ?

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

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 !!!

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

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

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.

Getting Started

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:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco