Disclaimer: This post does not cover platform specific understanding/troubleshooting of Multicast. It covers IGMPv2 from a platform independent, technology point of view.
I've always avoided Multicast like the Plague. There I was, one fine day, working on a case when the main concern was found to be due to an underlying multicast problem. Naturally I had to have someone else work the case from here on. Another engineer took over the call and had it fixed in no time. His explanations and methodical approach were fantastic; since then, I have been inspired to learn this technology to the best of my abilities. This post, and the ones that follow, will hopefully help someone transition into this technology with ease and add value to their multicast studies.
The concept of multicasting is best understood by how radios and televisions stream data. They send data to a specific channel/frequency; end users that wish to receive this data then "tune" into this channel/frequency. Multicasting is thus the transmission of information to a group of receivers. The source of a multicast stream does not necessarily need to know who the receivers are; the receivers need not know who the source is.
When I started out, I'd hear a lot of IGMP and PIM being thrown around but I was never sure what these protocols were, what they were used for and what was the necessity for both of their existence. Let's break that down now:
Internet Group Management Protocol (IGMP): This is what a host/receiver uses to communicate with multicast routers and informs them of its need to receive data for a specific multicast address. IGMP, thus, runs between a host and a multicast router.
Protocol Independent Multicast (PIM): This is what multicast routers use to communicate with each other. PIM, thus, runs between a multicast router and a multicast router. It is used to build the multicast tree (more on that later).
Now that we've got that out of the way, the remainder of this post focuses on IGMP (IGMPv2), the communication between a host that wishes to receive traffic for a specific multicast group and a multicast router. I'll use the following topology to walk through the working of IGMP:
When a host wants to join a multicast group, it does so by sending out 'Membership Report' packets to the router. These membership reports are destined to the group address that the host wants to join.
In our topology, when Host-1 comes up and decides that it wants to join the multicast group for 220.127.116.11, it sends out an unsolicited membership report that is destined to 18.104.22.168. This informs R1 and R2 that there is a host on their Ethernet segment that wishes to join that specific group. The question, that then arises, is how this host maintains its join status in the group? Does it continuously send out unsolicited reports to the routers at every X interval? Well, not exactly. It is the routers job to continuously poll to check if there are any hosts that wish to receive multicast traffic. This is done by sending out 'Query' messages. A host interested in receiving data then sends membership reports in response to a Query. A query is sent out every 60 seconds by default.
In our topology, there is more than one router on the same LAN segment. It wouldn't make sense for both to continuously send queries on this segment. That would be bandwidth and router resources being wasted. In such cases, there is a single 'querier' chosen from all the routers on the segment. It is the querier's responsibility to, well, send out queries. The querier election is fairly simple. Let's understand this using our topology.
Fa0/1 of R1 and R2 are configured with ip pim dense-mode. Enabling PIM on an interface also enables IGMP. We should start seeing queries being sent out now. Since there are two routers on this segment, which would be elected the querier? The process is very simple. The lowest IP address wins.
So when R2 hears the general query from R1, it looks at the source IP address of the packet. Since it is lower than its own IP address, it loses its querier status (naturally R2 would believe it is the querier till it heard R1's query).
We can confirm this with the following:
R1#show ip igmp interface fa0/1
FastEthernet0/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 2
Current IGMP router version is 2
IGMP query interval is 60 seconds
IGMP querier timeout is 120 seconds
IGMP max query response time is 10 seconds
Last member query count is 2
Last member query response interval is 1000 ms
Inbound IGMP access group is not set
IGMP activity: 2 joins, 0 leaves
Multicast routing is enabled on interface
Multicast TTL threshold is 0
Multicast designated router (DR) is 192.168.1.2
IGMP querying router is 192.168.1.1 (this system)
Multicast groups joined by this system (number of users):
There is a bunch of useful information that can be derived from this command:
IGMP query interval: This is the interval (in seconds) after which a query is sent out. Thus, by default, a query is sent out every 60 seconds. This timer can be modified using the 'ip igmp query-interval <value in seconds>' sub-interface command.
IGMP querier timeout: This is how long a router waits to hear query from the querier before declaring it dead and moving itself to a querier status. Be default, the value for this is 120 seconds. This can be modified using the 'ip igmp querier-timeout <value in seconds>' sub-interface command.
IGMP max query response time: This is the time within which a router expects to hear a membership report from the segment. By default, the value for this is 10 seconds. This can be modified by using the 'ip igmp query-max-response-time <value in seconds>' sub-interface command.
A debug ip igmp also gives us good information:
R1#debug ip igmp
*Sep 23 10:25:04.239: IGMP(0): Send v2 general Query on FastEthernet0/1
*Sep 23 10:26:04.239: IGMP(0): Send v2 general Query on FastEthernet0/1
You can see from the timestamps that a general query is being sent out every 60 seconds.
*Sep 23 10:34:28.083: IGMP(0): Received v2 Report on FastEthernet0/1 from 192.168.1.3 for 22.214.171.124
The above tells us exactly who sent a membership report and for which multicast group address.
Note: Host-1 is actually a router that is acting as a host trying to join 126.96.36.199 by adding the 'ip igmp join-group 188.8.131.52' under fa0/0.
Suppose, in our topology, there is more than one host in the Ethernet segment. When these hosts receive a Query from the router, each of them sets a delay timer to a random value between 0 and the Max Response Time (this is specified in the Query messages and is 10 by default). When this delay timer expires, the host sends out a membership report for every group that it wants to join/remain subscribed to. Naturally, one host will have its delay timer expire first. When the other hosts hear this membership report (all hosts that are subscribed to the same group will hear it since these reports are destined to the group address itself), they reset their delay timer and back off from sending a membership report for the same group. This process is also commonly referred to as 'report suppression'.
The concept behind report suppression is that a router does not need to know exactly how many members wish to receive traffic for a specific group and/or who exactly those members are. As long as there is at least one host that wishes to receive traffic on that segment, it will continue to send data on that segment. Report suppression also helps avoid unnecessary flooding of membership reports in a segment.
Say, there were another host, Host-2, connected to this LAN segment. R1 sends out a general query that reaches both these hosts. The point of the 'max response time' is to let the hosts know that they need to set their delay timers to a value between 0 and max response time. With a debug ip igmp on both Host-1 and Host-2, let's see what they do when they receive a general query.
IGMP(0): Received v2 Query on FastEthernet0/0 from 192.168.1.1
IGMP(0): Set report delay time to 8.6 seconds for 184.108.40.206 on FastEthernet0/0
IGMP(0): Received v2 Query on FastEthernet0/0 from 192.168.1.1
IGMP(0): Set report delay time to 4.6 seconds for 220.127.116.11 on FastEthernet0/0
From the delay timers set, we can safely assume that Host-2 will be sending a membership report before Host-1. Host-1 should get this and suppress it's report. This is exactly what happens:
IGMP(0): Send v2 Report for 18.104.22.168 on FastEthernet0/0
IGMP(0): Cancel report for 22.214.171.124 on FastEthernet0/0
Let's now understand what happens if a host decides to leave a group. Unlike IGMPv1, IGMPv2 incorporates a new type of message called the 'leave group' message. When a host leaves a group, it sends it's local router a leave group message. This is destined to 126.96.36.199, the 'all routers' address. The reason being that other members of the group need not be aware of when another member leaves the group. The leave group message is nothing but a membership report with the type code identifying the message as a leave group message.
Based on how the multicast application has been coded, we can have every host that leaves a group send out a leave group message, however RFC 2236 recommends that a leave group message be sent out only if the host was the last to respond to a query message. This helps throttle down the queries a little bit. Other members of the group can leave quietly and the router continues to forward traffic to that segment.
Another thing to note, when a router responds to a leave group message with a query, the query is not a general query. This query is destined to the group that the host is leaving (as identified by group address in the leave group message) and is thus known as a group specific query.
Let's understand this with another lab example. I will make Host-1 leave this group:
Host-1(config-if)#no ip igmp join-group 188.8.131.52
On R1, with a debug ip igmp, we see the following:
IGMP(0): Received Leave from 192.168.1.3 (FastEthernet0/1) for 184.108.40.206
IGMP(0): Received Group record for group 220.127.116.11, mode 3 from 192.168.1.3 for 0 sources
IGMP(0): Lower expiration timer to 2000 msec for 18.104.22.168 on FastEthernet0/1
IGMP(0): Send v2 Query on FastEthernet0/1 for group 22.214.171.124
IGMP(0): Send v2 Query on FastEthernet0/1 for group 126.96.36.199
Before we wrap up, let's have a look at each of the IGMP packets:
Group Specific Query:
From the above packets we can see that the packet format remains the same for all IGMP messages. A general IGMP packet format, thus, would be:
The 'type' is used to identify what kind of packet it is:
Membership Query: The type value is set to 0x11 for this. Queries can be of two types as we've seen:
General query: The group address is set to 0.0.0.0 while the destination IP address is 188.8.131.52.
Group specific query: The group address is set to the multicast group address that the leave group message was received for. The destination IP address is also set to the same.
Leave group message: The type value is set to 0x17. The group address is set to the multicast group address it is leaving and the destination IP address is set to 184.108.40.206, the 'all routers address'.
Membership reports: For a version 1 report, the type value is set to 0x12. For a version 2 report, the type value is set to 0x16. For both the group address and destination IP address is set to the multicast group address the report is being generated for.
We have a pair of 3750Gs that we are seeing some orange lights on. There is a trunk between the two switches and off of each port a loop hangs, ie port 5 on the first switch is connected to a bunch of other switches that eventually come back to port...
I have an MX64 that has (very intermittent) connectivity issues with the outside world. It can be anywhere from 4 minutes to 15 minutes and it can happen 3 times in a day or once in a week. When I check the event logs I see 'Ethernet port carrier change'....
Hello every body, I have this setup (object of this post), but i can't use 10G copper connexion to my computer.Every time i used a TenGigabitEthernet1/0/X (with X 1 to 8), the interface go down with err-disabled on "sh interface". The message is...
Hi ,I am currently having an issue with 9300 Stack of switches running IOSXE Amsterdam. I have followed the procedure on cisco's website "System Management Configuration Guide, Cisco IOS XE Amsterdam 17.3.x (Catalyst 9300 Switches) - Configuring Smar...
Refer to the exhibit. An engineer is bringing up a new circuit to the MPLS provider on the Gi0/1 interface of Router 1. The new circuit uses eBGP and learns the route to VLAN25 from the BGP path.What is the expected behavior for the traffic fl...