when H1 sends the membership report message 1st time to the R1 , the source IP will be 192.168.1.101 & destination will be 126.96.36.199 . I am still confuse why you are using 188.8.131.52 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 184.108.40.206 which is H1 it self ??
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 220.127.116.11.
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’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 ?
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:
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 18.104.22.168 a routeable multicast address? I know that you mention 22.214.171.124/24 is not and 126.96.36.199/24 are routable, but what about others addresses to?
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:
…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 (188.8.131.52/4), the only range that is not routable is the 184.108.40.206/24 which is reserved for the “local subnet”. All other multicast ranges are routable, including the SSM range of 220.127.116.11/8.
IGMPv1 uses a query-response model and sends all queries to 18.104.22.168.
IGMPv2 introduces leave group messages. These leave group messages are sent to 22.214.171.124, but queries are still sent to 126.96.36.199.
IGMPv3 sends membership reports to 188.8.131.52 but because it is backward compatible with v1 and v2, it also uses the 184.108.40.206 address for queries and the 220.127.116.11 address for leave group messages as needed.
Note that all three of these multicast addresses are well-known addresses. Specifically:
18.104.22.168 is the all hosts multicast group which addresses all hosts on the same network segment
22.214.171.124 is the all routers multicast group which addresses all routers on the same network segment
126.96.36.199 is specifically used for IGMPv3 and addresses all IGMPv3 capable multicast routers.
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 188.8.131.52 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.
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., 184.108.40.206). However, in IGMPv3, Membership Reports are sent to the all-routers group at address 220.127.116.11.
Is that correct that we have an exception for IGMPv2? General membership queries are sent to 18.104.22.168 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
General membership queries are sent to the all-hosts multicast address 22.214.171.124. 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 126.96.36.199. 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.
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 188.8.131.52 source 192.168.1.1
In this situation, the router is acting as a multicast host that is requesting to join the 184.108.40.206 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 am testing IGMPv3 in my lab and have noticed something that I think needs to be corrected in the lesson.
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 220.127.116.11
*Aug 25 06:50:13.400: IGMP(0): Received Group record for group 18.104.22.168, mode 2 from 192.168.1.101 for 0 sources
*Aug 25 06:50:13.401: IGMP(0): Setting v2 old host timer for 22.214.171.124 on GigabitEthernet0/0
*Aug 25 06:50:13.401: IGMP(0): Updating EXCLUDE group timer for 126.96.36.199
*Aug 25 06:50:13.402: IGMP(0): MRT Add/Update GigabitEthernet0/0 for (*,188.8.131.52) 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 184.108.40.206, mode 5 from 192.168.1.101 for 1 sources
*Aug 25 06:50:39.057: IGMP(0): Create source 220.127.116.11
*Aug 25 06:50:39.057: IGMP(0): Updating expiration time on (18.104.22.168,22.214.171.124) to 180 secs
*Aug 25 06:50:39.058: IGMP(0): Setting source flags 4 on (126.96.36.199,188.8.131.52)
*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 184.108.40.206, mode 5 from 192.168.1.101 for 1 sources
*Aug 25 06:50:40.090: IGMP(0): Updating expiration time on (220.127.116.11,18.104.22.168) to 180 secs
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 22.214.171.124 source 126.96.36.199
ip igmp join-group source 188.8.131.52 184.108.40.206
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.