IGMP Understanding

[Jeff Harned]

Hello All,

I have questions on understanding using IGMP.

I have conversion units that are capabale of being configured with two ip multicast addresses.  Therefore they can receive two separte multicast data streams simultaneously from two separte units. 

If my understanding is correct about IGMP, it is these receivers (hosts) that would have to have the IGMP feature built in to operate and

not just a switch itself?

As far as I know these conversion units do not use IGMP, so this feature with a switch would not function?   

Thanks.

Regards,

Jeff

[Jan Hrnko · Accepted solution]

Hi Jeff,

you are right. Hosts must have IGMP implemented. They must send the IGMP join message for subscription to a specific multicast stream.

Keep in mind that cisco switches have igmp snooping enabled by default. I think, that that's what you are asking. This feature dynamically decides to which ports should a multicast be sent and to which not. Your scenario will not function with igmp snooping enabled. That is because the switch is examining, if some hosts from its ports want to recieve multicast. If they don't(can't) send IGMP join messages, they won't get the multicast.

So in your case, I advise you to turn igmp snooping off.

Switch(config)#no igmp snooping

However, if you want to restrict flooding of multicast to only some ports, consider configuring it statically:

http://www.cisco.com/en/US/docs/switches/lan/catalyst2960/software/release/15.0_2_se/configuration/guide/swigmp.html#wp1020159

Best regards,

Jan

[Jeff Harned]

Hi Jan,

Thanks, this is good info.  Now this leads me to my next question since I can not use IGMP.

Switch info:

C3560x-24

SW Version: 15.0(2)SE4
SW Image C3560E-UNIVERSALK9-M
License level: ipbase

I am now looking at using the mac addresses of the units in attempt to pass one or both data steams to the receiving units. I am attempting to add to the mac address table statically.  However, I cannot use the CLEAR command to clear the table of the dynamic addresses assigned to the ports?

I used the procedure according to the instructions for the 3560 but it will not work.  I have not been able to find why the

clear command will not work?

Any help for this?

Thanks,

Regards,

Jeff

[Jan Hrnko]

Hi Jeff,

I've been thinking about it lately but I am not sure what exactly do you want to achieve.

Why do you want to clear the mac address table in the first place? Please, enlighten me a little bit.

Have you tried to configure (restrict) the flooding manually, like in the document provided in my previous post?

Please, let me know.

Best regards,

Jan

[james.doukas]

You can statically assign a port in a vlan to a multicast group as the link shows. If you're source is on a different subnet, then you have to do multicast routing. You could statically assign the group under the interface but would still need to configure PIM, etc..

Not sure about the clearing mac part. The multicast mac can reside on the port for the multicast traffic and the devices regular mac stays there for regular IP traffic.

*For the switch*

ip igmp snooping vlan static interfaces .

*For the router under the interface*

ip igmp static-group

[Jeff Harned]

Hi Jan & James,

Let me back up and start again.

First, I do not have much experience with networking but I want to learn!!  I have had excellent results using MVR which

I have gain some knowledge.

What I am trying to achieve is working with regular VLANs and IP Multicast Routing with a L3 switch, the latest

being the 3560x.   Unfortuately working with another Member I found out the switch does not have the IPservices that I

need to do it.  Not wanting to give up I am trying to explore if there is another way to achieve the following goals and hope

that I can get this switch updated and get another switch with this licesnse.

The goals:

I have several serial to IP Multicast conversion units.  These units are configured to receive two multicast data streams.  Two of these units receive serial data each one outputing a single multicast data stream into the switch.  There are two host units that are configured to be able to receive both data streams.  I want at the end to write a script program where I can select which single multicast data would be passed from a switch port to any one of the host units I select.

As mentioned earlier I was able to do this using MVR with the 2950 (L2) switch with excellent results!  Now that I have a L3 switch to work with I want to get away from MVR and use standard VLANs with IP Multicast Routing but I do not have this

capability at this time.  The conversion units to the best of my knowledge do not have IGMP so this is not an option

as Jan has acknowledged.

So, since these conversion units have MAC addresses I am trying to explore if I can set up switch ports to receive

multicast data using VLANS.  So far it is not going well at all.  I must have a misunderstanding on how a static assigned

mac address to a port/host works.  When I removed the unit from a configured static assigned port with another unit, which

of course has another mac address the multicast data was still passed to it.  I expeceted this unit not to receive anything since the port was statically assigned only to the first conversion unit.

I hope this makes sense!

Thanks for any help and explanations!!

Regards,

Jeff

[Peter Paluch]

Hello Jeff,

I am at a loss in understanding why you want to modify the MAC address table manually.

Multicasting on Ethernet layer is done by addressing the Ethernet frames to an artificial multicast destination MAC address. This MAC address is distinct and different from any MAC address used by real network cards. Becase a multicast MAC address is never used as a source, a switch can never learn it in the way it learns about unicast MAC addresses. Therefore, if a switch receives a multicast-addressed frame, it floods it automatically simply because it does not know the destination. This is the same behavior you would see with unknown unicast or broadcast destination.

So in other words - on a simple, unmanaged switch, you don't need to do anything, and the multicast will just work.

More sophisticated switches like Catalysts actually try to limit the multicast flooding only to ports where the subscribers are connected. They do this by eavesdropping on IGMP traffic and learning which station on which port subscribes to which multicast group. These switches then dynamically modify their MAC address tables to make sure the multicast traffic is switched out only those ports that have corresponding subscribers connected.

This IGMP Snooping, as Jan has correctly called the feature, is on by default, and if your devices use IGMP then again, you don't need to move a finger, and the multicast should just work.

You have indicated that your serial-to-multicast converters do not use IGMP. Are you sure about that? You said you have used MVR before and you were satisfied with it - but MVR also depends on IGMP. So is it really certain your converters do not support IGMP?

Even if they don't, you can always deactivate the IGMP Snooping on your switch, allowing the multicast to be flooded everywhere, or define static IGMP Snooping entries for those ports and groups that have no IGMP-capable subscribers.

This is why both Jan and me are confused about your efforts to manually modify the MAC address table as doing this has no meaning in the context of multicast stream delivery. Please note once again that the destination MAC address of multicast frames is a fictious group MAC address and none of the subscribers actually adopts that address - it only listens on it, in addition to its own MAC address.

I guess this is the set of questions you should try to answer:

1. What kind of multicast is being used? Do the converters use IPv4 multicast, or do they communicate directly over Ethernet without using IP, utilizing Layer2 multicasting only?
2. Are the senders and receivers of the multicast in the same VLAN, or are they located in multiple VLANs?
3. Is it absolutely certain the converters do not support IGMP? Please note that even if they don't, you are not supposed to modify the MAC address table in any way.

Looking forward to your answers.

Best regards,

Peter

[Jeff Harned]

Hi Peter,

Wow!! What a way to be learning!!

You helped me before with the same switch.  You are talking about things that I have to look at closer.

There is much to understand in what you are talking about.

As with your questions I will have to speak to another person about the conversion units but I was under

the impression that they do not use IGMP, maybe I am wrong!! 

Thanks again!

Regards,

Jeff

[Jeff Harned]

Hi Peter, Jan and James,

I have met with a gentlemen who knows about these conversion units and he has showed and explained to me using Wireshark.  I have a better understanding on the process after the seriial data is converted.

Peter to answer yor questions:

1) You are right these units do use IGMP!  These units use IPv4 multicasting. There are two source units with each data port assigned an IP address and each a single IP Multicast address.  The reciever data ports are also assigned each with an IP address but configured each with two IP Multicast addresses to "request" the multicast data from both source units.

2) As I mentioned before to you I have a 3560 switch.  I have it configured with one source and reciever units in a VLAN with the other source and reciever units in another. I want to be able to IP Multicast route between the VLANs but as you found out I do not have the proper license to do this.  There is a process in place to rectify this issue!!

While I am waiting I will have to concentrate on learning IGMP now that I know these unit uses it!  As far as the MAC addresses, I am way off base and will stay away from this at least for now.

As I learn, any comments or suggestions are always welcomed!!

Thanks.

Regards,

Jeff

[Peter Paluch]

Hi Jeff,

I just wanted to ask if there is anyting new in this matter, and perhaps if we can assist you getting further. Thanks!

Best regards,

Peter

[Jeff Harned]

Hi Peter,

Well, I am glad you asked!.  While I am waiting for the switch to get ordered and the license upgrade I went ahead

and took a look at IGMP.  The units use IGMPv2.  How do I know because I used Wireshark to look at a receiver port

and it indicated membership reports for the correct two multicast addresses.

I am going to have to go back and see if I can do something with this protocol. I made a mistake and thought the receiver units used version 3 and by what I have read there are limitations on what you can do with it at least in my case.  Maybe with version two I can do some testing.

I was able however to accomplished one good thing using an example that you provided using ip igmp snooping querier.

I was able to set all source and receiver units under one VLAN and now all the receiving units receive both

multicast data streams!  What I have to undestand is why you also included an ip address associated with the vlan:

interface vlan 20
ip address xxx

exit

If you remeber my goal is to use IP Routing between VLANs but as you found out we do not have the IPservices license to do this.  So I have to wait.  I have ordered and received a couple of books one being on just TCP/IP that hopefully will

aid in my undestanding on how ip and multicasting addressing work.

Any comments or suggestions are always welcomed!!

Thanks for your help.

Regards,

Jeff

[Peter Paluch]

Hi Jeff,

It's good to know things are working

What I have to undestand is why you also included an ip address associated with the vlan:

The reason is that the IGMP Querier needs to send, obviously, IGMP Membership Query packets. These are IP packets carrying IGMP messages. As an IP packet, it has to have a source IP address filled in, and ideally, the source IP shall be filled in using the querier's own IP address in the subnet where the querier is running. Hence my recommendation to create a SVI for VLAN20 and assign it an IP address - to make sure that the querier running in VLAN 20 has an IP address to use as the source address for IGMP messages.

Best regards,

Peter

[Jeff Harned]

Hi Peter,

Yes some progress!!

I have been taking another look at IGMP now that I know that the receiver units use v2.  I have to say that things are not working well at all with it. I obviously do not understand how this function works.  This is what I am trying to do:

We know that the receiver units puts out a igmp request since they are now receiving both multicast data. What I have been trying to do is see if I can block out a receiver unit from receiving any multicast data or one selected one. I have made an attempt to use the immediate-leave function on one receiver but that did not work.  Reading further it is now my underdstanding that the receiver unit itself has to request leaving and that I just can not disable the port?  Though I have administrative rights to these receivers there in no function that I know of where I can do this.

I took a look at using IGMP Filtering with using just one receiver and that also did not work.  I have attached a sample of the configuration that I am using for just one switch.  Two notes on this.  I went ahead and configured the LAN back using MVR and this works. Intergrating IGMP filtering into this however, did not produce the desired result.

According to the Cisco configuration guide it says "IGMP filtering is applicable only to the dynamic learning of IP multicast group addresses, not static configuration".  I had manually configured all these conversion units way back with multicast addresses of  239.1.1.3 and  239.1.1.4.  I am not clear on this statement and how it applies to my situation.

Again, thanks for any help!

Regards,

Jeff