If two hosts randomly choose the same time, then both responses will be sent. But that’s OK, because the router will receive both and process them normally. This means that the multiple responses will only take place at that moment. Future random times are chosen by hosts each time they are to respond to a query from the router.
Keep in mind that this is a very rare occurrence. Not only because it is unlikely for two hosts to choose the same random timer, but also because the same random timers must also be the shortest timers, compared to all of the multicast receivers.
For example, if you have 50 multicast receivers, and a query is sent from the router, all 50 hosts will set random timers to respond. Only if the two shortest timers are the same will there be two responses sent out. If two hosts choose the same timer duration, but they’re not the shortest, they will receive a response from another host and will cancel sending out their responses. Does that make sense?
In the initial setup, when R1 sends general membership query there’s only one host connected - H1.
So H1 sends/replies with a report type message; however it doesn’t set the report delay time (MRT) but does so later when another host (H2) joins the multicast - is this observation correct?
Keep in mind that the value found within the MRT field is only meaningful within a general membership query, and it refers to the maximum response time that the router allows the hosts to set their random response timers to.
Notice that in the router advertisement, the value is 10 seconds, which is the default. However, in all membership reports sent by hosts, the MRT is set to 0. This is because this field is ignored completely in such messages.
According to RFC 2236 which describes the Max Response Time field, it states:
The Max Response Time field is meaningful only in Membership Query messages, and specifies the maximum allowed time before sending a responding report in units of 1/10 second. In all other messages, it is set to zero by the sender and ignored by receivers.
The random time chosen by each host is actually maintained internally and is not shared in any messages, so you will never see the value chosen by any particular host in any field of an IGMP message.
I am trying to test IGMPv2 and have made an exact replica of the lab taught in the lesson. I am using EVE-ng with vIOS L3 images. I don’t think I am doing anything wrong but when I remove the hosts 1 and 2 from the multicast group for some strange reason the router R1 still shows the entry for 239.1.1.1 and expires only after the timer expires!
Once the timer expires for 239.1.1.1 I see the delete showing in the debug for R1’s console.
So as per the lesson, it means that R1 will forward traffic for H1 and H2 until the timer expires which is futile and not expected in IGMP v2.
R1#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.1 GigabitEthernet0/0 00:01:43 00:02:49 192.168.1.102
224.0.1.40 GigabitEthernet0/0 00:04:10 00:02:51 192.168.1.1
R1#
R1#
R1#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.1 GigabitEthernet0/0 00:01:53 00:02:39 192.168.1.102
224.0.1.40 GigabitEthernet0/0 00:04:21 00:02:41 192.168.1.1
R1#
R1#
R1#
R1#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.1 GigabitEthernet0/0 00:01:57 00:02:35 192.168.1.102
224.0.1.40 GigabitEthernet0/0 00:04:25 00:02:37 192.168.1.1
R1#
R1#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.1 GigabitEthernet0/0 00:02:20 00:02:12 192.168.1.102
224.0.1.40 GigabitEthernet0/0 00:04:48 00:02:14 192.168.1.1
R1#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
239.1.1.1 GigabitEthernet0/0 00:03:45 00:00:46 192.168.1.102
224.0.1.40 GigabitEthernet0/0 00:06:13 00:02:47 192.168.1.1
R1#sho ip igmp groups
IGMP Connected Group Membership
Group Address Interface Uptime Expires Last Reporter Group Accounted
224.0.1.40 GigabitEthernet0/0 00:08:21 00:02:40 192.168.1.1
R1#
In the debug below you will see that R1 has received Leave from H1 (192.168.1.101) and H2(192.168.1.102)
R1#
*Aug 20 13:58:25.632: IGMP(0): Received Leave from 192.168.1.101 (GigabitEthernet0/0) for 239.1.1.1
*Aug 20 13:58:25.632: IGMP(0): Received Group record for group 239.1.1.1, mode 3 from 192.168.1.101 for 0 sources
*Aug 20 13:58:25.633: IGMP(0): Lower expiration timer to 2000 msec for 239.1.1.1 on GigabitEthernet0/0
*Aug 20 13:58:25.633: IGMP(0): Send v2 Query on GigabitEthernet0/0 for group 239.1.1.1
*Aug 20 13:58:25.654: IGMP(0): Received v2 Report on GigabitEthernet0/0 from 192.168.1.101 for 239.1.1.1
*Aug 20 13:58:25.654: IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 192.168.1.101 for 0 sources
*Aug 20 13:58:25.654: IGMP(0): Updating EXCLUDE group timer for 239.1.1.1
*Aug 20 13:58:25.655: IGMP(0): MRT Add/Update GigabitEthernet0/0 for (*,239.1.1.1) by 0
*Aug 20 13:58:26.331: IGMP(0): Received v2 Report on GigabitEthernet0/0 from 192.168.1.102 for 239.1.1.1
*Aug 20 13:58:26.331: IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 192.168.1.102 for 0 sources
*Aug 20 13:58:26.332: IGMP(0): Updating EXCLUDE group timer for 239.1.1.1
*Aug 20 13:58:26.332: IGMP(0): MRT Add/Update GigabitEthernet0/0 for (*,239.1.1.1) by 0
*Aug 20 13:58:29.468: IGMP(0): Send v2 general Query on GigabitEthernet0/0
*Aug 20 13:58:29.468: IGMP(0): Set report delay time to 2.5 seconds for 224.0.1.40 on GigabitEthernet0/0
*Aug 20 13:58:30.051: IGMP(0): Received Leave from 192.168.1.102 (GigabitEthernet0/0) for 239.1.1.1
*Aug 20 13:58:30.051: IGMP(0): Received Group record for group 239.1.1.1, mode 3 from 192.168.1.102 for 0 sources
*Aug 20 13:58:30.052: IGMP(0): Lower expiration timer to 2000 msec for 239.1.1.1 on GigabitEthernet0/0
*Aug 20 13:58:30.053: IGMP(0): Send v2 Query on GigabitEthernet0/0 for group 239.1.1.1
*Aug 20 13:58:30.067: IGMP(0): Received v2 Report on GigabitEthernet0/0 from 192.168.1.102 for 239.1.1.1
*Aug 20 13:58:30.067: IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 192.168.1.102 for 0 sources
*Aug 20 13:58:30.068: IGMP(0): Updating EXCLUDE group timer for 239.1.1.1
*Aug 20 13:58:30.068: IGMP(0): MRT Add/Update GigabitEthernet0/0 for (*,239.1.1.1) by 0
*Aug 20 13:58:31.999: IGMP(0): Send v2 Report for 224.0.1.40 on GigabitEthernet0/0
*Aug 20 13:58:32.000: IGMP(0): Received v2 Report on GigabitEthernet0/0 from 192.168.1.1 for 224.0.1.40
*Aug 20 13:58:32.000: IGMP(0): Received Group record for group 224.0.1.40, mode 2 from 192.168.1.1 for 0 sources
*Aug 20 13:58:32.001: IGMP(0): Updating EXCLUDE group timer for 224.0.1.40
*Aug 20 13:58:32.001: IGMP(0): MRT Add/Update GigabitEthernet0/0 for (*,224.0.1.40) by 0
After taking another look at the debug, I see that just after R1 receives Leave from H1 and R1 also receives a report from H1! This also happens in case of H2. Why would there be a Report seen for the hosts that have already sent a Leave message to the Router?! Makes no sense to me.
Could you please shed some light on why this might be happening.
Note:
I have already tried closing out the lab, logging out of EVE-ng and deleted and re-applied the config with no change.
I am using EVE on my VMware WS installed on my laptop.
Hmm, it seems that as soon as the 192.168.1.101 host sends its leave group message, we see that the router lowers the expiration timer and sends out a v2 query for the group. However, it seems that the same host sends out a v2 report back to the router, thus canceling the lowered expiration timer. It looks like the host wants to keep receiving multicast traffic.
Indeed you are right, it makes no sense. This is strange behavior. I suggest you do a debug on the host as well to see why it’s sending out that additional report and let us know. Hopefully we’ll be able to resolve the issue…
Thanks for your response.
I did take a debug on hosts as well and on both of them I saw they sent Leave message to the Router which is also seen on the router however, there I did not see any further logs on the console of both hosts so as per them they are no longer interested in receiving multicast traffic.
I am not sure why is it like this. I guess it is ok to leave it at this as the issue maybe due to the vIOS quirk! I wanted to understand the IGMP behavior which I have so I think its fine.
Thanks for verifying that. That’s very strange. When the router receives the leave message, it lowers the expiration timer, and then sends out a v2 query. From the point of view of the router, it looks like the host is responding to that query with a report telling the router it still wants to receive traffic. If the host didn’t actually send that report, where did it come from?
In any case, you’re right its probably not worth troubleshooting any longer, since it’s not a production network and this is not an issue that is troubling your users. It is likely some sort of bug. In any case, since your understanding of the process is clear, you’re all good to go.
It’s always enlightening to review such situations, cause it keeps us on our toes and helps us to further understand these processes, so thanks for sharing…
i have a small query, regarding report suppression.
How one host send other hosts membership report so report suppression can be achive?
is it on any multicast group? or its a unicast communication?
also if there is 1000 host in a network subscribing any multicast group, in that case host with lowest holddown timer will send membership report to all the 999 host in the network?
Also what will happen if by any changes 2 or more then 2 host took same hold down timmer?
Membership reports are sent to the multicast group from which a particular host is interested in receiving traffic. So if a host sends a membership report to 239.1.1.1, that report will be received by all hosts that are members. That means that if another host is ready to send a report because its timer is about to expire, and it “hears” the membership report of another host, it will not send its membership report, but will reset its timer, thus suppressing the sending of its report.
Yes that is correct, because the membership reports are sent to the group address. That saves a lot of network bandwidth and host processing since membership reports from 999 other hosts don’t have to be sent.
If it happens that two hosts get the same hold-down timer, and the timer expires at exactly the same time, then both hosts will send a membership report. But that’s OK because the multicast network is designed to handle such situations anyway. This is a rare occurrence and one that has a negligible effect on efficiency.
I wanted to understand the IGMP behavior which I have so I think its fine.