IGMP Version 3

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

2 Likes

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

1 Like

So far, I haven’t seen how the server multicast is streamed from is configured. Will I see in the coming lessons?

Server > R1 > Host

What configuration do we apply to the server, what information does the server require to forward traffic to the destination multicast group and the router?

Many thanks.

Hello NetworkGuy

Actually, the server itself needs no special configuration to operate as a multicast server. It simply sends traffic to the appropriate multicast group IP destination, such as 239.1.1.1 and the network takes care of the rest.

Indeed you can send a ping from your PC to that destination and that would be a multicast transmission just like any other. No specialized configuration.

I hope this has been helpful!

Laz

1 Like

Hi,

I think there’s a typo:

ip igmp join-group source 239.1.1.1 1.1.1.1

should be:

ip igmp join-group 239.1.1.1 source 1.1.1.1

Also, I just want to clarify something with regard to the difference between IGMPv2 and IGMPv3.

For IGMPv2, Membership Reports are sent to the multicast address of the group you want to join (e.g. 239.1.1.1) whilst for IGMPv3 they are sent to the all-routers group 224.0.0.22.

Is that correct?

Thanks.

Sam

Hello Samir

Yes you are correct, I will let Rene know to make the change.

Yes, you are correct. In IGMPv2, Membership Reports are sent to the multicast address of the group you want to join (e.g., 239.1.1.1). However, in IGMPv3, Membership Reports are sent to the all-routers group at address 224.0.0.22.

I hope this has been helpful!

Laz

2 Likes

Hi Laz,

Is that correct that we have an exception for IGMPv2? General membership queries are sent to 224.0.0.1 but Membership queries following a leave are sent to the Multicast Group address?
That’s what we see in the previous lesson in the wireshark screenshot

Thanks,

Hello David

Thanks for pointing this out. Let me clarify.

General membership queries are sent to the all-hosts multicast address 224.0.0.1. These queries are sent by the multicast router to periodically check if there are still members in a multicast group.

Group-specific membership queries are sent to the multicast group address in response to a Leave Group message. When a host wants to leave a multicast group, it sends a Leave Group message to the all-routers multicast address 224.0.0.2. The router then sends a group-specific membership query to the multicast group address to check if there are any remaining members in that group. If no other hosts respond, the router stops forwarding packets for that multicast group.

I hope this has been helpful!

Laz

1 Like

Hi,

Great content. It would be even better if it explains EXCLUDE and other IGMPv3 group modes as well

Hello Ram

IGMPv3 uses two filter modes that provide a lot more flexibility and granularity in managing multicast traffic compared to previous versions. These modes are INCLUDE and EXCLUDE. These are not explicitly configured on a Cisco device but are part of the operation of the IGMPv3 protocol itself. They are used to determine how a host receiver wants to receive multicast traffic from various sources.

According to RFC 3376, the filter mode is further described as follows:

"filter-mode" may be either INCLUDE or EXCLUDE.  In INCLUDE mode,
 reception of packets sent to the specified multicast address is
 requested *only* from those IP source addresses listed in the
 source-list parameter.  In EXCLUDE mode, reception of packets sent
 to the given multicast address is requested from all IP source
 addresses *except* those listed in the source-list parameter.

In the lesson, you see an example of how the INCLUDE mode is used. Again, it’s not explicitly configured, however, it is inferred by the IGMP protocol based on the configuration. Under what circumstances would we see an EXCLUDE mode? Here is an example:

Router(config)# interface gigabitethernet0/0
Router(config-if)# ip igmp join-group 239.1.1.1 source 192.168.1.1

In this situation, the router is acting as a multicast host that is requesting to join the 239.1.1.1 multicast group. By configuring the source of the multicast traffic, it is essentially excluding the addresses stated in the source list. In the above case, that is the 192.168.1.1 address. Based on the above description from the RFC, this should give us an EXCLUDE mode in the IGMPv3 message.

I hope this has been helpful!

Laz

Hi Team,

I am testing IGMPv3 in my lab and have noticed something that I think needs to be corrected in the lesson.

  1. Enable IGMPv3 also on Host H1 which is not done otherwise it will send IGMPv2 report by default. Below debug on R1 you will see it received IGMPv2 query from H1 until I changed the version on H1 to v3.
*Aug 25 06:50:13.400: IGMP(0): Received v2 Report on GigabitEthernet0/0 from 192.168.1.101 for 239.1.1.1
*Aug 25 06:50:13.400: IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 192.168.1.101 for 0 sources
*Aug 25 06:50:13.401: IGMP(0): Setting v2 old host timer for 239.1.1.1 on GigabitEthernet0/0
*Aug 25 06:50:13.401: IGMP(0): Updating EXCLUDE group timer for 239.1.1.1
*Aug 25 06:50:13.402: IGMP(0): MRT Add/Update GigabitEthernet0/0 for (*,239.1.1.1) by 0
*Aug 25 06:50:39.056: IGMP(0): Received v3 Report for 1 group on GigabitEthernet0/0 from 192.168.1.101
*Aug 25 06:50:39.056: IGMP(0): Received Group record for group 239.1.1.1, mode 5 from 192.168.1.101 for 1 sources
*Aug 25 06:50:39.057: IGMP(0): Create source 1.1.1.1
*Aug 25 06:50:39.057: IGMP(0): Updating expiration time on (1.1.1.1,239.1.1.1) to 180 secs
*Aug 25 06:50:39.058: IGMP(0): Setting source flags 4 on (1.1.1.1,239.1.1.1)
*Aug 25 06:50:40.089: IGMP(0): Received v3 Report for 1 group on GigabitEthernet0/0 from 192.168.1.101
*Aug 25 06:50:40.089: IGMP(0): Received Group record for group 239.1.1.1, mode 5 from 192.168.1.101 for 1 sources
*Aug 25 06:50:40.090: IGMP(0): Updating expiration time on (1.1.1.1,239.1.1.1) to 180 secs

  1. Below command syntax seems to incorrect:

It should be as shown below:

ip igmp join-group 239.1.1.1 source 1.1.1.1

Hello Rahul

Indeed you are correct on both counts. IGMPv3 should be activated on the host in order for the lab to behave as described in the lesson. Also, the syntax of the command is

ip igmp join-group 239.1.1.1 source 1.1.1.1

and not

ip igmp join-group source 239.1.1.1 1.1.1.1

as shown in this CIsco command reference:

Although for the latter I tried to discover if this syntax belongs to an older version of IOS, but I was unable to find such an indication. In any case, thanks for pointing this out, I will let Rene know to make the appropriate changes.

Laz

1 Like