IGMP Snooping

prince20020 · July 19, 2019, 3:11pm

Hi Rene,

I would like to know the difference between igmp snooping and igmp snooping proxy.

What is use of using igmp proxy instead of igmp snooping?

lagapidis · July 22, 2019, 6:27am

Hello Chandan

IGMP snooping and IGMP snooping proxy perform the same functions. The difference is in how it is implemented.

With plain IGMP snooping, all the hosts send their complete membership information to the router in response to queries. The switch receives these responses, updates the database and forwards the reports to the router.

In a network with many hosts, this process may overwhelm the router with reports. When IGMP snooping proxy is enabled, the switch forwards only the first report for a channel to the router and suppresses all other reports for the same channel, thus reducing the number of reports that the router receives. In a sense, it filters out the packets that provide duplicate information to the router, thus delivering only necessary information to the router.

Take a look at page 27-6 in the following Cisco documentation for more details.

I hope this has been helpful!

Laz

ronaldcheng14 · August 21, 2019, 8:57am

On most multi-layer switches I’ve seen, IGMP snooping is enabled by default. In a scenario where you have PIM sparse-mode, and default IGMP snooping enabled, would the multi-layer switch overrule the membership report suppression mechanism, when multiple hosts are connected.

Or would functionality be more along the lines of what is described in the Multicast IGMP version 2 Lesson? My confusion lies when both PIM and IGMP snooping both enabled.

lagapidis · August 22, 2019, 5:48am

Hello Ronald

Imagine that a L3 switch is internally separated into its two components, a router and an L2 switch. If you have multiple VLANs, then you can assume that each VLAN functions as a separate physical switch. By doing this mind exercise, it becomes clearer as to how IGMP snooping and PIM are separated within the logic of the switch. IGMP snooping would occur within each VLAN (or the logically separated switch we imagined) while the PIM mechanisms would occur in the imagined router portion of the device.

A good exercise would also be to view the diagrams in this lesson as single entities (where the switch and router belong to the same device, where the router is actually the SVI of the VLAN in question, and the switch is the sum of all ports on the same VLAN).

So even in a single device, the operation of IGMP snooping and PIM will still be discrete and separate, and would follow the same rules/guidelines laid out in this lesson.

I hope this has been helpful!

Laz

sims · February 12, 2020, 3:13pm

Hi,
You said “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?”

How we can see this CAM table in the switch I mean multicast only

Thanks

lagapidis · February 13, 2020, 8:36am

Hello Sims

You can view the multicast entries of the CAM table using the following command:

SW1#show mac address-table multicast

I hope this has been helpful!

Laz

ronaldcheng14 · April 5, 2020, 6:42am

As Andrew as mentioned above,

Group-Specific Query (GSQ)

Not available in IGMP version 1

Event-based (when an IGMP Leave Request is received)

Group address queried can be targeted to a specific multicast group (not all groups)

Default maximum response time = 1 second

The lesson however indicates that an IGMP General Query is sent by the IGMP Querier is response to an IGMP Leave by hosts.

lagapidis · April 6, 2020, 5:36am

Hello Ronald

Both the lesson, as well as Andrew’s comments are correct. Andrew states that GSQ is:

This means that it will send out a GSQ whenever a leave request is received.

The lesson states the same thing, that:

You can verify this by looking at RFC 2236 which states:

When a Querier receives a Leave Group message for a group that has
group members on the reception interface, it sends [Last Member Query
Count] Group-Specific Queries every [Last Member Query Interval] to
the group being left.

If I have misunderstood your question, please let me know so I can further clarify.

I hope this has been helpful!

Laz

philtylr · April 6, 2020, 11:31am

Hi Rene/Laz
In the IGMP group leave section, when H1 sends its leave group message to multicast group 224.0.0.2 using destination MAC address 0100.5e00.0002, is that saying it wants to leave ALL multicast groups or does the leave group message specify which group? I’m just thinking of a scenario where a host is listening to more than one multicast group at the same time, if that is possible.

Thanks in advance,
Phil.

lagapidis · April 6, 2020, 1:28pm

Hello Philip

When a host like H1 sends a leave group message, it will always specify which group it wants to leave. Within the IGMP Group Leave message, there is a field that specifies the specific group. This is important for the reason that you mentioned: because some hosts may be receving multicast traffic from multiple groups.

In the following lesson, you can see some Wireshark captures of IGMP leave group messages where the specific group from which they are leaving is indicated within the IGMP section of the message.

An example can be seen below:

Notice that it is a Leave Group type, and the specific multicast address group of 239.1.1.1 is specified.

I hope this has been helpful!

Laz

bikram.na · April 20, 2020, 3:19am

Hi Laz,

Regarding , can we see this in debug or packet capture how the switch is forwarding the membership report to a router for all the ports.

Yes, only one membership report is forwarded to the router, however this one membership report includes all of the interfaces that want to take part in the multicast group. This is not a form of membership report suppression, because as mentioned in the lesson:

lagapidis · April 22, 2020, 8:04am

Hello Bikram

What I mentioned in that post can be somewhat misleading. Let me clarify what I meant. The membership report itself does not actually contain a list of the switch’s interfaces that want to take part in the multicast group, as this information is useless to the router… So even if we do a wireshark capture, you won’t see anything special in such a response.

The purpose of these mechanisms is for the switch to maintain multicast groups. These groups are maintained within the switch’s CAM table, where particular multicast MAC addresses correspond with specific ports of the switch. These CAM table entries are updated using, among other things, leave messages. But what if you don’t have leave messages?

The solution is to use the periodic general query message that a router will send out to maintain the CAM table. This query will reach all hosts. The response of the hosts will allow a switch to update the multicast entries of the CAM table simply by determining which hosts respond. It records on which ports it received a response, and on which it didn’t, and updates the CAM table accordingly.

The switch however, will not forward all of these responses to the router, but only a single one, which is enough to simply tell the router “keep sending this multicast traffic from your interface”.

I hope this has been helpful!

Laz

jallen314 · July 16, 2020, 9:49pm

The switch will forward any igmp traffic to 0100.5exx.xxxx to the internal interface. in the example in this lesson, 0100.5e01.0101 was forwarded out gi0/1 and gi0/4. wouldn’t the first multicast entry cover all traffic thereby throwing all multicast traffic at the internal interface? Or is there a longest match rule for multicast as well?

lagapidis · July 17, 2020, 12:53pm

Hello Justin

What you state makes perfect sense when comparing the MAC address table with the routing table or even more with access lists or route maps. These entities are searched sequentially and when there is a match, the search stops, and action is taken.

However, the MAC address table operates differently, and this has to do with the type of memory in which it is stored. Content Addressable Memory (CAM) is type of memory where the MAC address table is stored, and it is also why it is often referred to as the CAM table. Where the previously mentioned entities are searched sequentially line by line, and each line corresponds to a single cycle of the CPU, the CAM table is searched in full in only a single CPU cycle. This is what makes switching so fast. The other characteristic of the CAM table, that actually answers your question, is that it only makes an exact match. Only when there is no exact match will it match with the general multicast address group used for IGMP. You can find out more about CAM as well as TCAM memory in the following post:

I hope this has been helpful!

Laz

mrtrialshot · July 31, 2020, 5:44am

Hello Laz,

I hope everything is well with you.

In my topology, do Layer 3 switches can be a IGMP “snooper” instead of a querier? This is the topology on my GNS3 the same as the topic shown here.

This is configured on R10

ip multicast-routing
interface FastEthernet0/0
 ip address 192.168.1.254 255.255.255.0
 ip pim sparse-mode
 ip igmp join-group 239.1.1.1
 duplex auto
 speed auto

Debug result on R10:

On “Layer2Switch” I’ve tried debug ip igmp snooping but it wasn’t able to debug anything as it could be acting as a querier instead of a “snooper”.

As also captured on Wireshark, R10 is sending PIM and IGMP data to the multicast but the switch is not sending anything back.

All ports on the switch is on VLAN 1. And snooping is enabled as per this screenshot:

It was only able to debug something when I typed on the switch

interface Vlan1
 ip address 192.168.1.10 255.255.255.0
 ip pim sparse-mode

but this isn’t the result I should be seeing because when I typed the show commands for igmp snooping

The IP address querier is the switch itself (192.168.1.10) not R10 (192.168.1.254).

Just to add, the image I am using for the switch is vIOS-L2. I’ve also tried no ip routing on the switch but to no avail. Maybe it is an image problem because it is not actually a Layer 2 but a Layer 3 image. Apologies if this post is long. Thank you

lagapidis · August 3, 2020, 6:56am

Hello Alvis

Looking over your explanation and your configurations, I don’t find any reason for the switch to be behaving like this. L3 switches are capable of IGMP snooping, and by confirming that it is enabled, and even that IP routing was disabled, you essentially made the switch an L2 switch.

My suggestion would be to get your hands on a pure L2 image and try it out. In the meantime, I have been looking at some threads online about GNS3 and IGMP snooping, and I have read that even as recent as 6 months ago, people have been having trouble with IGMP snooping on GNS3, where commands seem to exist, but they are not supported and don’t behave as expected (similar to your situation). I have been unable to find definitive answers to this, however.

I hope this has been helpful!

Laz

mrtrialshot · August 3, 2020, 7:06am

Thanks for checking, Laz.

henglyhom.tk · November 23, 2020, 9:31am

Hi !
By default igmp snooping is enable that mean it enable on all vlan that was created on switch. Is there any way to enable igmp snooping on specific vlan instead ?

Regard.

lagapidis · November 25, 2020, 7:29am

Hello Hengly

It is possible to enable IGMP snooping on a particular VLAN. In order to do so, you can use the following command:

SW1(config)#ip igmp snooping vlan 10

But remember that IGMP snooping is enabled by default, so you will have to first disable IGMP snooping globally, and then enable it on the VLANs of your choice.

I hope this has been helpful!

Laz

henglyhom.tk · November 26, 2020, 1:44am

Hi Laz,
I follow you instruction to disable igmp snooping in global and enable on specific vlan instead. When i did that my multicast vlan can not learn mrouter port. Can you explain that issue ? is there any more step to configure it ?

Thank.
Hengly