IGMP Snooping

When there are multiple receivers on the network then using multicast traffic is a good idea. It’s more efficient than unicast since we only have to send our traffic once, this saves us precious bandwidth. It’s also more efficient than broadcast because only receivers that are actually interested in our traffic will receive the traffic.

Routers use PIM (Protocol Independent Multicast) to figure out where to forward multicast traffic but what about switches?

Layer two switches are simple devices. They learn source MAC addresses and insert these in their MAC address tables. When a frame arrives, they check for the destination MAC address, perform a lookup in the MAC address table and then forward the frame. This works very well for unicast traffic but it’s a problem for multicast traffic. Take a look at the example below:

multicast traffic flooded

Above we have a video server that is streaming multicast traffic to destination 239.1.1.1,  the destination MAC address will be 0100.5e01.0101. When the switch receives this traffic then it will do a lookup for MAC address 0100.5e01.0101. Since this MAC address has never been used as a source, all multicast traffic will be flooded. All hosts will receive our traffic whether they want it or not.

IGMP snooping allows us to constrain our multicast traffic. As the name implies, this is done by listening to IGMP traffic between the router and hosts:

  • When the host sends a membership report for a multicast group then the switch adds an entry in the CAM table for the interface that is connected to the host.
  • When the host sends a leave group for a multicast group then the switch removes an entry in the CAM table for the interface that is connected to the host.

This sounds simple but there is more to this story.

What do we do when we use IGMP version 1? Our hosts will not send any leave group messages so there’s nothing to snoop. How do we deal with the video server that never joins any multicast groups but only streams traffic to it?

To answer these questions we’ll have to take a closer look at IGMP snooping.

IGMP snooping without L3 aware ASICs

We will start with a simple example. I’ll use the following diagram for this:

Multicast IGMP Snooping Topology

Above we have a multicast enabled router, a switch and three host devices. Our switch has a CPU and a CAM table (mac address table) which is connected to an internal interface that I will call “INT”. We are using a cheap budget switch that is only able to look at layer two Ethernet frames. It does have support for IGMP snooping though. Let’s see what happens when we enable IGMP snooping on this switch:

multicast igmp snooping membership report flooded

Above you can see that one of our hosts (H1) sends a membership report for multicast group 239.1.1.1 that it wants to join. Our switch has no idea where to forward this to so the first time it will flood it on all interfaces, including the internal interface to the CPU. The CPU will take a closer look at the membership report and will create an entry in the CAM table:

multicast igmp snooping cam table one entry

In the CAM table above you can see an entry for MAC address 0100.5e01.0101 which corresponds with multicast group 239.1.1.1. The interfaces that were added are for H1, R1 and the internal interface. Why did the switch add the interface of the router in the CAM table?

Once IGMP snooping is enabled, the switch will detect multicast enabled routers and it does so by listening to the following messages:

  • IGMP General Query (0100.5e00.0001)
  • OSPF (0100.5e00.0005 and 0100.5e00.0006)
  • PIM version 1 and HSRP (0100.5e00.0006)
  • PIM version 2 (0100.5e00.000d)
  • DVMRP (0100.5e00.0004)

When the switch detects a multicast enabled router then it will add the corresponding entry in the CAM table.

From now on, all multicast traffic that has destination MAC address 0100.5e01.0101 will only be forwarded on interface Gi0/1, Gi0/4 and the internal interface to the CPU.

It sounds like we did a good job constraining our multicast traffic but we still have one problem. Here’s what happens when one of our devices starts streaming multicast traffic:

multicast igmp snooping cpu overload

In the example above we see that R1 is sending 10 Mbps of multicast traffic which is forwarded to H1 and the CPU. Our CPU is unable to process 10 Mbps of traffic so it will choke on it…when this occurs, there’s a couple of things that could occur:

  • The switch will start dropping unicast and multicast traffic.
  • The CPU might be able to drop exceeding multicast traffic but that could also include IGMP membership reports and IGMP group leave messages.

The issue above is common with cheap switches that support IGMP snooping. It might work with low bandwidth multicast traffic but that’s about it.

IGMP snooping with L3 aware ASICs

To fix this issue, we need switches with special ASICs that are able to look into the frame and differentiate between IGMP and non-IGMP multicast traffic. Here’s what that would look like:

multicast igmp snooping l3 asic aware

Above you can see the changes that were made to the CAM table:

  • The first entry tells the switch to forward all IGMP traffic with destination 0100.5exx.xxx to the internal interface. This allows the CPU to look at the different IGMP messages.
  • The second entry tells the switch to forward all non-IGMP traffic with destination 0100.5e01.0101 (group 239.1.1.1) to interface Gi0/1 and Gi0/4.

The switch will now intercept all IGMP messages, they are only sent to the internal interface which puts our switch in total control of all IGMP traffic.

IGMP Group Leave

Let’s continue the story, let’s say that H1 and H2 are listening to multicast group 239.1.1.1. Suddenly, H1 is no longer interested so it will send a leave group message:

multicast igmp snooping igmp leave group

Leave group messages are always sent to multicast group 224.0.0.2 using destination MAC address 0100.5e00.0002. When the switch receives the IGMP leave, it will forward it on the internal interface to the CPU.

In response, the switch will send an IGMP general query on the interface that connects to H1:

multicast igmp snooping general query

The IGMP general query is only sent on the Gi0/1 interface and we do this to check if there are any other hosts that are interested in multicast group 239.1.1.1 on this interface. There are two possible outcomes:

  • If another host was connected to the Gi0/1 interface which was still interested in receiving traffic for 239.1.1.1 then the switch would just get rid of the group leave message, nothing will change.
  • When the switch doesn’t receive a membership report then the CPU will remove the Gi0/1 interface from the CAM table. Since we still have a second listener (H2), the switch will not forward the leave group message to the router.

Here’s what the CAM table looks like now:

multicast igmp snooping interface removed

Above you can see that interface Gi0/1 has been removed from the CAM table. No messages have been forwarded to the router.

A few minutes later, H2 decides that it also wants to leave multicast group 239.1.1.1 so it will send an IGMP leave group message:

multicast imp snooping igmp leave group host 2

Above you can see the switch receives the IGMP leave group from H2 which is forwarded to the CPU. Here’s what happens next:

We're Sorry, Full Content Access is for Members Only...

If you like to keep on reading, Become a Member Now! Here is why:

  • Learn any CCNA, CCNP and CCIE R&S Topic. Explained As Simple As Possible.
  • Try for Just $1. The Best Dollar You’ve Ever Spent on Your Cisco Career!
  • Full Access to our 798 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

539 Sign Ups in the last 30 days

satisfaction-guaranteed
100% Satisfaction Guaranteed!
You may cancel your monthly membership at any time.
No Questions Asked!

Tags: ,


Forum Replies

  1. Hi,

    Why do we need a router ? . If I have only a switch , how does it work

    Thank you

  2. Hi Sims,

    The router is there since normally hosts use IGMP to indicate that they are interested in receiving a certain multicast group. Routers listen to these messages and forward multicast traffic is required.

    If the switch doesn’t have a routed port then it will drop all incoming IGMP membership reports from hosts. If you don’t want this, then you should disable IGMP snooping.

    There is once exception though. (Routing) protocols that use the 224.0.0.x range also don’t use IGMP when they want to receive multicast traffic. Examples are protocols like RIP, EIGRP

    ... Continue reading in our forum

  3. hi thank you for your good article

    as i look this section, i have a question

    what is l3-aware switch ? for example cat 3750 3850 etc.

    please tell me what platform is l3-aware…

    thanks

  4. Hi Mungi,

    Cheap switches (anything you can buy new for 20-30 USD) are only designed to learn MAC addresses, build a MAC address table and forward Ethernet frames based on the destination MAC address. That’s it.

    These switches are unable to look into the content of an Ethernet frame to check the payload.

    A layer 3 “aware” switch is able to look into the payload and make decisions based on the content, like the IGMP snooping example.

    Don’t confuse this with “L3 switches”. There’s a difference between a L3 switch and a L3 “aware” switch. For example, the Cisco cat

    ... Continue reading in our forum

  5. hi thank you for your reply

    i have another question about igmp report message from host

    If another host was connected to the Gi0/1 interface which was still interested in receiving traffic for 239.1.1.1 then the switch would just get rid of the group leave message, nothing will change. <- it’s your decription, how do the switch know whether host want to receive multicast or not

    in this case, host send igmp member report message for switch’s query?

    always thanks your good lessons

94 more replies! Ask a question or join the discussion by visiting our Community Forum