IGMP Snooping

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

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 657 Lessons. More Lessons Added Every Week!
  • Content created by Rene Molenaar (CCIE #41726)

551 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 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

  2. Hello Ananth. I will attempt to answer all of your questions in this single reply.

    1. You wrote: H1 and H2 are still interested so they will respond with a membership report. The switch will intercept these two messages and forwards them to the CPU. One of the two membership reports is then forwarded to the router. In the above statement , only one the membership report is forwarded to the router . Is this a form of report suppression? Also explain why only one report is sent?

    Yes, only one membership report is forwarded to the router, however this one member

    ... Continue reading in our forum

  3. Hello Say Hian

    I will attempt to answer your questions below:

    H1 and H2 are hosts. However, Rene has used routers there to simulate the hosts. This is why he has command line access to them.[quote=“sayhian16, post:28, topic:1321”]
    Does the following commands assign multicast ip address to ports in switch?
    ip igmp snooping vlan (vlan number) stat

    ... Continue reading in our forum

  4. Hi Hussein,

    You can try:

    R1# show mac address-table multicast vlan 1
     vlan   mac address     type    qos             ports
     -----+---------------+--------+---+--------------------------------
       1  0100.5e02.0203  static   --  Gi0/1,Gi0/2,Router
       1  0100.5e00.0127  static   --  Gi0/1,Gi0/2,Router
       1  0100.5e00.0128  static   --  Gi0/1,Gi0/2,Router
       1  0100.5e00.0001  static   --  Gi0/1,Gi0/2,Router,Switch

  5. Hi Hussein,

    You can see the multicast groups with show ip igmp snooping groups but it won’t show the corresponding MAC addresses that are used per group. About your questions:

    You can use this if you expect packet loss on your subnet. It changes the interval for some IGMP messages. The downside of changing this is that you increase the leave latency:

    * Group member interval: this is the am

    ... Continue reading in our forum

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