igmp snooping non working on C2950T w some traffic

napTuZane · ‎09-10-2010

Someone can help me?

igmp snooping work fine with next packet flow:

(traffic from vlc media )

# tcpdump -vvvi rl1 dst 238.238.0.8
tcpdump: listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes
11:54:05.732013 IP (tos 0x0, ttl 1, id 50863, offset 0, flags [none], proto UDP (17), length 1344)
    192.168.11.11.4230 > 238.238.0.8.1234: UDP, length 1316
11:54:05.732133 IP (tos 0x0, ttl 1, id 50864, offset 0, flags [none], proto UDP (17), length 1344)
    192.168.11.11.4230 > 238.238.0.8.1234: UDP, length 1316
11:54:05.732247 IP (tos 0x0, ttl 1, id 50865, offset 0, flags [none], proto UDP (17), length 1344)
    192.168.11.11.4230 > 238.238.0.8.1234: UDP, length 1316

but with next packet flow, igmp snooping not work and send all packets as broadcast to all ports of C2950T switch:

(traffic from freebsd router with igmpproxy software)

# tcpdump -vvvi rl1 dst net 238.0.0.0/8
tcpdump: listening on rl1, link-type EN10MB (Ethernet), capture size 96 bytes
12:16:30.753532 IP (tos 0xe0, ttl 62, id 0, offset 0, flags [DF], proto UDP (17), length 1344)
    10.10.10.1.49152 > 238.0.0.9.1234: [no cksum] UDP, length 1316
12:16:30.755559 IP (tos 0xe0, ttl 62, id 0, offset 0, flags [DF], proto UDP (17), length 1344)
    10.10.10.1.49152 > 238.0.0.9.1234: [no cksum] UDP, length 1316

    ## from provider
15:47:17.978718 IP (tos 0xe0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 1344)
    10.10.10.1.49152 > 238.0.0.9.1234: [no cksum] UDP, length 1316
15:47:17.980816 IP (tos 0xe0, ttl 63, id 0, offset 0, flags [DF], proto UDP (17), length 1344)
    10.10.10.1.49152 > 238.0.0.9.1234: [no cksum] UDP, length 1316

igmp status on switch:

===========
Switch#show ip igmp sno group
Vlan      Group          Version     Port List
---------------------------------------------------------
1         238.0.0.9      v2          Fa0/12
1         224.0.1.60     v2          Fa0/14
1         239.192.152.143v2          Fa0/6, Fa0/8, Fa0/9, Fa0/13, Fa0/14, Fa0/16, Fa0/17, Fa0/19, Fa0/20, Fa0/21, Fa0/22,
                                     Fa0/23,
                                     Fa0/24,
                                     Gi0/1
1         233.89.188.1   v2          Fa0/20, Fa0/24
1         239.255.67.250 v2          Fa0/14
1         239.255.255.250v2          Fa0/6, Fa0/8, Fa0/9, Fa0/12, Fa0/13, Fa0/14, Fa0/16, Fa0/17, Fa0/19, Fa0/20, Fa0/21,
=========
Switch#show ip igmp sno querier
Vlan      IP Address     IGMP Version        Port
---------------------------------------------------
1         192.168.6.121 v2                  Gi0/1
==========
Switch#show ip igmp sno mrouter
Vlan    ports
----    -----
   1    Gi0/1(dynamic)

===============

how can I use igmp snooping in this situation?

Peter Paluch · ‎09-13-2010

Hello,

The problem is caused by an unfortunate selection of the multicast group IP address 238.0.0.9. Let me explain some basics first.

You are probably aware that the multicast IP address range 224.0.0.0/24 is called the link-local multicast. In this range, many applications are running, among others OSPF, EIGRP, RIPv2, PIM, HSRP, VRRP, GLBP, and others. Neither of these applications subscribes in these groups, however. For example, you will never see an EIGRP router sending an IGMP join message to the 224.0.0.10 group where all multicast EIGRP packets are delivered.

Because of this reason (no IGMP joins are commonly sent for applications in the link-local multicast scope), Cisco Catalyst switches cannot perform IGMP snooping for these groups because there would be no IGMP messages received/sent. Instead, these switches flood all frames whose destination MAC address corresponds to the appropriate multicast IP address within the link-local scope, which is the range from 01:00:5e:00:00:00 up to 01:00:5e:00:00:FF (the first 25 bits are set to 01:00:5e:0, the last 23 bits are directly copied from the lowest 23 bits of the multicast IP address; the remaining bits from the IP address are lost during this mapping from IP to MAC). For the link-local multicast IP address range, the IGMP Snooping is ignored.

Now, notice that the multicast IP address 238.0.0.9 maps to the MAC address 01:00:5E:00:00:09 - just the same MAC address as would be used by a RIPv2 router using the link-local multicast IP address 224.0.0.9. For a Catalyst switch, this is indistinguishable from a frame containing a real link-local multicast IP packet. As a result, this frame will be flooded all ports in the same VLAN which is exactly the phenomenon you are experiencing.

As a matter of rule, all addresses in the form

224.0.0.X

224.128.0.X

225.0.0.X

225.128.0.X

...

239.0.0.X

239.128.0.X

will map to the very same MAC address 01:00:5E:00:00:Hex(X) and will be treated as link-local multicasts - they will be flooded all ports, disregarding the IGMP Snooping completely. This has to be taken into consideration by the network administrator that is responsible for planning the multicast addressing plan so that these IP addresses are not used for multicast applications because IGMP Snooping does not apply to them.

Best regards,

Peter