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
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.
*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
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
Hello Rene & Laz,
I believe there is an extra ‘source’ keyword in the H1 config below:
Thank you.
Hello Zhassulan
You’re absolutely right. I’ll let Rene know to make the fix. Thanks for pointing that out!
Laz
Thank you @jasulan87 . I just fixed this.
Rene
Hello Team,
I labbed and found something that one host chose the group mode as EXCLUDE and another host chose the group mode as INCLUDE. Is there any way to manually choose the mode ?
Hello Sathish
IGMPv3 allows hosts to send membership reports that INCLUDE or EXCLUDE specific multicast group addresses, as explained in the lesson. However, what is actually used cannot be directly configured on the host itself. This is usually the responsibility of the network application running on the host that is leveraging multicast. If you want to change the mode, you would need to configure the network application accordingly.
Now you mention that you found hosts using either one of INCLUDE and EXCLUDE. Were those Cisco devices or some other hosts? In any case, you can find out more about these modes at this related NetworkLessons note.
I hope this has been helpful!
Laz
Hello, everyone.
Above, you can see that H1 wants to receive traffic from 239.1.1.1 from source 1.1.1.1. The destination for these membership reports is 224.0.0.22, the IGMP version 3 “all routers” group address. IGMP versions 1 and 2 used the 224.0.0.2 (all routers) address.
v1 and v2 only used the 224.0.0.2 address when sending an IGMP leave, or not? Technically, the destination IP for the reports in v1/v2 was the multicast group that the host joined, right?
Thank you.
David
Hello David
Membership reports in IGMPv1 and v2 are sent to the specific multicast group in question, and not to the 224.0.0.2 all routers address. Multicast routers join the 224.0.0.2 group by default, which is used by various protocols, including PIM, but not for IGMP membership reports.
I will let Rene know to make the clarification in the lesson.
I hope this has been helpful!
Laz
That’s correct about v1 and v2. You can see it in these capture files too:
I’m not sure what I was thinking when I wrote that but I just fixed it 
Rene
A post was merged into an existing topic: IGMP Snooping
Hello,
Great lesson. But I have a doubt:
I have the following topology:
So the goal here is that KG-LAT1 is listening for 239.10.20.10 but only for KG2 stream (sourced from 10.116.201.2). Multicast traffic destined to 239.10.20.10 from KG1 should not be accepted by KG-LAT1.
So I put this configs on KG-LAT1:
So far so good. I configured PIM SM and BSR and N-TGX200 learn the RP address dynamically over tunnel 110. The tunnel is PIM SM enabled so multicast traffic flows through it. Now, here comes the doubt:
When I configured KG-LAT1, I run the following command on N-IR01:
and as expected, I got such output. However, note that this router is also the RP. I was expecting that the RP will see that no clients are interested in (10.116.200.2,239.10.20.10) and therefore, on the OIL of (10.116.200.2,239.10.20.10) in the MRT I will not see G2 listed. I was expecting to only see G2 on the OIL of (10.116.201.2,239.10.20.10) But I see the following:
So does this mean that the RP is not source-specific aware by default,even with IGMPv3 enabled on interfaces of the router that acts as the RP ? Is PIM Accept-Register the mechanism to achieve what I want?
I am confused on the fact that N-IR01 seems to be capable of determining what multicast streams to forward based on the source without PIM SSM or any other features by seeing the output of sho ip igmp groups 239.10.20.10 detail but at the same time the MRT is telling me the opposite thing!!
Thanks,
Jose
Hello Jose
Wow, this is really getting into the nitty-gritty, and I like it! 
Thanks for the detailed network topology and outputs of those commands, it’s really helpful.
What you are seeing is expected when you’re using any source multicast (ASM). IGMPv3 source filtering is a last-hop function and the RP does not automatically honor per-receiver source filters. IGMPv3 source filtering has only a local scope of influence.
The RP will still forward any (S,G) down the shared tree to all downstream interfaces that have (*,G) state until it is explicitly pruned for that source by the downstream router. If you want to make the RP also honor the source policy, you can use PIM accept-register as a valid method, but it’s independent of IGMPv3.
So why do your outputs look the way they do? Well, the show ip igmp groups detail command reflects what the last-hop router (your RP is also the LHR for interface G2) knows about receivers: “include 10.116.201.2 only.” However, the show ip mroute shows the actual PIM/forwarding state. In ASM, the RP forwards down the shared tree to every interface with (*,G) state regardless of source until that interface sends a per-source prune. So you can still see G2 in the OIL for (10.116.200.2, 239.10.20.10) on the RP even though the IGMP database says “only source 10.116.201.2 is wanted.” These are different control-plane functionalities.
So the RP is not “source-specific aware” just because IGMPv3 is enabled. IGMPv3 source filters live on the LHR, and the RP still forwards until it sees a prune for each unwanted (S,G). What you saw in the MRIB/MFIB is normal until the per-source prune is received and processed.
I hope this has been helpful!
Laz
Thanks Laz!
