IGMP Working Principle
IGMP Version 1
IGMP Version 2
IGMP Version 3
MAC Address of Multicast Group
I have introduced the Layer 3 multicast protocol PIM (Protocol Independent Multicast) in this webpage. For layer 2, IGMP (Internet Group Management Protocol) is playing the role of connector between Host and PIM Router. I recommend that reader should have basic knowledge of PIM before reading this article since PIM is the upstream of multicast and IGMP is the downstream, it will be easier to study IGMP if you know PIM.
IGMP Working Principle
Assume the multicast traffic have already arrived to the last PIM router of a Layer 3 PIM network. The problem is this router have more than one interface and which interface the router should send the multicast to? Which hosts need the multicast traffic? IGMP is the language between host and router to tell the router that which host is requesting which multicast group.
The mechanism is simple. When the router (IGMP Querier) receive some multicast groups, it will send query message to ask which host want to receive the groups. If a host (receiver) needs, it will reply an IGMP Membership Report message and the router knows some hosts on this interface need the traffic. What it need to do is send the multicast traffic to this interface. Oppositely, if the host do not response, router will know that no host is requesting this group and the multicast traffic is not needed to be sent.
There are three version of IGMP, that is version 1, version 2 and version 3.
IGMP Version 1
While IGMP version 1 is used, the default query-interval is 60 seconds means that the router will send Membership Query every 60 seconds to ask that if there are anyone needs the group. Host will reply IGMP Membership Report if it needs. If router receive the reply with a Max Response Time (default 10 seconds), it know that some hosts need the multicast group. To maintain the multicast group, host needs to send IGMP Membership Query every time it receive a Membership Query in the future. If the host do not want to receive the Multicast Group anymore, it just ignores the query message. If router do not receive IGMP Membership Report for 180 seconds, it assume that no one need this group anymore. On the other hand, host can send IGMP Membership Report to the router actively any time to request a group instead of waiting the Membership Query message. The following command shows how to change the query-interval,
R1(config-if)#ip igmp query-interval 120
IGMP Version 2
Version 2 enhances with Leave Group Message. When host do not want to receive a group anymore, it can send a Leave Group Message to the router. When router receives a Leave Group Message, it sends Last-member-query by every Last-member-query-interval (default 1000ms) to ask whether any hosts still need the group. The number of query messages is determine by Last-member-query-count with default value of 2. It means that when a router receives Leave Group Message, it send out a Last-member-query. Wait for 1000ms and send out another. If there are no replies for both Last-member-query, router know that all host on that interface do not need the group. The following command shows how to change the Last-member-query-interval and Last-member-query-count.
R1(config-if)#ip igmp last-member-query-interval 2000 R1(config-if)#ip igmp last-member-query-count 4
If we confirm there is only one host on the interface, we could tell the router do not need to send Last-member-query when receiving Leave Group Message.
R1(config)#access-list 1 permit 126.96.36.199
R1(config)#int eth1/0 R1(config-if)#ip igmp immediate-leave group-list 1
Also, the Max Response Time can be changed starting from Version 2. It optimizes the determination of delivering the Multicast Group. Use the following command to change the Max Response Time.
R1(config-if)#ip igmp query-max-response-time 20
IGMP Version 3
Version 3 supports Source Specific Multicast (SSM) so that host can choose a specific source address of multicast traffic. To know more about the SSM, please take a look to PIM tutorial.
For the IGMP querier, IGMP automatically start while PIM is running on the router. For the receiver, if you want to use a router to act as a receiver when doing the experiment, you may use ip igmp join-group <group> to start the IGMP and use ip igmp version <ver> to choose the running version. The default version is 2.
R2(config-if)#ip igmp join-group 188.8.131.52 R2(config-if)#ip igmp version ? version number R2(config-if)#ip igmp version 2
最後我們可以用 show ip igmp interface 查詢 IGMP 的 Version 及 Timer 等資訊。
R2#show ip igmp interface ethernet 1/0 Ethernet1/0 is up, line protocol is up Internet address is 192.168.12.2/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 configured query interval is 60 seconds IGMP querier timeout is 120 seconds IGMP configured 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: 1 joins, 0 leaves Multicast routing is disabled on interface Multicast TTL threshold is 0 Multicast groups joined by this system (number of users): 184.108.40.206(1)
Router always send IGMP Query to communicate with hosts. If there are two or more routers on the same network, they may have same group thus sending duplicate query messages. So, an IGMP Querier will be elected to ensure that the query message are not sent repeatedly. IGMP version 1 choose PIM designated router to be the IGMP querier. For IGMP Version 2 and 3, smaller interface IP address will be the querier. For the setting of PIM designated router, please check the PIM tutorial.
After choosing an IGMP querier, if the querier fails for some reasons, the other router will wait for a querier-timeout and re-elect the querier. The default value of querier-timeout is the double of IGMP query-interval, that is 120 seconds. Here is the configuration of querier-timeout.
R2(config-if)#ip igmp querier-timeout 100
Multicast Group 的 MAC Address
We know that the router will do a one-to-one translate of the unicast traffic destination IP address to MAC address and deliver the message to the network. Devices with the destination MAC Address can receive and process the message. But, it does not have any destination IP address for multicast traffic. So, how the router handle the multicast traffic?
When a multicast packet is initialized, a MAC address is generated by using the group address and write to the packet. For example, the step of translating the group 220.127.116.11 to a MAC address is shown below,
Change 18.104.22.168 to binary: 11100000.00000001.00000010.00000011
Only keep the last 23 Bits: 0000001.00000010.00000011
Add the 25 Bits multicast MAC prefix: 00000001.00000000.01011110.0
Change to Hex: 0100.5e01.0203
Since the range multicast address (Class D, First 4 Bits 1110) is from 22.214.171.124 to 126.96.36.199, the above mechanism causes duplicate MAC address results for some groups, these group should be avoided to use together in the same network.
188.8.131.52 ➡️ 0100.5e01.0203
184.108.40.206 ➡️ 0100.5e01.0203
220.127.116.11 ➡️ 0100.5e01.0203
18.104.22.168 ➡️ 0100.5e01.0203
22.214.171.124 ➡️ 0100.5e01.0203 (Total 32 Groups duplicate results)
Router use the above translation. And client also use the same method when it joins a multicast group to calculate which MAC address it needs to listen to. So, when multicast traffic arrives, the client can receive and process it.
The next question is, now we add a switch between router and client. For unicast traffic, the source MAC address from host traffic is checked and the attached port of the host is learned. But for multicast MAC address, host never use it to send out traffic, so the switch will never learn the multicast group MAC address. Switch cannot handle the multicast traffic just like what it did for unicast traffic.
A solution to solve the problem is sending the multicast traffic to all ports (like broadcast), but it wastes bandwidth. Another efficient method is IGMP Snooping. The principle of IGMP Snooping is simple, switch check all Join and Leave Message that is sent by host to router. If a Join is transmitted, switch add the port and group to the Snooping Table. If a Leave is transmitted, the information is removed. So the switch knows which port is receiving which group based on the Snooping Table. IGMP Snooping is enabled on the switch. Use show ip igmp snooping groups to check the Snooping Table.
Switch#show ip igmp snooping groups Vlan Group Type Version Port List ----------------------------------------------------------------------- 1 126.96.36.199 igmp v2 Gi1/0/1 1 188.8.131.52 igmp v2 Gi1/0/2 1 184.108.40.206 igmp v2 Gi1/0/11
In simple words, IGMP Filtering can implemented done on router or switch.
On the router, it is called IGMP access-group. Access-list is used to control the router to accept or deny the multicast groups. For example, if a router do not accept a client to join the 220.127.116.11,
R1(config)#access-list 1 deny 18.104.22.168 R1(config)#access-list 1 permit any R1(config)#int eth1/0
R1(config-if)#ip igmp access-group 1
After configured, Join 22.214.171.124 will not be success and the following log will be seen when debug ip igmp.
R1#debug ip igmp IGMP debugging is on R1# *Mar 19 12:22:10.773: IGMP(0): Received v2 Report on GigabitEthernet8 from 192.168.123.2 for 126.96.36.199 *Mar 19 12:22:10.773: IGMP(*): Group 188.8.131.52 access denied on GigabitEthernet8
On the switch, it is called IGMP Profile. It can deny all transit IGMP Join message. For example, to deny join group from 184.108.40.206 to 220.127.116.11, the configuration will be,
SW1(config)#ip igmp profile 1 SW1(config-igmp-profile)#deny SW1(config-igmp-profile)#range 18.104.22.168 22.214.171.124 SW1(config-igmp-profile)#exit SW1(config)#int f0/1 SW1(config-if)#ip igmp filter 1
While debug, the following log will be received when illegal igmp join is detected.
SW1(config)#debug ip igmp IGMP debugging is on SW1# Mar 19 11:11:20.359: IGMPFILTER: igmp_filter_process_pkt() checking group from Gi1/0/1 : no profile attached
Was this article helpful?