IGMP
Last updated
Internet Group Management Protocol (IGMP) is used by hosts to signal to their default router that they wish to receive multicast traffic for a particular multicast group. Without this protocol, a router would have no way of knowing whether hosts on the LAN want to receive multicast traffic, and which multicast groups they are interested in.
IGMP is essentially a query/response protocol. The router periodically asks “Do any hosts want multicast traffic? If so let me know the group address you are interested in.” A host responds with “Yes, please send me multicast traffic for group 239.1.1.1”
The IGMP query is repeated by the router every 60 seconds by default, as a keepalive-type mechanism. The host continues responding to every query with the groups it is interested in.
There are three versions of IGMP. IGMPv1 is outdated enough that it’s not really worth covering. We will cover IGMPv2 in this article. It is the default IGMP version on Cisco IOS-XE routers. IGMPv3 adds support for source-specific multicast. We’ll cover IGMPv3 when we get to PIM-SSM.
The quickest way to understand how IGMP works is to see it in action. We’ll use the following topology in our lab:
The Source and R1 are both CSR1000v routers. The switch is an IOSvL2. The hosts are IOSv routers. IOSv is used because in my experience, it responds to ICMP messages destined to a multicast group IP that the router joined, while the CSR1000v does not. The switch has the default config; all switchports are access ports in vlan 1.
First we’ll enable IGMP on R1. Notice that R1 is both the FHR and LHR in this simple topology. To enable IGMP we must turn on PIM. We’ll look at PIM later, but for now we’ll simply enable PIM dense-mode on Gi1 and Gi2. We also must turn on ip multicast-routing which is kind of similar to turning on ipv6 unicast-routing to enable the router to forward IPv6 traffic. When you enable PIM on an interface, it also enables IGMPv2 on the interface.
Immediately R1 will begin sending IGMP queries at a 60 second interval out both Gi1 and Gi2. We are only interested in the LAN side, Gi2, because that is where our hosts are.
You can see that IGMP is a fairly simple protocol. The Type of the message is Membership Query. “Membership” refers to multicast group membership. Hosts that are interested in traffic for a particular multicast group are said to be members of the group. The maximum response time is 10 seconds. This is the time a host has to respond to the query. You will see why this is set to 10 seconds later in this article. The multicast address field is all zeros (0.0.0.0) in a General Query.
Right now each memership query is going unanswered. There are no multicast hosts on the LAN yet. We’ll now enable the multicast client functionality on Host1. We issue the command ip igmp join-group 239.1.1.1 under the interface. This instructs the router to join this multicast group, acting as a client that is interested in receiving multicast traffic for this group.
The host will first send an unsolicited membership report (frame 20), and then begin responding to every membership query (frame 39 and 59).
You can see that the Membership Report simply has the multicast address field as the group the host is interested in. The max response time field is set to 0 in the membership report. Only the querier (R1) sets the max response time in its messages. The first membership report a host sends is referred to as an “IGMP Join” because the host is joining the group.
Notice in the previous screenshot that each membership report is sent by Host1 within 10 seconds of the membership query, but it seems to be a random interval. Frame number 39 was 4.9 seconds later, and frame number 59 was 5.3 seconds later.
The max response time field is an optimization for when there are many hosts on a LAN that are all interested in the same multicast group. Instead of all hosts responding to the query immediately, potentially flooding the LAN with membership report messages, they each run a random timer that determines when they will respond to the query. The host software selects a random value between 0 and the max response time (which was signaled in the membership query).
If any host sees another membership report for their own group on the LAN before their own timer goes off, they cancel their pending membership report. This is called membership report supression. This prevents the flooding of duplicate membership reports. The querier (R1) only cares about whether there is at least one interested host, it does not matter if there is 1 host or 50 hosts interested in a single group. Either way, the router simply forwards multicast traffic for the group to the LAN.
Let’s enable the multicast client functionality on Host2 and see membership report suppression in action.
Either Host1 (10.10.10.10) or Host2 (10.10.10.2) responds to a membership report, but never both. R1 doesn’t actually care how many or which hosts are interested in the multicast traffic, it only cares that there is at least one host on the LAN interested in the traffic.
The configuration we have so far is sufficient for multicast traffic to work. The source will route 239.1.1.1 towards its default gateway, the FHR, which is R1. R1 is running PIM dense mode on the interface facing the Source, so it will accept the multicast traffic and route it. R1 has hosts interested in 239.1.1.1, and will forward traffic out Gi2 towards the switch. The switch replicates the traffic and treats it as broadcast, since we do not have IGMP snooping enabled. The received frame is replicated out all ports belonging to the VLAN (except the port where it was received).
If we generate a ping on the Source destined for 239.1.1.1, both hosts will respond:
Using ICMP in this way just verifies that multicast traffic is working. Normally in the real world, hosts just receive a UDP stream. They would not typically respond to the source directly like this.
When a host leaves a group, it sends an IGMP Leave Group message. Let’s remove the config statement on Host2 which instructs the router to subscribe to 239.1.1.1.
Upon issuing this command, Host2 immediately sends the Leave Group message with the multicast address set to 239.1.1.1
R1 reacts to this by sending a targeted membership query. The multicast address is 239.1.1.1 in this query. In the general membership query we saw before, the address was set to 0.0.0.0. Also notice that the max response time is now 1 second instead of 10 seconds. This membership query is R1 asking “Before I stop sending traffic for 239.1.1.1 onto this LAN, is there anyone else still interested in 239.1.1.1? You have one second to let me know.”
In frame 15 above, Host1 sends a membership report for 239.1.1.1 within one second to let R1 that it is still interested in this multicast group. R1 continues forwarding multicast traffic for group 239.1.1.1 onto the LAN.
Let’s say the last host interested in 239.1.1.1 crashes and does not send an IGMP Leave message. How does R1 know to stop sending traffic for 239.1.1.1 onto the LAN?
The general query sent at 60 second intervals is used for this purpose. By default, if three general queries go by with no membership report for 239.1.1.1, the router will stop sending traffic for 239.1.1.1 to the LAN.
You can see the current active IGMP groups and their corresponding outgoing interface with the command show ip igmp groups
Under normal circumstances, you will see the expiration fluctuate between 2 and 3 mins. This is very similar to the Hello mechanism used for routing protocol neighborships. For example, with OSPF you would see a neighbor’s dead time fluctuate between 30 and 40 seconds.
The last IGMP feature we have not covered is querier election. Right now we have a single querier, R1. If we had multiple routers on the LAN (perhaps for redundancy, running a protocol such as VRRP or HSRP between them), it would not make sense for both routers to query the LAN.
In this situation, the routers use the IGMP general query messages to elect the IGMP Querier. The router with the lowest IP address on the subnet is the IGMP Querier. The routers determine this individually upon receiving IGMP general query messages from the other router. If the router has a lower IP address than the received general query message, it continues querying the subnet. If the router has a higher IP address, it ceases to send query messages. This router will watch for the querier to go down and take over the querier role when it sees no query messages for two query intervals (2x 60 seconds).
IGMP is a protocol used by hosts to signal their interest in multicast traffic to their default router. IGMP is a simple query/response protocol in which the router periodically asks whether hosts are interested in multicast traffic using a General Membership Query. These are sent at 60 second intervals. If 3 minutes go by without a Membership Report for a given multicast group, the router removes that group from its table and stops sending traffic for that group onto the LAN.
In the next few articles we will cover PIM, which is the multicast routing protocol used by routers to signal to other routers their interest in receiving multicast traffic. This interest is driven by IGMP. When hosts signal interest via IGMP, the LHR then uses PIM to tell its neighbors that it has hosts interested in the multicast group. This is how the tree is built. We will first look at PIM Dense Mode, as it is the simplest PIM variant.
