IGMP Version 1

lagapidis · February 10, 2020, 7:23am

Hello Jiwon

Both real equipment as well as the GNS3 should have the same debug output. When implementing debugging, make sure that you also employ the terminal monitor command in order to tell the device that all debug output should appear on the terminal screen. Also, verify that IGMP is indeed enabled and that you have achieved the necessary connectivity between the hosts and R1 before implementing the commands on the hosts.

Take a look at these and let us know your results!

I hope this has been helpful!

Laz

dakshinaeswar · April 18, 2020, 10:34am

Hi Laz, Can you explain it please ?Please correct me if am wrong. 224.0.0.1 addresses all the host on a network segment. This IP is used by the router to send membership query to all host to ask whoever interested in multicast traffic. And then followed by this you say that 239.1.1.1 multicast IP is the actual IP address that is used to send the multicast traffic to the host participating in the group ? I don’t understand here.
Do you mean 239.1.1.1 is the multicast IP address that host uses when they are sending the membership report ?
Please confirm

lagapidis · April 21, 2020, 6:44am

Hello Dakshinamurthy

Yes, this is correct. All IP hosts on a segment will receive such a message. This multicast address only remains within the segment, and is not routable to any other network segments.

This multicast IP address is the multicast group which the hosts in this lesson want to join. This is seen by the following commands issued on the interface of H1 and H2:

H1(config)#interface GigabitEthernet 0/1
H1(config-if)#ip igmp version 1
H1(config-if)#ip igmp join-group 239.1.1.1

Unlike the 224.0.0.1 address, which is a well known and reserved address, the 239.1.1.1 multicast group address is configurable. This means that some hosts choose to join it, while others may choose not to. It is the destination address used by multicast sources to send their content to. A video server, for example, would use this as the destination address to reach all hosts interested in its multicast stream.

Yes, this address is also used by hosts to send their membership reports. The membership reports actually tell the multicast router that the host sending the report wants to receive multicast traffic destined for this particular multicast IP address.

I hope this has been helpful!

Laz

rspela830 · July 13, 2020, 7:21pm

Rene,

Speaking of enabling multicast routing, in your topology, H1 and H2 are Cisco routers, but in your configuration example, I did not see the command ip multicast-routing on H1/H2. For routers to participate in multicast, do you not have to enable on all routers in global config mode even when they are behaving as hosts??

lagapidis · July 15, 2020, 7:23am

Hello Ralph

As you correctly stated, H1 and H2 are actually routers, but are functioning as hosts. Within the framework of multicast, hosts (even if they are Cisco routers) do not perform multicast routing. So to answer your question, no, multicast routing does not (and actually should not) be enabled on routers that play the role of a host.

Think about it this way. If you have a Windows PC connected to the network, and it wants to participate in a multicast group, it can do so even through it does not have the capability of multicast routing itself. For hosts of any type to participate in multicast, they simply have to support IGMP and the functionality of joining of multicast groups.

I hope this has been helpful!

Laz

rspela830 · July 17, 2020, 5:20pm

Yes…Thank you for the clarification. I’m using multicast more and more these days it seems!!

gowthamraj4 · September 22, 2020, 11:24am

HI ,

expires time is 180 seconds and periodic time is 60 seconds am i right?

lagapidis · September 24, 2020, 6:19am

Hello Gowthamraj

For IGMPv1 the intervals I think you are talking about are:

Query Interval = 60 seconds
Group Membership Interval = 180 seconds

You can see the default values of all IGMP timers on a particular interface using the following command: show ip igmp interface <interface>. Keep in mind that intervals vary from IGMPv1 and IGMPv2.

I hope this has been helpful!

Laz

gowthamraj4 · September 24, 2020, 7:12pm

thank you lagapides

I have 1 more question Lagapides

can you explain the IGMPv1 query packets size in Wireshark they mentioned as 60 bytes.

Ethernet Header 14bytes + IPv4 Header 20 bytes (but they mentioned total length 28 bytes that extra 8 bytes indicating which one ?

total 60 bytes= 14+28=42 bytes what about rest 18 bytes?

Membership Report:
same as Query packet 60 bytes can you explain me.

amar.dulaimi · May 27, 2021, 5:21pm

Hi Lagapides, Rene,

I’m still not sure how this multicast traffic reaches the router since the host destination multicast address is 239.1.1.1 but the router uses 224.0.0.1. How does the router know it has received the multicast traffic from the host since I don’t see 239.1.1.1 configured on the router side. Can you please clarify

Thanks

lagapidis · May 29, 2021, 5:43am

Hello Amar

First of all, multicast traffic does not reach the router. The router is not the destination of multicast traffic. It is the hosts that receive this traffic. The router is configured to send multicast traffic, and when it is sent, it goes to all hosts that have requested it.

When traffic that is destined to 239.1.1.1 is sent from the router, it will go to all hosts that have requested such traffic. If you take a look at the multicast routing table of R1, you will see that group 239.1.1.1 is in the table, and it corresponds with the GigabitEthernet0/1 interface.

Now I believe that your question was, how does the host’s membership query reach the multicast router using a destination address of 224.0.0.1 since this address is nowhere to be seen in the router itself, correct? Well, this is a special reserved multicast IP address called an “all hosts multicast group address”. By default, all multicast hosts on a network segment belong to this group. So even though you can’t see it anywhere, multicast hosts and routers are always a part of this group. So any packet sent with a destination of 224.0.0.1 will reach all multicast-enabled devices, including the router.

I hope this has been helpful!

Laz

castrojuanj · October 14, 2021, 1:43am

Hello Rene, but i’m a little bit confused because in the video you explain and demostrate when there no more hosts listening to a multicast group ip address, the multicast router remove this ip multicast address of the multicast routing table.

lagapidis · October 16, 2021, 6:09am

Hello Juan

IGMP version 1 does not have a message that can explicitly and proactively allow a host to inform a router that it doesn’t want to receive traffic anymore. However, IGMP version 1 does have a timer mechanism that allows a router to determine if there are still interested multicast hosts or not.

As stated in the lesson:

The router will periodically send a membership query to destination 224.0.0.1 (all hosts multicast group address). Hosts that receive this message will respond with a membership report to tell the router that they are still interested in receiving the multicast traffic. When the router receives the membership report, its expiry timer will be refreshed. When no hosts respond, the router knows that nobody is interested anymore in the multicast traffic and it will then remove the entry once the timer exceeds.

So if the timer times out and no host sends any membership reports, then the router knows that no one is interested in the multicast traffic. Only then will it remove the entry from the routing table.

I hope this has been helpful!

Laz

roi9098 · June 16, 2024, 1:25pm

Hi,

in this lesson it was said that the router will forward multicast traffic to the clients until it’s timer expired, and It seems that the timer is per Group address and not per client
so my question is- if there are 2 clients that were in the same multicast group and then one of them stopped being in this group, but the other one continued to be, what happens? the router just continues to transfer multicast queries and information and only the one that left in the group is listening and responding to queries?

also- what is the default value of the Expiration Timer?

lagapidis · June 18, 2024, 7:27am

Hello Roi

Yes that is correct. As long as the router is receiving at least one response to a membership query for a particular multicast group, the router will continue to forward that multicast group.

The default value is typically 260 seconds.

I hope this has been helpful!

Laz

davidilles · September 9, 2024, 8:34am

Hello, everyone.

An excellent explanation, thank you Rene for this lesson. I have two questions:

Does ip multicast-routing need to be issued on the querying router? In my CML lab, it all works just fine, even without this command:

R1(config)# interface G0/0
R1(config-if)# ip pim sparse-mode
R1(config-if)#do show ip igmp int G0/0
*Sep 9 08:29:45.048: %PIM-5-DRCHG: DR change from neighbor 0.0.0.0 to 192.168.1.1 on interface GigabitEthernet0/0/0
GigabitEthernet0/0 is up, line protocol is up
Internet address is 192.168.1.1/24
IGMP is enabled on interface
Current IGMP host version is 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP configured query interval is 60 seconds
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 192.168.1.1 (this system)
IGMP querying router is 192.168.1.1 (this system)
Multicast groups joined by this system (number of users):
224.0.1.40(1)
R1(config-if)#

What exactly is this multicast group here?

obrázok1040×131 4.49 KB

R1 is the multicast querier and its the only router that is party of this group. What does this mean?

That’s all, thank you.
David

lagapidis · September 14, 2024, 5:08am

Hello David

The ip pim sparse-mode command, which you’ve issued under the interface enables multicast routing but only on that specific interface. So, in your lab setup, even without the ip multicast-routing command, that interface is configured to participate in multicast routing. That’s why you’re seeing “Multicast routing is enabled on interface” in your output.

However, because multicast hasn’t been enabled globally, you will get a message stating that “IP Multicast Forwarding is not enabled” when you issue the show ip mroute command. Thus, the router will not route any multicast traffic.

For the purposes of the lab, not issuing the ip multicast-routing command doesn’t make a difference, because IGMP only needs a multicast-enabled interface to function. However, if you add a second router in the multicast topology the further multicast routing throughout that topology will fail.

The multicast group you’re referring to, 224.0.1.40, is a reserved group address for the Cisco’s AutoRP feature. It’s used by routers to announce which router is the RP in a PIM-SM network. In your case, R1 is the only router in this group because it’s the only router that’s announcing itself as the RP.

I hope this has been helpful!

Laz

Ciscobiscuit · November 3, 2024, 6:44pm

Hi, This is just a general question on IGMP. What is the purpose of enabling IGMP under an SVI or other interface ? I have a decent understanding of Multicast but I cannot grasp why or if it matters to have IGMP enabled on an interface such as the interface in the lesson or on an SVI ? For example my understanding is the end devices (windows client) etc. sends an IGMP join message to its last hop router usually gateway. If I am using multicast routing pim will probably be enabled on the interface towards to client be that an SVI or a physical interface and it will send the periodic queries. Same in that if I use a layer 3 svi as a querier for layer 2 multicasting it will also send those queries. I also understand that a querier will “stand down” if it “hears” a pim enabled query on the same broadcast domain and the pim enabled router will take “precedence”. I understand SSM requires IGMPv3 to be enabled etc. and IGMPv3 is backward compatible with igmpv2. But I cannot grasp as to why IGMP needs to be enabled on an interface. I get the reason for IGMP snooping to be enabled. But if the end device sends an ip igmp join message then surely the querier sending a query or pim sending query is all that is required along with igmp snooping enabled ? For example if I had a large stretched vlan lets say vlan 555. And I have 10 switches connected together in vlan 555 and hosts on all 10 switches on vlan 555. Lets say I enabled IGMP snooping on all 10 switches which would be a good idea (I think its enabled by default on ios XE) . Now if I enabled an SVI for vlan 555 on one of the switches as a querier. Everything should work. Or do I also need to enable ip igmp versionx on the SVI of the querier on top of it already being a querier ? and also do I need to enable igmp versionx on the SVI of vlan 555 on each of the 10 switches ? Are query messages not “general” or are there specific queries for each version of IGMP ? (1,2,3) ? I would have assumed I would just enable snooping on each switch (if not already enabled) and configure a querier or pim enabled L3 interface in that specific vlan ? Many thanks, hopefully my questions make some sense.

lagapidis · November 5, 2024, 8:18am

Hello Sean

Enabling IGMP on an interface or SVI is an important step for multicast communication if you want that SVI to function as a querier and/or a multicast router. Here’s why:

When a host wants to receive multicast traffic, it sends an IGMP join message to its local router. The router, in turn, needs to forward this multicast traffic to the host. If IGMP is not enabled on the interface connected to the host, the router won’t understand the IGMP join message and won’t forward the multicast traffic to the host.

In your example, if you have a large stretched VLAN (like VLAN 555) and 10 switches connected together, enabling IGMP snooping on all 10 switches is indeed a good idea. This will ensure that multicast traffic is only forwarded to the switches where there are interested hosts.

Now, when you enable an SVI for VLAN 555 on one of the switches to act as a querier, this switch will start sending IGMP queries to the hosts. The hosts will respond with IGMP reports to let the querier know they are interested in receiving certain multicast traffic. Again, if IGMP is not enabled on the SVI, the querier won’t understand or process the IGMP reports from the hosts.

So, to answer your question, yes, you need to enable IGMP on the SVI of the querier, and also on the SVI of VLAN 555 on each of the 10 switches. This will ensure that the switches understand the IGMP join messages from the hosts and the IGMP reports from the querier.

I hope this has been helpful!

Laz

ekangajoel536 · December 19, 2024, 8:40pm

Hi Rene,

Thanks for your hard work. Please, the topology was not clear. The way you connect devices, H1, and H2, are routers but simulated as hosts. Are they connected to a switch? Please clarify. we need to follow you step by step, when things are not clear we are lost.