IGMP Made Easy: Your Introduction to Internet Group Management Protocol

Multicast Fundamental

Many people will have a hard time understanding how multicast works. We will start out with the foundations of multicast, they build are way up. So the first question we should ask is, “What exactly is multicast?”

Multicast is a way of sending and receiving information when you have a group of people sending/receiving that information. Unlike a broadcast which goes to everyone, multicast will only send or receive to a group of people. Because it goes to and from a group of users, we do introduce two different terms:

• Sender – A node that will generate information, and sends to a a group
• Receiver – The group of devices receiving information from the sender

Multicast has the ability to send traffic three different ways:

• One-to-Many
• Many-to-One
• Many-to-Many

Address Blocks

The other thing to keep in mind is what blocks can be used for multicast. There’s multiple blocks needed for multicast:

• Local Network Control Block – Range is 224.0.0.0/24. Used for protocol control traffic such as OSPF or VRRP. . The assignments for this range is controlled by IANA and can’t be forwarded by routers across subnets.
• Internetwork Control Block – Range is 224.0.1.0/24. This block is also used by protocol control traffic, but the main difference is that it can traverse the network across networks. Some examples of this is NTP or mdhcpdiscover.
• AD-HOC Blocks – There is three different ranges for this block. These are publicly assigned by IANA and can be forwarded over the internet. Ranges include:
  • 224.0.2.0 – 224.0.255.255
  • 224.3.0.0 – 224.4.255.255
  • 233.252.0.0 – 233.255.255.255
• SDP/SAP Block – Range is 224.2.0.0/16. Session Description Protocol/Session Announcement Protocol. Used when a host needs to receives address through SAP.
• GLOP Block – Range is 233.0.0.0/8. Statically assigned to a domain with a ASN (Autonomous System Number) by IANA.
• Source-Specific Multicast (SSM) Block – Range is 232.0.0.0/8. Used by SSM to make sure only sources that want the traffic receives the traffic, and doesn’t get sent to unintended hosts.
• Administratively Scoped Block (239.0.0.0/8) – Similar to private IPv4 addresses, where we can subnet this into a more useable range for private use in our networks.

Group Subscription

Everything is done dynamically, from sending the stream to subscribing to a particular stream. In order to subscribe to a stream, it will send a join. This join message indicates that the host wants to start receiving multicast stream. When a host wants to leave the stream, stop receiving the information, or to stop sending traffic to a segment, it will send a leave.

In order send these IGMP Join and Leave across multiple subnets and routers, it has to populate the MFIB (Multicast Forwarding Information Base). The MFIB is responsible for forwarding multicast packets to other networks. The way this MFIB gets populated is by using PIM.

The below picture shows a brief description on how an IGMP leave packet is processed:

1. An IGMP Leave for the group 239.30.20.10 is sent from the Multicast host in order to tell the Source/Server and everything in-between that’s it’s no longer interested
2. When the router gets the IGMP leave, it will see if any other hosts on the subnet needs the stream, if not, it will forward a PIM Prune message to the upstream device saying it’s not no longer interested in that stream.

IGMP Basics

We mentioned IGMP a couple of times above, but this is what we will use to manage and and track subscriptions on each subnet. Then the querier, usually a router or gateway, will also IGMP Query messages to each host to see which streams they want.

IGMP hosts will send the join and leave messages described in the previous section, to be removed or added to that particular multicast stream.

IGMP Versions

There is three different versions when it comes to IGMP. Usually IGMP Version 2 will be default version on most stuff, but there is important differences between each of them.

Version 1

There are a few things we need to take note of in this version:

1. IGMPv1 has a very basic query system to determine which streams should be sent to a host
2. Has no leave mechanism
3. Can generate a large amount of unnecessary network traffic

The querier, described earlier as a gateway or router, will keep track of all the hosts need for the subnet by sending a message to every host on the subnet. This will send a message to the “all-nodes” multicast of 224.0.0.1. Instead of all hosts responding back to this query, only one host will respond back and all other hosts will suppress.

There is also no leave mechanism, meaning that it will continue sending the stream until a group times out. As a result, you will see a large amount of a unnecessary multicast traffic.

Additionally, since IGMPv1 doesn’t have the ability to elect a specific querier/router for a subnet, there’s a chance where we might send the same multicast packet multiple times if there is more than one querier in the subnet. This can be fixed by using PIM to elect a Designated Router (DR) for that subnet, so only one device can send at once.

Version 2

There is a couple of major differences in IGMPv2 compared to IGMPv1:

1. Introduction of the Leave Mechanism
2. Group Queries
3. Querier Election

One of the major differences in this version compared to the previous version is that leave mechanism was finally introduced. By introducing this, we can eliminate a lot of the unnecessary multicast streams since we can inform the querier that we are no longer interested in a stream.

Additionally, the group-queries capability was added. This makes it possible now where every host on the subnet doesn’t receive the multicast packet anymore.

Lastly, IGMP now has a built in querier election process instead of having to use PIM. The router with the highest IP address becomes the DR, which is responsible for forwarding the multicast packets. Likewise, the router with the lowest IP becomes the querier to keep track of who needs what.

Version 3

There is one major change we need to keep track of with IGMPv3, and that is Source Specific Multicast (SSM).

This will allow us to put the specific source IP for the hosts wanting to receive the stream inside the packet itself, and we can keep track a lot easier with the number of sources needed. This adds the ability to be more secure, because now we include or exclude specific sources from sending/receiving a stream from.

What’s Next?

This article mainly talks about IGMP and multicast works on the fundamental level. The bread and butter on where this confuses people is when PIM comes into play. For anything to be forwarded across subnet, Protocol Independent Multicast (PIM) has to be implemented:

The Core Concepts and Fundamentals of PIM Multicast