IGMP Version 1

Lessons Discussion
42

Hello Joel,

I usually use routers as hosts unless I need something that a router can’t do, such as iPerf.

When you add no ip routing on a router, you disable routing and it will need a static route or default gateway when you want to reach destinations outside of its own subnet. I like to use routers as hosts because it’s simple and they are easy to add to a topology. No need to understand Windows or Linux.

Also, when you see a simple line that connects those devices, it’s a L2 segment. In reality it’s a switch but it doesn’t require any configuration. Even in an emulator, it could be an unmanaged switch. I usually do this not to clutter the topology.

Rene

to

43

Silly question guys.
How a PC, Macbook Pro or any other mobile device join to multicast group?

44

Hello Daniel

That’s not a silly question! It will help you and others to understand the way multicast works.

Now, multicast is a service typically initiated and managed by device applications. For example, if you have a multicast service on your enterprise network, say streaming video or audio music being shared among multiple devices, your PC, for example, will connect to the server using unicast communication. During that communication, the application on the PC will negotiate with the application on the server, using whatever software mechanisms have been programmed into them, to allow the PC to join the required multicast groups. The server will inform the PC about the multicast groups it needs to join, and it, in turn, will send out the IGMP join messages needed. Now, details of how this works depend highly on the server and client applications running on the PC and the server.

So, multicast in a production environment is primarily a mechanism initiated and managed by the applications themselves. They just require that the underlying network infrastructure is able to support the multicast operation using PIM, IGMP, and the related protocols and network features. Does that make sense?

I hope this has been helpful!

Laz

45

My question is related to IGMPv1.

When hosts send a membership join to the group address, that triggers the router to start a timer. When the timer counts down to zero, it then sends the membership query to inquire whether there is any host still interested in receiving multicast traffic from the group. Is this a good understanding of the process of the workflow. If so, how long does timer run for? Is the length of this timer standard/fixed or varies?

46

Hello aayouba379

Great question! Your mental model is close, but there’s an important clarification needed, and this actually touches on two distinct timers that are easy to confuse in IGMPv1.

You’re right that joining triggers a timer, but the cause-and-effect flow isn’t quite as you’ve described. The router’s periodic queries and the group’s expiration timer are actually two independent mechanisms and not a simple sequence. Let me describe how it works.

Router queries run on their own schedule. The router sends General Membership Queries to 224.0.0.1 periodically, every 60 seconds by default on Cisco IOS, regardless of whether any host has joined a group. This isn’t triggered by a host’s join, it just runs continuously.

Hosts join with unsolicited reports. When a host wants to join a group, it doesn’t wait for a query. Instead, it immediately sends an unsolicited Membership Report. This is what triggers the router to start forwarding traffic and to create a per-group expiration timer.

Reports refresh the group timer. When the router’s periodic query arrives, hosts that are still members respond with a fresh Report. Each Report resets the per-group expiration timer (shown as “Expires” in show ip igmp groups).

There are two key timers in the process, and this is where the confusion typically comes in.

  1. Query Interval: This is how often the router sends Host Membership Queries. The default is 60 seconds but is configurable via ip igmp query-interval. This runs continuously and independently.
  2. Group Membership Interval, which is the expiry timer. This defines how long the router keeps the group active and forwards traffic if it receives no fresh reports. The default is 180 seconds (3 minutes) and is derived from 3 times the Query Interval on Cisco platforms.

The 180-second value is not mandated by any standard. RFC 1112 (the IGMPv1 spec) doesn’t define a specific group-membership timeout. It only says routers assume a group has “no local members” after “some number of Queries” go unanswered. Cisco’s approach is a sensible 3× multiplier of the query interval, which gives the router three chances to hear from at least one interested host before cleaning up.

The timeout does vary in practice: if you change the query interval to 30 seconds, the group-membership timeout scales proportionally to 90 seconds. Different vendors may also implement a different multiplier.

If the router stops receiving any Reports for a group (because hosts have left), that per-group timer counts down and eventually expires, ανδ the group is then removed. This is significant because IGMPv1 has no explicit Leave message. Timeout is the only way the router learns that membership has ended, which is one reason IGMPv2 was introduced with an explicit Leave Group message.

For Cisco IOS, remember that 60 seconds is the query interval, and 180 seconds the group expiry, which maintains a consistent 3:1 ratio. You can verify this with show ip igmp interface and show ip igmp groups (shows the countdown “Expires” timer, typically around 180 s after a fresh join).

I hope this has been helpful!

Laz

47

Thank you for your compendious answer. It’s absolutely clear now.
Another question that’s eluding me is as follows:

One advantage IGMPv2 and v3 have is the leave message feature. When a host leaves a group it sends a general report to 224.0.0.2(All routers). This report is then followed by an immediate query by the querier to that group (group-specific query) to inquire about the group’s membership state. Good!
Now what happens when no host leaves. Is the “Group-Specific query feature” still in play? or does the querier carries on with the general query to 224.0.0.1? Which in my estimation makes more sense.

  1. In IGMPv2 the querier is the router with the lowest IP. Is it the same for IGMPv3 or does it use a different mechanism to select the querier?
    Thank you!
48

Hello Aayouba379

I’m glad the previous explanation was clear. Let me address both of your new questions in order.

First, concerning the querying behavior when no host leaves. You’re on the right track in your reasoning. The querier continues to send periodic General Queries to 224.0.0.1 regardless of whether any Leave messages occur. Group-Specific Queries are not the default. In IGMPv2, they’re event-triggered only by a Leave message.

So General Queries still take place in IGMPv2 and can be considered the “heartbeat” that keeps all group memberships alive. The Group-Specific Queries are a “double-check” that occurs only after someone leaves. In a steady state (no leaves), the querier simply repeats this general query cycle continuously. On Cisco IOS, for example, this defaults to every 60 seconds. Hosts respond to these general queries, and the router’s multicast routing table is kept current based on those responses and any unsolicited reports.

Concerning the querier selection in IGMPv3, the answer is straightforward. IGMPv3 uses the exact same querier election mechanism as IGMPv2. The router with the lowest IP address on the subnet is elected as the querier. RFC 3376 explicitly reuses the v2 querier election process.

I hope this has been helpful!

Laz