IGMP Version 2

Hello Hild

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?

I hope this has been helpful!

Laz

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?

Hello NetworkGuy

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 hope this has been helpful!

Laz

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:

  1. I have already tried closing out the lab, logging out of EVE-ng and deleted and re-applied the config with no change.
  2. I am using EVE on my VMware WS installed on my laptop.

Hello Rahul

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…

I hope this has been helpful!

Laz

Hi Laz,

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! :smiley: I wanted to understand the IGMP behavior which I have so I think its fine.

Thanks for your help as always!
Regards,
Rahul

Hi Rahul

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? :crazy_face:

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 hope this has been helpful!

Laz

1 Like