IGMP Version 3

Hello Heng

Yes you are correct, in order to have H1 participate as an IGMPv3 host, it must have IGMPv3 enabled. This is something you wouldn’t need to do to an endpoint like a PC, so it’s not included here in the lesson as a command. However, it is included in the configuration of the H1 device at the end:
image

Concerning the RP, it is quite an in-depth topic. Take a look at the Multicast lessons on the site starting with the following:


RPs are introduced here and further explained in subsequent multicast routing lessons. Take a look and if you have any specific questions, we’ll be here to respond.

I hope this has been helpful!

Laz

Dear lagapides,rene
Kindly,

  1. i see in ip header of two report message he dest add = multicast address 224.0.0.22 ( all IGMPV3) router, not mulicast group 239.1.1.1 , so only router will recieve this report message, so no report suppression exit ,since if another host exit on same lan segment n , it will not recieve this report need clearification & reset MRT
    2.i see no leave message send from IGMPV3 .only report message with group record type as block old sources
  2. how can change record mode to exclude ?

Hello Saif

The membership report is sent by the host to all IGMPv3 routers, so the destination will be 224.0.0.22. The 239.1.1.1 address is only for multicast traffic sent by the source. The specifying of source addresses does not affect the reports being sent, but it affects only the actual multicast traffic to the group address. The hosts should not receive any membership reports, only the routers should, so this is operating correctly.

IGMPv3 does not use the Leave Group message. It has been replaced with the report message. Report messages indicates that it no longer wants to receive traffic from specific groups using the block old sources record type.

By default, a Cisco router functioning as a host for multicast will function using include mode. From what I could find in the most recent Cisco documentation about IGMPv3, Cisco routers as hosts do not support exclude mode. However, hosts of all kinds participating in multicast using IGMPv3 can use this feature.

I hope this has been helpful!

Laz

Hello,
What’s happened if in my environment I have same IP soruce and same destination address but the port destination is deferent.
Example
10.1.1.1 224.1.2.3 5420
10.1.1.1 224.1.2.3 5320
If my client sent igmp join to 224.1.2.3 10.1.1.1 I will get the to Multicast group.

Hello Itzik

Subscribing to a multicast group and listening on a multicast address and port are two different things. When you subscribe to a multicast group, your host IP address is included in the specific multicast group, say 224.1.2.3. All traffic destined for that IP will reach your host if you are properly configured. This is regardless of port numbers. So to answer your specific question, yes, you will get in the multicast group. This is because port numbers are not taken into account when this occurs.

Now say that two hosts are in the same group, one is listening on port 5420 and the other on 5320. The traffic destined for 224.1.2.3:5420 will reach both hosts because both are members of the group. What happens next depends on which port each host is listening to. If the host is listening on 5420 then it will receive traffic. If it is not, the traffic will be dropped.

I hope this has been helpful!

Laz

Hi all,
in my configuration is a switch with is acting as MC Querier (IGMP snooping enabled too). Attached is a Ethernet recorder, which is by default a passive listener to the network traffic. As we want also the MC traffic to be recorded, we’re able to set up the recorder to send out a free defined message periodically. I build up an IGMPv3 Report Message manually and wireshark recognize it as a valid IGMPv3 Report message.
The questions are:
Do the switch add this “host” to its MC routing table? (because the recorder isn’t responding to quries)
What is the correct Group Record Type for that message? Because compared to IGMPv2 I don’t find that typicall “Join” and “Leave” Types here in v3.

Thanks a lot

Best regards, Florian

Hi Laz ,

when H1 sends the membership report message 1st time to the R1 , the source IP will be 192.168.1.101 & destination will be 239.1.1.1 . I am still confuse why you are using 1.1.1.1 as a source address here ? is it implicitly configure as a random IP & H1 is informing the R1 it should send the multicast message to that particular source 1.1.1.1 which is H1 it self ??

Thanks!

Hello Tanmoy

It is important to note that there is a difference between the source IP address of the actual IPv4 packet found in the IPv4 header which is 192.168.1.101, and the multicast Source Address set to 1.1.1.1.

The first is the IP address of the interface from which the packet is sent. This simply serves the same purpose as the source address for all IPv4 traffic of all types. The source address that is specified in the ip igmp join-group command serves a difference purpose. It is used to enable source specific multicast (SSM), a feature of multicast that will only forward multicast traffic that comes from a pre-specified source. Rene configured it here so that you can see its value included within the IGMP information of the IGMP message.

You can find out more about SSM at the followinglesson:


I hope this has been helpful!

Laz

I’m totally new to multicast, but i can understand all these multicast lessons, and replicated them on eve-ng pro
But i’d like to know how it works in the real world, lets say i run a windows or linux host that want ro receive multicast traffic from a VLC video server… do i have to configure anything on my windows or linux host ? and what about on the VLC server ?

Hello Juan

In the labs concerning multicast, in order to get a host to participate and receive a multicast stream of data, we use the ip igmp join-group command. But when you are using your PC, and you are connecting to a video server, as a user, you don’t actually need to do anything. The whole “joining” mechanism used by multicast is taken care of by the application providing the service. If it is a web application, it is the responsibility of the application to initiate the multicast grouping mechanisms.

Now depending on what application you are using, you may need to enable multicast in the configuration parameters (say in VLC media player?), as well as in the underlying operating system. In most cases, this is already taken care of by the software and OS being used.

From the source point of view, you will have to enable the use of multicast, so that the source will send out the appropriate multicast addresses, and participate successfully in multicast on the network. Some level of configuration is necessary there, but for the most part, it is a high level implementation that has to do with simply checkboxing the appropriate parameters. An example of the required configuration for configuring a Windows Media Server to use multicast can be found here:

I hope this has been helpful…

Laz

1 Like

Hi Rene, i’m a bit confused as to which way the “source” command applies, does it mean only packets coming from a certain source IP address to a host will be accepted? Or does it mean the router will only accept multicast traffic from hosts/routers with a certain source IP address? Because on your SSM lesson it seems to be done one way and then on your IGMP v3 lesson it appears to done another way.

Also, is 232.1.1.1 a routeable multicast address? I know that you mention 224.0.0.0/24 is not and 224.0.1.0/24 are routable, but what about others addresses to?

Thanks

Hello Michael

Applying a source multicast address using IGMPv3 and applying an SSM topology is achieved using the same command:

ip igmp join-group <multicast_group> source <source_address>

The only difference between the two is that the first is simply using PIM sparse mode, while the second is implementing SSM using the ip pim ssm default command. In the case of SSM, there are no shared trees and no RPs. Only SPTs are built toward sources.

In both cases the result is that a host wishing to participate in multicast uses the additional parameter of source of the multicast traffic. So by issuing a command like:

R3(config-if)#ip igmp join-group 232.1.1.1 source 192.168.12.1

…the device is saying that it will join this multicast group but will receive traffic only from the 192.168.12.1 source. This applies only to multicast traffic destined for that specific multicast group.

Out of the full range of IPv4 multicast addresses (224.0.0.0/4), the only range that is not routable is the 224.0.0.0/24 which is reserved for the “local subnet”. All other multicast ranges are routable, including the SSM range of 232.0.0.0/8.

I hope this has been helpful!

Laz

Hello, how can i change the group mode from include to exclude ??

Hello Juan

The group mode is not something that you can change directly, but it is a parameter that is configured internally by IGMPv3 as needed. This is described in detail in the following documentation:

I hope this has been helpful!

Laz

Hi,

Can help to double check this statement “IGMP version 1 and 2 used the 224.0.0.2 (all routers) address” ? is 224.0.0.2 the correct destination for IGMP version 1?

Thank you.

Hello Jisooya

  • IGMPv1 uses a query-response model and sends all queries to 224.0.0.1.
  • IGMPv2 introduces leave group messages. These leave group messages are sent to 224.0.0.2, but queries are still sent to 224.0.0.1.
  • IGMPv3 sends membership reports to 224.0.0.22 but because it is backward compatible with v1 and v2, it also uses the 224.0.0.1 address for queries and the 224.0.0.2 address for leave group messages as needed.

Note that all three of these multicast addresses are well-known addresses. Specifically:

  • 224.0.0.1 is the all hosts multicast group which addresses all hosts on the same network segment
  • 224.0.0.2 is the all routers multicast group which addresses all routers on the same network segment
  • 224.0.0.22 is specifically used for IGMPv3 and addresses all IGMPv3 capable multicast routers.

I hope this has been helpful!

Laz