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:

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:

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:

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:

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:

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:

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:

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:

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:

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:

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