Published: 2021-12-19
Without any management protocol multicast will be forwarded exactly like broadcast. Any switch receiving a multicast frame will flood it on all other ports while a router will ignore them.
Using IGMP, a multicast receiver will send out reports announcing what multicast group(s) it wants to join. This allows the router and switches in the network to learn which interfaces they should be forwarding multicast traffic out on. These reports can be sent immediately when the receiver joins the group, but are also periodically sent in reply to general queries generated by the local multicast router.
The router may receive multicast flows from other subnets, so IGMP is useful in helping the router decide which multicast traffic should enter the local subnet and which traffic should be dropped to save network resources. In more advanced terms, an IGMP membership report is usually translated into a PIM Join message on the router that is sent upstream into the network, but PIM is out of scope for this post.
Generally, IGMP is enabled on the network router and multicast receivers. IGMP Snooping is enabled on network switches, allowing them to intercept and process the IGMP messages sent by the router and multicast receivers.
The first version of IGMP, a simple soft-state protocol with two messages, both explained below.
The General Query is sent out by the router every 60 seconds, asking locally connected multicast receivers to send a Membership Report of every (*,G) multicast flow they wish to receive. If no response is received, no multicast traffic will be forwarded by the router into the subnet. This query is sent to multicast link-local address 224.0.0.1.
This report is generated by the multicast receiver, each report containing a single multicast group. So if PC5 is a member of 239.1.1.1 and 239.4.4.4, it will create two reports, one for each group. The report is sent to the corresponding multicast address, so the report for joining the (*, 239.1.1.1) group is sent to multicast address 239.1.1.1; the report for group (*, 239.4.4.4) is sent to address 239.4.4.4.
When a Membership Report is received from a receiver, the router creates a multicast routing entry for the (*,G) group and adds the receiving interface to the list of outgoing interfaces. This multicast entry has a 180 second expiry timer. Every time a report for that flow is received (every 60 seconds), the expiry timer is reset. If the multicast entry timer expires, the multicast routing entry is removed and the router will not forward that multicast flow out on that interface.
In this example I have three Cisco IOS devices. R1 is acting as the multicast router. PC4 and PC5 act as receivers on the same subnet. In this example, both PC4 and PC5 are members of the (*, 239.1.1.1) multicast group but PC5 is also a member of the (*, 239.5.5.5) group.
Let's look at the config and IGMP debug output:
R1#show running-config
ip multicast-routing
no ip pim autorp
!
interface Ethernet0/1
ip address 10.0.0.1 255.255.255.0
ip pim sparse-mode # Enables IGMP on the interface
ip igmp version 1
---
R1#debug ip igmp
IGMP(0): Send v1 general Query on Ethernet0/1
IGMP(0): Received v1 Report on Ethernet0/1 from 10.0.0.4 for 239.1.1.1
IGMP(0): Received v1 Report on Ethernet0/1 from 10.0.0.5 for 239.1.1.1
IGMP(0): Received v1 Report on Ethernet0/1 from 10.0.0.5 for 239.5.5.5
---
R1#show ip mroute
IP Multicast Routing Table
(*, 239.1.1.1), 00:00:19/00:02:40, RP 0.0.0.0, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse, 00:10:19/00:02:40
(*, 239.5.5.5), 00:10:06/00:02:48, RP 0.0.0.0, flags: SJC
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse, 00:10:06/00:02:48
PC4#show running-config
interface Ethernet0/0
ip address 10.0.0.4 255.255.255.0
ip igmp join-group 239.1.1.1
---
PC4#debug ip igmp
IGMP(0): Received v1 Query on Ethernet0/0 from 10.0.0.1
IGMP(0): Set report delay time to 0.8 seconds for 239.1.1.1 on Ethernet0/0
IGMP(0): Received v1 Report on Ethernet0/0 from 10.0.0.5 for 239.1.1.1
IGMP(0): Send v1 Report for 239.1.1.1 on Ethernet0/0
PC5#show running-config
interface Ethernet0/0
ip address 10.0.0.5 255.255.255.0
ip igmp join-group 239.1.1.1
ip igmp join-group 239.5.5.5
---
PC5# debug ip igmp
IGMP(0): Received v1 Query on Ethernet0/0 from 10.0.0.1
IGMP(0): Set report delay time to 0.6 seconds for 239.1.1.1 on Ethernet0/0
IGMP(0): Send v1 Report for 239.1.1.1 on Ethernet0/0
IGMP(0): Send v1 Report for 239.5.5.5 on Ethernet0/0
IGMP(0): Received v1 Report on Ethernet0/0 from 10.0.0.4 for 239.1.1.1
Looking at the debug output, we can see that R1 sends out a general Query and receives a response from both PC4 and PC5. PC4 also sees the report from PC5 before it sent its own report out, but it sends the report anyway. Going back to R1, we see the output of the "show ip mroute" which is the multicast routing table, and that both multicast group entries have been added.
Summarizing IGMPv1, its main problem is that it is quite slow. The general queries are sent out every 60 seconds and each entry times out after 180 seconds, so the router may continue forwarding multicast traffic for a group up to three minutes after all receviers have left. Joining a group is not as slow, thanks to receivers sending out a membership report immediately when joining a multicast group, they don't have to wait for a query from the router.
IGMP version 2 is an an improved version that adds the following functionality:
This is a new field in the general Query message, specifying how long the receivers can wait before responding to this query. Each host generates a random wait-time value between 0 and MRT, adding a few seconds of delay before responding to the query. This reduces response flooding as a receiver with a shorter delay will send its report before the timer on other devices have ended. Any device that receives a report will not sends its own report.
This message is sent by a receiver when it wants to leave a multicast group. This allows it to leave much faster than when using IGMPv1.
This is a query sent out by the router for a specific (*, G) multicast group, triggered by a Leave Group message. This is sent out by the router immediately after receiving a leave group message to check if any other host are interested in receiving this traffic. If no response is returned before the MRT expires, the router will stop forwarding that multicast traffic.
This allows two multicast routers to elect a querier to send out the query messages because there is no point in both sending the messages. The lowest IP-address wins. This is useful in LAN environments where two routers are connected for redundancy as it avoids packet duplication.
So there are two big improvements in IGMPv2. One is reduced report flooding thanks to the new MRT functionality. As we will see in the debug output below, receivers will cancel their reports if another receiver got to send theirs first. This is a big reduction in IGMP messages, especially in large subnets where you may have hundreds of receivers that would otherwise send out their reports at the same time.
The other improvements is the addition of the Group Leave message, allowing a receiver to announce that it is leaving a multicast group, lowering the leave-time from hundreds of seconds to less than ten seconds.
R1#debug ip igmp
IGMP(0): Send v2 general Query on Ethernet0/1
IGMP(0): Received v2 Report on Ethernet0/1 from 10.0.0.5 for 239.5.5.5
IGMP(0): Received v2 Report on Ethernet0/1 from 10.0.0.4 for 239.1.1.1
PC4#debug ip igmp
IGMP(0): Received v2 Query on Ethernet0/0 from 10.0.0.1
IGMP(0): Set report delay time to 5.2 seconds for 239.1.1.1
IGMP(0): Send v2 Report for 239.1.1.1 on Ethernet0/0
PC5#debug ip igmp
IGMP(0): Received v2 Query on Ethernet0/0 from 10.0.0.1
IGMP(0): Set report delay time to 7.6 seconds for 239.1.1.1
IGMP(0): Set report delay time to 1.2 seconds for 239.5.5.5
IGMP(0): Send v2 Report for 239.5.5.5 on Ethernet0/0
IGMP(0): Received v2 Report on Ethernet0/0 from 10.0.0.4 for 239.1.1.1
IGMP(0): Cancel report for 239.1.1.1 on Ethernet0/0
The above output show that PC5 cancel its 239.1.1.1 report because it received the same report from PC4 just before its timer ran out. This is a big improvement to reduce unnecessary IGMP message flooding.
PC4(config-if)#no ip igmp join-group 239.1.1.1
IGMP(0): IGMP delete group 239.1.1.1 on Ethernet0/0
IGMP(0): Send Leave for 239.1.1.1 on Ethernet0/0
R1#debug ip igmp
IGMP(0): Received Leave from 10.0.0.4 (Ethernet0/1) for 239.1.1.1
IGMP(0): Send v2 Query on Ethernet0/1 for group 239.1.1.1
IGMP(0): Received v2 Report on Ethernet0/1 from 10.0.0.5 for 239.1.1.1
The above output show that PC4 leaves the 239.1.1.1 and immediately sends a group leave message. Upon receiving it, R1 sends out a v2 query for that specific group and receives a response from PC5. If not response was found, R1 would remove the multicast entry.
This concludes the IGMPv2 chapter, let's move on to IGMPv3.
The latest and current IGMP version, adding some new features and changes to the protocol.
This new feature allows a receiver to specify a source IP-address for the multicast group it wants to join, making it an (S, G) message. This is a security feature that separates multicast flows based on which unicast IP-address is originating the flow, stopping others from injecting their own packets. An IGMPv3 receiver can specify that it wants to join the (10.10.10.10, 232.1.1.1) multicast group. If 2.2.2.2 then starts sending traffic to 232.1.1.1 it would be considered a different flow and may be dropped by the router. SSM has been assigned IP-range 232/8, so I will use that range in the examples below.
Another enhancement to IGMPv3 is the fact that the same membership report now can include multiple groups. Instead of PC5 having to send one report for each of its (*, 232.1.1.1) and (*, 232.5.5.5) groups, it now sends one report to 224.0.0.22 that includes both multicast groups. This undoes some of the work done by IGMPv2 to reduce flooding as each receiver may be members of different combinations of multicast groups and so their reports may look different, but there are still less reports thanks to all groups being announced by the same report message.
IGMPv3 has been assigned its own multicast address, used as destination address for any membership report. This address is necessary now that membership reports are grouped together. Previous versions would send one report for each group, using the multicast address of that group as the destination IP. When grouping the messages, some destination IP-address has to be set in the packet, so 224.0.0.22 was assigned.
With these features in mind, let's look at some IGMPv3 debug output:
R1#show running-config
!
interface Ethernet0/1
ip address 10.0.0.1 255.255.255.0
ip pim sparse-mode
ip igmp version 3
---
R1#debug ip igmp
IGMP(0): Send v3 general Query on Ethernet0/1
IGMP(0): Received v3 Report for 1 group on Ethernet0/1 from 10.0.0.4
IGMP(0): Received Group record for group 232.1.1.1, mode 1 from 10.0.0.4 for 1 sources
IGMP(0): Updating expiration time on (10.10.10.10,232.1.1.1) to 180 secs
!
IGMP(0): Received v3 Report for 2 groups on Ethernet0/1 from 10.0.0.5
IGMP(0): Received Group record for group 232.1.1.1, mode 1 from 10.0.0.5 for 1 sources
IGMP(0): Updating expiration time on (10.10.10.10,232.1.1.1) to 180 secs
IGMP(0): Received Group record for group 232.5.5.5, mode 1 from 10.0.0.5 for 1 sources
IGMP(0): Updating expiration time on (11.11.11.11,232.5.5.5) to 180 secs
---
R1#show ip mroute
(11.11.11.11, 232.5.5.5), 01:32:18/00:02:06, flags: sTI
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse, 01:32:18/00:02:06
(10.10.10.10, 232.1.1.1), 01:38:40/00:02:06, flags: sTI
Incoming interface: Null, RPF nbr 0.0.0.0
Outgoing interface list:
Ethernet0/1, Forward/Sparse, 01:38:40/00:02:06
PC4#show running-config
!
interface Ethernet0/0
ip address 10.0.0.4 255.255.255.0
ip igmp join-group 232.1.1.1 source 10.10.10.10
ip igmp version 3
---
PC4#debug ip igmp
IGMP(0): Received v3 Query on Ethernet0/0 from 10.0.0.1
IGMP(0): Set report delay to 4.8 seconds to respond to General Query
IGMP(0): Building v3 Report on Ethernet0/0
IGMP(0): Add Group Record for 232.1.1.1, type 1
IGMP(0): Add Source Record 10.10.10.10
IGMP(0): Send v3 Report with 1 group records on Ethernet0/0
PC5#show running-config
!
interface Ethernet0/0
ip address 10.0.0.5 255.255.255.0
ip igmp join-group 232.1.1.1 source 10.10.10.10
ip igmp join-group 232.5.5.5 source 11.11.11.11
ip igmp version 3
---
PC5#debug ip igmp
IGMP(0): Received v3 Query on Ethernet0/0 from 10.0.0.1
IGMP(0): Set report delay to 8.3 seconds to respond to General Query
IGMP(0): Building v3 Report on Ethernet0/0
IGMP(0): Add Group Record for 232.1.1.1, type 1
IGMP(0): Add Source Record 10.10.10.10
IGMP(0): Add Group Record for 232.5.5.5, type 1
IGMP(0): Add Source Record 11.11.11.11
IGMP(0): Send v3 Report with 2 group records on Ethernet0/0
We can see an increase in debug output as there is more going on. Starting with R1, its general Query is first responded to by PC4, who announces that it is a member of the (10.10.10.10, 232.1.1.1) multicast group. Shortly after the PC5 report is received announcing its two groups: (10.10.10.10, 232.1.1.1) and (11.11.11.11, 232.5.5.5). The output of PC4 and PC5 show their respective point of view.
So IGMPv3 makes some big changes to IGMP; it adds the possibility for the receiver to specify which source IP it is interested in receiving the multicast traffic from, and the membership reports now includes all groups instead of sending one report per group. This overrides the IGMPv2 flood reduction as both PC4 and PC5 has to report that they are members of the same 232.1.1.1 group. However, this increase in IGMP flooding may be negated by IGMP Snooping that will be covered in another post.
This concludes our look at the IGMP protocol. We have covered all versions of the protocol, from the simple but slow IGMPv1 to the reduced flooding in IGMPv2 to the security features of SSM in IGMPv3. If you want to learn about the switch-side of the IGMP protocol I can recommend the chapter on IGMP Snooping where the switches get involved to further reduce multicast flooding.