IGMP Version 1

IGMP (Internet Group Management Protocol) version 1 is the first version that hosts can use to announce to a router that they want to receive multicast traffic from a specific group. It’s a simple protocol that uses only two messages:

  • Membership report
  • Membership query

When a host wants to join a multicast group, it will send a membership report to the group address that it wants to receive. When the multicast-enabled router receives this message, it will start forwarding the requested multicast traffic on the interface where it received the IGMP membership report on.

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, it’s 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.

In this lesson, we’ll take a closer look at these two messages and I will show you how to configure IGMP version 1. Here’s the topology we will use:

multicast igmp topology router two hosts

Above we have one router and two hosts. On the router we will enable multicast routing and IGMP on its Gigabit 0/1 interface.

All modern operating systems support IGMP, you can use Windows, Linux or MacOS. You can also use Cisco routers as host devices which is what I will do in this example.

IGMP (Internet Group Management Protocol) version 1 is the first version that hosts can use to announce to a router that they want to receive multicast traffic from a specific group. It's a simple protocol that uses only two messages: Membership report Membership query When a host wants to join a mu



Let’s configure R1 first:

R1(config)#ip multicast-routing
R1(config)#interface GigabitEthernet 0/1
R1(config-if)#ip igmp version 1
R1(config-if)#ip pim sparse-mode 

We configured three commands on the router:

  • First we enabled multicast routing globally, this is required for the router to process IGMP traffic.
  • We enabled PIM on the interface. PIM is used for multicast routing between routers and is also required for the router to process IGMP traffic.
  • We changed IGMP to version 1, the default on Cisco IOS routers is version 2.

Let’s verify if IGMP is enabled on our router:

R1#show ip igmp interface GigabitEthernet 0/1
GigabitEthernet0/1 is up, line protocol is up
  Internet address is 192.168.1.1/24
  IGMP is enabled on interface
  Current IGMP host version is 1
  Current IGMP router version is 1
  IGMP query interval is 60 seconds
  IGMP configured query interval is 60 seconds
  Inbound IGMP access group is not set
  IGMP activity: 1 joins, 0 leaves
  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)

Above we can see that IGMP is enabled on the interface. Each 60 seconds it will send a membership query on this interface. Here’s what that looks like in wireshark:

Wireshark Capture Multicast IGMP Version 1 Membership Query

Above you can see the membership query packet that our router sends to 224.0.0.1. There’s not much in the packet but when the hosts receive this, they will act upon it. Let’s configure one of our hosts so that it joins a multicast group:

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

Above we configured our host to join multicast group 239.1.1.1.1. It will now send a membership report:

Multicast IGMP Version 1 membership report

Above you can see that host 1 sends a membership report with destination 239.1.1.1.1. When our router receives this, it will forward traffic with destination 239.1.1.1 on its interface where it received this membership report.

We can also see these packets with a debug. Let’s enable IGMP debugging on our router and two hosts:

R1, H1 & H2
#debug ip igmp 
IGMP debugging is on

Now I will configure our second host to join the same multicast group address:

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

Here’s what you will see on the router:

R1#
IGMP(0): Send v1 general Query on GigabitEthernet0/1
IGMP(0): Set report delay time to 0.7 seconds for 224.0.1.40 on GigabitEthernet0/1
IGMP(0): Received v1 Report on GigabitEthernet0/1 from 192.168.1.102 for 239.1.1.1
IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 192.168.1.102 for 0 sources
IGMP(0): Updating EXCLUDE group timer for 239.1.1.1
IGMP(0): MRT Add/Update GigabitEthernet0/1 for (*,239.1.1.1) by 0
IGMP(0): Received v1 Report on GigabitEthernet0/1 from 192.168.1.101 for 239.1.1.1
IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 192.168.1.101 for 0 sources
IGMP(0): Updating EXCLUDE group timer for 239.1.1.1

Above you can see that the router sends a membership query and that it receives two membership reports, one from each host. Here’s what the debug on the hosts looks like:

H1#
IGMP(0): Received v1 Query on GigabitEthernet0/1 from 192.168.1.1
IGMP(0): Starting v1 router present timer on GigabitEthernet0/1
IGMP(0): Set report delay time to 0.8 seconds for 239.1.1.1 on GigabitEthernet0/1
IGMP(0): Received v1 Report on GigabitEthernet0/1 from 192.168.1.102 for 239.1.1.1
IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 192.168.1.102 for 0 sources
IGMP(0): Send v1 Report for 239.1.1.1 on GigabitEthernet0/1
H2#
IGMP(0): Received v1 Query on GigabitEthernet0/1 from 192.168.1.1
IGMP(0): Starting v1 router present timer on GigabitEthernet0/1
IGMP(0): Set report delay time to 0.6 seconds for 239.1.1.1 on GigabitEthernet0/1
IGMP(0): Send v1 Report for 239.1.1.1 on GigabitEthernet0/1
IGMP(0): Received v1 Report on GigabitEthernet0/1 from 192.168.1.101 for 239.1.1.1
IGMP(0): Received Group record for group 239.1.1.1, mode 2 from 192.168.1.101 for 0 sources

The hosts received the membership query and send membership reports in return. This will happen over and over again, you can see it in the following packet capture:

wireshark capture multicast igmp membership query report

Above you can see that each 60 seconds the router sends a membership query. I’m showing only one of the hosts which responds with a membership report.

Let’s see what happens when our hosts don’t want to receive multicast traffic anymore:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You've Ever Spent on Your Cisco Career!
  • Full Access to our 657 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

524 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Rene,

    Great lesson, however I have a question about for the host don’t we need ip pim sparse-mode? I can see on the router we have ip pim sparse-mode.

    Please clarify.

    Hamood

     

     

  2. great post.

    with respect to below 2 statements: what is the diff between multicast-routing and PIM command ? both seems to be doing same thing - process the IGMP traffic.

    1.First we enabled multicast routing globally, this is required for the router to process IGMP traffic.
    2.We enabled PIM on the interface. PIM is used for multicast routing between routers and is also required for the router to process IGMP traffic.

    Also
    a. from where .40 address came ? does router generates it randomly ?
    b. group address 239.1.1.1 who decides and gives this IP in real time environment ?

  3. Hi,

    R1#show ip igmp groups 239.1.1.1
    IGMP Connected Group Membership
    Group Address    Interface                Uptime    Expires   Last Reporter   Group Accounted
    239.1.1.1        GigabitEthernet0/1       19:22:56  00:01:07  192.168.1.101
    

    Can you explain
    Why the host cannot see 192.168.1.102 cant see here
    Thanks

  4. There are two options that come to mind:

    R1#show ip multicast                   
            Multicast Routing: enabled
            Multicast Multipath: disabled
            Multicast Route limit: No limit
            Multicast Triggered RPF check: enabled
            Multicast Fallback group mode: Sparse
            Multicast DVMRP Interoperability: disabled
    

    Or just check the running config:

    R1#show run | include multicast-routing
    ip multicast-routing

  5. Hello Recto

    The 239.0.0.0 to 239.255.255.255 range of multicast IP addresses known as “Administratively scoped” addresses. These are defined by RFC 2365 and are reserved for private use within an organization. So to answer your question, yes, when configuring multicast groups it is best practice to use these addresses.

    Having said that, as you probably know, there are various special-use multicast addresses that have various purposes as defined by the IANA and by various RFCs. Although I don’t like linking to Wikipedia, I find that their summary of the IPv4

    ... Continue reading in our forum

13 more replies! Ask a question or join the discussion by visiting our Community Forum