IGMP Version 2

thank you lagapides.

i will check RFC

1 Like

Hi Rene,

Might be worth linking the IGMPv1 lesson to ENCOR as IGMPv1 is referenced a few times. PLus that one also mentions the different messages.

1 Like

Hi Rene/Laz,
This was a great lesson. I was labbing the same topology and noticed that the router received a group membership report following the leave group message. For example in your output, when Host2 send the leave group, R1 sent a group specific query and then Host1 replied with a membership report.

I got the same in mine, however I also got a group membership report from Host2. Additionally I didn’t see any sending of membership report on Host2 following the leave group message being sent. Was wondering what the purpose of this is. Is it some kind of acknowledgment?

Thanks

H2#
*May  8 13:52:38.899: IGMP(0): IGMP delete group 239.1.1.1 on Ethernet0/0
*May  8 13:52:38.899: IGMP(0): Send Leave for 239.1.1.1 on Ethernet0/0
R1#
*May  8 13:52:38.900: IGMP(0): Received Leave from 192.168.1.102 (Ethernet0/0) for 239.1.1.1
*May  8 13:52:38.900: IGMP(0): Received Group record for group 239.1.1.1, mode 3 from 192.168.1.102 for 0 sources
*May  8 13:52:38.900: IGMP(0): Lower expiration timer to 2000 msec for 239.1.1.1 on Ethernet0/0
*May  8 13:52:38.900: IGMP(0): Send v2 Query on Ethernet0/0 for group 239.1.1.1
*May  8 13:52:38.901: IGMP(0): Received v2 Report on Ethernet0/0 from 192.168.1.102 for 239.1.1.1
*May  8 13:52:38.901: IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 192.168.1.102 for 0 sources
*May  8 13:52:38.901: IGMP(0): Updating EXCLUDE group timer for 239.1.1.1
*May  8 13:52:38.901: IGMP(0): MRT Add/Update Ethernet0/0 for (*,239.1.1.1) by 0
*May  8 13:52:39.936: IGMP(0): Received v2 Report on Ethernet0/0 from 192.168.1.101 for 239.1.1.1

Hello Bhawandeep

Thanks for the suggestion. I’ll let @ReneMolenaar to consider clarifying the content in this way…

Laz

Hello @bthethy ,

Could it be a coincidence that H2 sent a membership report just before it left? When I debug this, I only get this on R1:

*May 12 08:54:56.468: IGMP(0): Received Leave from 192.168.1.102 (GigabitEthernet0/1) for 239.1.1.1
*May 12 08:54:56.468: IGMP(0): Received Group record for group 239.1.1.1, mode 3 from 192.168.1.102 for 0 sources
*May 12 08:54:56.468: IGMP(0): Lower expiration timer to 2000 msec for 239.1.1.1 on GigabitEthernet0/1
*May 12 08:54:56.469: IGMP(0): Send v2 Query on GigabitEthernet0/1 for group 239.1.1.1
*May 12 08:54:57.489: IGMP(0): Send v2 Query on GigabitEthernet0/1 for group 239.1.1.1
*May 12 08:54:58.489: IGMP(0): Switching to INCLUDE mode for 239.1.1.1 on GigabitEthernet0/1
*May 12 08:54:58.489: IGMP(0): MRT delete GigabitEthernet0/1 for (*,239.1.1.1) by 0

Could you try a ip igmp join-group 239.1.1.1 and no ip igmp join-group 239.1.1.1 a couple of times on H2 to see if it’s consistent?

A membership report is a very simple message:

https://www.cloudshark.org/captures/909766aa3ea6

It doesn’t have anything except the multicast address that the host is interested in. There are no flags or anything to use it for anything else.

Rene

Hey Rene

Thanks for the lesson, in the video you did not see the leave message because of report suppression, only the last host to send a membership report will send a leave message, other hosts will leave silently without sending a leave.

i think the above is something that you need to add for the lesson to avoid confusion

Hi @abedkhater8 ,

On a switch with IGMP snooping enabled, hosts never see each other IGMP membership reports because the switch intercepts these. This prevents hosts from using the report suppression mechanism and it means that each host will send a membership report.

Rene

Hello Abdallah

Thanks for pointing this out. I will let Rene know to consider making a clarification.

Laz

First of all thank you for all the great lessons. I am getting addicted to your lessons.

Now a membership Query :smiley:
IGMP membership group specific query message from the router right after receiving leave msg from H2 seems to have different values for Max Resp Time from other query msgs.
Other Query Msgs:
Max Resp Time: 10,0
Group specific Query right after receiving the leave msg from H2:
Max Resp Time: 1,0

Is there any significance of this change?

Guess:
Because router quickly wants to decide whether to remove this group entry or not.
Please confirm.

“above we see the leave group membership that H2 sends to destination 224.0.0.2 (all routers multicast group address)”

Why we can’t see the group 224.0.0.2 in the mroute table ? Does it means what multicast groups 224.0.0.0 – 224.0.0.255 are enabled by default (under router interfaces) but it is not visible ?..

Hello Artūras

The address range of 224.0.0.0/24 is known as the local subnetwork address range of the multicast IPv4 address space. These IP addresses are not routable. That means that they, by definition, must remain within the network segment within which they originate. This is why they don’t appear in the multicast routing table.

For additional information, take a look at the NetworkLessons note on the Multicast local subnetwork address range.

I hope this has been helpful!

Laz

Hello Muhammad

This is expected behavior. This has to do with a variable in IGMP called the Last Member Query Interval, which has a default value of 1 second. You will see from RFC3326 that:

The Last Member Query Interval is the Max Response Time inserted into
Group-Specific Queries sent in response to Leave Group messages, and
is also the amount of time between Group-Specific Query messages.

And it is described in further detail in this section with the following explanation:

When a Querier receives a Leave Group message for a group that has
group members on the reception interface, it sends [Last Member Query
Count] Group-Specific Queries every [Last Member Query Interval] to
the group being left. These Group-Specific Queries have their Max
Response time set to [Last Member Query Interval]. If no Reports are
received after the response time of the last query expires, the
routers assume that the group has no local members, as above. Any
Querier to non-Querier transition is ignored during this time; the
same router keeps sending the Group-Specific Queries.

I hope this has been helpful!

Laz

Think I’m getting the hang of this now (thanks!) but I still have one unanswered question - as the hosts are choosing their reply-time at random within the MRT-period, what happens when two hosts randomly choses the same time? Does it just mean that there will be multiple responses in that circumstance? And do they choose a new time for every query, or will the multiple responses keep happening whilst those hosts continue being members of this group?

1 Like

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