Common Issues with IGMP

By Anthony Sequeira on March 28th, 2012

Common Issues with IGMP

IGMP is a very simple protocol to troubleshoot. IGMP uses a simple operational mechanism to accomplish its duties forwarding multicast packets. Even though the overall process is simple, dividing it into specific phases makes troubleshooting more straightforward. To simplify troubleshooting common issues while deploying IGMP, we identify three categories of problems: Host Fails to Send IGMP Joins, Switch Fails to Forward IGMP Packets, and IGMP Packet Filtering.

Host Fails to Send IGMP joins

This section deals specifically with IGMP version 2 because it is the default IGMP version employed by Cisco IOS. It is important to note that successful troubleshooting of IGMP depends on role-based operations within the protocol. A host failing to send a IGMP membership report is a common issue encountered while deploying IGMP. In effect, this means that a host is not notifying the IGMP router that it has joined a multicast group.

Failure of a host to send IGMP joins would most probably be the result of a poorly written multicast application, or a configuration mistake in a testing scenario. Configuration mistakes may include but are not limited to; failure to apply an ip igmp join-group command or ip igmp static-group command under an interface. Additionally, the wrong multicast group applied to an interface prevents a host router from sending a membership report for the correct multicast group.

Switch Fails To Forward IGMP Packets

Thus far, we have addressed the fact that IGMP Multicast involves both a method of delivery and discovery of senders and receivers of multicast data. This information is transmitted via IP multicast addresses called groups. A multicast address that includes a group and source IP address is a channel or stream. The fact that the successful operation of multicast IGMP depends on the correct configuration of the upstream switch has not been addressed as of yet. By default, switches like the Catalyst 3560 utilize a concept called IGMP Snooping.

IGMP snooping, scopes the flooding of multicast traffic by dynamically configuring Layer 2 interfaces so that multicast traffic is forwarded to only those interfaces associated with IP multicast devices. IGMP snooping requires the LAN switch to monitor IGMP transmissions between the host and the router and to keep track of multicast groups and member ports.

When a switch receives an IGMP report from a host for a particular multicast group, the switch adds the host port number to its forwarding table entry; when it receives an IGMP Leave Group message from a host, it removes the host port from the table entry. It also periodically deletes entries if it does not receive IGMP membership reports from any multicast clients.

The most common issue that can cause problems where a switch does not forward IGMP messages are where IGMP Filtering and Throttling have been erroneously configured, or previous configurations have not been completely removed.

  • IGMP Filtering – filters multicast joins on a per-port basis by configuring IP multicast profiles and associating them with individual switch ports. IGMP filtering controls only group-specific query and membership reports, including join and leave reports and does not control general IGMP queries. IGMP filtering is applicable only to the dynamic learning of IP multicast group addresses, not static configuration.
  • IGMP Throttling - throttling sets the maximum number of IGMP groups that Layer 2 interfaces can join. Utilization of this technique can cause a switch to drop IGMP membership reports.

Apply IGMP Filtering using the ip igmp filter command. Apply IGMP Throttling using the ip igmp max-groups command. Both are interface level commands.

IGMP Packet Filtering

IGMP Throttling and Filtering deal with IGMP packets at Layer 2 on a switch. There are versions of the same concepts designed to function at Layer 3. On routers, the ip igmp access-group and ip igmp limit commands accomplish these same goals:

  • ip igmp access-group – used to filter groups from IGMP membership reports by applying a standard access list. This command restricts hosts on a subnet to joining only multicast groups permitted by the configured standard IP access list.
  • ip igmp limit – used to configure a limit on the number of mroute states that are created as a result of IGMP membership reports (IGMP joins). Membership reports exceeding the configured limits do not enter the IGMP cache.

The most common issue that can cause problems where a router does not accept IGMP join messages are where IGMP Filtering or limiting have been erroneously configured, or previous configurations have not been completely removed.

This post was an excerpt from the IPv4/6 Multicast Operation and Troubleshooting book from IPexpert.

Anthony Sequeira CCIE, CCSI
Twitter: @compsolv


Common Issues with IGMP, 3.5 out of 5 based on 2 ratings
Be Sociable, Share!

    Tags: Cisco, igmp, multicast, practice, Troubleshooting

    2 Responses to “Common Issues with IGMP”

    1. Amit Bhagat says:

      One more – the Cisco switch remarks the IGMP messages to COS=6. This is not good for a service provider network like ours which will drop IGMP messages if they are not marked COS=4.

      My 2cents.

      Best regards,

      VA:F [1.9.22_1171]
      Rating: 0.0/5 (0 votes cast)
      • Anthony Sequeira says:


        GREAT STUFF! Thank you so much for your participation in

        VN:F [1.9.22_1171]
        Rating: 0.0/5 (0 votes cast)

    Leave a Reply