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:
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 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
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.
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.
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.
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.
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 ??
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’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 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?
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 (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.
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:
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?
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.
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?
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.
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.
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.
