Spoke: IGMP (Multicast)
In the last post, we talked about some of the fundamental details of multicast, the challenges it solves, and the basics of how it works. This time, let’s focus on the method by which receivers signal their interest in multicast feeds. I’m intentionally skipping a few things here because I’ll cover them in another post (Addressing, MAC Addresses and Group Overlap). Right now I want to focus on the receivers, next time we’ll focus more on the sources and considerations.
Receivers use multicast in different ways, but in general, a receiver is an endpoint that is (or wishes to be) ‘tuned-in’ to a multicast group. Generally, any interest in multicast beyond a link-local scope requires the use of Internet Group Management Protocol. IGMP is the radio tuner that receivers use to tell the network into which station to tune.
In the above topology, the LHR routers are performing multiple functions. LHR-A is the HSRP primary for the VLAN on which the receivers reside. LHR-B is the HSRP backup. Both routers listen for IGMP traffic from the attached segment, but only LHR-A will send IGMP traffic onto the wire. LHR-B listens and stands by in case the active router fails.
Before we start talking about IGMP traffic flows, let’s start with a short history lesson, then break down the kinds of IGMP messages we’ll see. There are three versions of IGMP, and each version beyond the original introduced game-changing improvements.
IGMPv1
The original IGMP was extremely basic, consisting only of an IGMP Query and an IGMP Report message. In simplest terms, an IGMP Query is a router shouting, “Marco!” and an IGMP Report is a receiver shouting, “Polo!” This simple mechanism allowed for a timer-based way to verify that multicast traffic was needed on a segment.
When a receiver wanted to signal interest in a particular multicast group, it sent an IGMP Report with the group address onto the network segment, relying upon an IGMP router to take it from there. Receivers did not have to wait for a Query message to do this. However, when a router wanted to check to see if a segment was interested in (or still wanted to receive) multicast, it sent a general IGMP Query message out to all hosts, relying on them to respond. Receivers wanting multicast traffic would respond to a Query with a Report based on a random timer, and if another host heard a Report for groups it also wanted to receive it would suppress its own Report.
This crude game of Marco Polo was sufficient at first, but lacked an important feature: Hosts couldn’t signal when they were done playing! The Query timer was 60 seconds, and it took three missed Reports before the router would prune the feed. This meant it would take three minutes before multicast traffic was removed from a segment with no receivers!
What’s worse, if there were multiple routers attached to the segment, they ALL did this. They all sent Queries and they all expected to hear Reports. There was no way to specify which router should control the Query function for the segment. This increased the amount of traffic just to start, stop and keep multicast traffic flowing.
IGMPv2
The next version of IGMP introduced an incredible amount of improvements. Queries were expanded to either be general or group-specific. The IGMP Leave Message was added in order to optimize the process by which multicast traffic was pruned. The IGMP timers became tunable, and IGMP added the ability to elect one router per segment to perform the function of querier. This reduced the amount of multicast maintenance traffic needed on segments that contained multiple IGMP routers.
The process of sending Report and Query messages changed to take advantage of the new extensions. IGMP queriers alone send the Query messages to a segment, but any IGMP router can receive a Query or Report message and act depending on its role. In this lab network, while LHR-A is the IGMP querier, it is LHR-B which will take action based on an IGMP Report or IGMP Leave. I’ll show this a bit later when we examine outputs.
When a host sends an IGMP Leave message, signalling that it no longer wishes to receive multicast traffic for a group, the IGMP querier sends an immediate Group-Specific Query to see if any other receivers exist for that group. This optimizes the query process by only targeting interested receivers. If no Report message is sent, that multicast traffic can be pruned much faster.
It’s worth noting that IGMPv2 is the standard version implemented on Cisco routers as of now. It is also fully compatible with IGMPv1. When an IGMPv2 router hears an IGMPv1 report from a receiver, it falls back to using IGMPv1 queries for a period of time. If time passes without new IGMPv1 reports, it will revert back to using IGMPv2 queries. For this reason, it’s best to try and ensure receivers are using the most up-to-date version of IGMP available in order to take advantage of the improvements.
IGMPv3
So what’s left to improve? Well, IGMPv3 saved the best for last. In this version, the major extension was to add a field for a source-specific multicast group Report message. Until IGMPv3, receivers did not have the ability to request a multicast feed from a specific source. This new ability to actively seek multicast from a particular source is called Source-Specific Multicast and will be covered under a separate post. IGMPv3 also removed the Leave message in favor of a Block Source / Include Zero Sources message, since sources are now part of the equation. Hosts no longer receive each other’s Reports, meaning that report suppression no longer takes place. This is actually a good thing when we deal with IGMP Snooping, which we will discuss shortly.
It’s important to understand that before SSM support was added, receivers could only signal interest in a particular multicast group feed. It was up to the network to determine what sources were sending to that group and then pair sources and receivers. This is known as Any-Source Multicast, and it is this form of multicast which feeds most of the confusion and fear that people think of when they think “Multicast is hard”.
IGMPv3 is backwards compatible with the two previous versions, and an IGMPv3 querier will fall back to using the previous version’s messages if received. This could be potentially bad if some receivers on the segment wish to use SSM, but other receivers don’t support IGMPv3. Also important is that some older switches might not support IGMPv3 for IGMP snooping.
This Isn’t Complicated Enough, What’s This About IGMP Snooping?
IGMP Snooping is an optional, per-vlan feature available with multi-layer switches. It’s similar to DHCP Snooping. The switch listens for IGMP Report and Query messages and maps the groups and ports to a snooping table. In this way, it optimizes the messaging and ensures that only interested receivers receive multicast messages for these groups. It also maps the IGMP router ports in order to deliver IGMP Reports effectively.
Enough Talk! Let’s See IGMP in Action!
Okay, let’s get a quick refresher on the topology. I’ll put it here so we can reference it with outputs.
So first of all, let’s look at the steady state of this network. LHR-A is the IGMP querier for the segment, LHR-B is the PIM designated router (more on this in another post), and the switch is performing IGMP snooping.
Under normal circumstances, the IGMP querier will send a general query onto the segment every 60 seconds to verify if any hosts are receiving, or want to receive multicast. The IGMP snooping switch will record the port that receives the Query message as an IGMP Router port.
What happens when a multicast receiver attached to the segment signals that it wants to join 239.1.2.3? Here’s what the IGMP snooping switch does:
First, the switch needs to update its snooping table based on the IGMP Report it received. Then it will forward the Report message to the port on which the IGMP router (or routers) for the segment resides. This is actually really simple. Despite all the text in the outputs, what’s happening is clear. The receiver has turned on the radio and tuned to a station. The switch now just needs to signal the multicast network to find the feed.
LHR-A is the IGMP querier for the segment, but both IGMP Routers listen for Query and Report messages. If LHR-A fails, LHR-B would take over as the querier if it doesn’t hear any Query messages for a bit. The last part of this output is relevant to Protocol Independent Multicast, which will be covered in another post as mentioned. For now, understand that PIM is how we go from a receiver’s signalling to the actual multicast routing/delivery.
Even though LHR-A is the IGMP querier for the segment, all IGMP routers listen for Query and Report messages. Since LHR-B is the PIM designated router for the segment, it is this router which will act on the IGMP Report and send it into the multicast network.
Let’s suppose that the feed was delivered and that the receiver no longer wished to participate. Next we’ll show an IGMP Leave message and see how the network deals with that.
LHR-A receives the IGMP Leave and immediately sends a Group-Specific Query. Importantly, the other IGMP router on the segment, LHR-B, doesn’t send any Query though it also receives the Leave message.
LHR-B is the PIM designated router on the segment, so it will take the action of signalling upstream to the rest of the multicast network that the feed can be stopped. We’ll cover PIM in detail in another post.
I Thought This Was Supposed To Be Easy!
The most important thing to remember about IGMP is that it serves the function of signalling the receiver’s interest in multicast to the network. The current version is IGMPv3, which has been the current version for well over 10 years now. There are still many multicast applications and IOT-style devices that do not support IGMPv3, however.
I can bottom-line it this way:
IGMPv1 – Marco Polo, legacy, don’t use this. It takes forever to react to any changes and is incredibly inefficient.
IGMPv2 – One router sending Query messages per segment. Periodically checks in with general Query messages, and also Group-Specific ones when receivers signal that they wish to leave a group. This ensures other receivers won’t lose their feeds in an efficient way.
IGMPv3 – Everything you like about IGMPv2, but now we can directly request multicast from a particular source! That vastly optimizes and improves the multicast routing and delivery. More on this later.
Next time, we’ll start talking about multicast routing after the IGMP Report has been turned into a PIM Join. We’ll cover how PIM works and start discussing challenges of pairing sources and receivers in networks that don’t use IGMPv3 and SSM exclusively.
