IGMP snooping on Cat2950 - any known side impact?

[s.yeong]

Hi,

Anyone know if high rate multicast traffic on Cat2950 with default IGMP snooping enabled will cause messages lost?

Read from book that Cat2950 process IGMP snooping at hardware level but will there be possibility the switch can't handle high rate of multicast traffic?

Thanks in advance if you can share your expereince.

[Kevin Dorrell]

Don't confuse the IGMP snooping with the multicast traffic itself.

IGMP is a protocol which is used by a host listening to the multicast, to say "I am listening to the stream 239.42.42.1". These reports are, themselves, multicast, and are flooded throughout the VLAN. The source of the multicast, or the multicast router, sees the report and thinks "Someone is listening, so I had better carry on sending out this multicast stream." The multicast listeners send out these reports only rarely - once every 60 seocnds if I remember right (someone correct me on this?)

So, what does a switch do with these once-a-minute reports? Well, it knows where the report came from by the MAC address, and it knows that the host is listening to the multicast stream. So it sends the stream to the where it sees that MAC address. But it doesn't send the multicast stream to any ports that have not said they are listening. If you don't implement IGMP snooping, the switch will send the multicast out all port regardless.

In answer to your question, the load on the switch in implementing IGMP snooping is minimal. OTOH, if you don't implement IGMP snooping, the load on your hosts, having to listen to everyone else's radio programs, could be enormous. Put it this way, it would turn a multicast switch into a multicast hub

I would advise you to enable it.

Kevin Dorrell

Luxembourg

[s.yeong]

Hi Kevin,

Thanks a lot for your reply.

I do believe the benefit of IGMP snooping to hosts that don't require the multicast traffic.

However, I read from book that IGMP control message itself is multicast packets, indistinguishable from multicast data at Layer 2. Hence, the switch need to examine every multicast data packet for IGMP control information. There's possible severe performance impact to the siwtch if data rate is high but CISCO highlighted that this should not be a problem on newer switches like CAT2950 that process snooping at hardware level.

I would like to believe on above but due to my network start to experiencing multicast traffic lost since using CAT2950 (previously using older CAT2900XL without similar problem - which don't have IGMP snooping and CGMP not enabled as well) I need to study all possible causes.

If there's no similar experience that I can find in this forum, I'll need to simulate above problem in my testbed to find the root cause.

Nevertheless, thanks again for sharing your experience.

Cheers.

[Kevin Dorrell]

I honestly don't think the IGMP is the problem. The IGMP only happens once every few seconds, and in any case the IGMP recognition is done in hardware. I presume what it does is to clock the header into a shift register, and compare fields of the header against a mask, then take action only if they match. So I don't think the problem is to do with the load of processing the IGMP, os much as the IGMP being processed incorrectly.

Is the multicast traffic lost only to those hosts connected through the new 2950, or to other hosts elsewhere on the network? I wonder if the IGMP snooping is doing its job too enthusiastically.

You mention CGMP as well, but can you confirm that it is disabled on the new switch?

I did a search in the bug database for IGMP snooping, and found lots and lots and lots of bugs. Some of them involved IGMP reports not being propagated correctly. Which version are you running so we can narrow it down?

http://www.cisco.com/cgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef96314

When you get multicast loss, do all the hosts on the switch lose the stream at the same time? If so, there is a proably problem propagating the IGMP up towards the host. Do they lose the stream permanently, or do they lose just a couple of packets, or what?

Is you multicast source on the VLAN, or is it coming from a router?

Kevin Dorrell

Luxembourg

[s.yeong]

Hi Kevin,

Following is the network topo:

SenderPC(s)

|

*[CAT2950 SW]

|

[Cisco3725 RTR]

| |

[CAT2900XL SW] [CAT2950 SW]

| |

ReceiverPC(s) ReceiverPC(s)

1) There's no problem initially until more sender PCs are added sending additional multicast traffic to same multicast group. Since I disabled IGMP snooping on *switch, see no more msg lost on path through CAT2900XL SW but traffic through second CAT2950 SW (with IGMP snooping still on) still have msg lost. However, above is based on 3 days observation since disabling IGMP snooping on * switch.

2) CGMP not supported on CAT2950. Confirmed CGMP is disabled on CAT2900XL SW.

3) IOS ver: (C2950-I6Q4L2-M), Version 12.1(13)EA1, IGMP ver 2.

4) Yes, all receivers on the same switch lose the same message at the same time. Lost is random ranging from 1-17 at one time (based on 2 wks observation

[Kevin Dorrell]

OK, I'll have a think about that. In the meantime, here is some goodstuff to read about IGMP snooping:

http://www.cisco.com/en/US/products/hw/switches/ps628/products_configuration_guide_chapter09186a00801cde69.html#1020106

Did you configure the router port manually, or did you let it discover it itself? It might be an idea to hard-code the router port. Something like ip igmp snooping vlan 200 mrouter interface F0/12

Kevin Dorrell

Luxembourg

[marikakis]

I really enjoy this conversation.

I cannot help you, but I am really curious

what other interesting stuff you can possibly say :-)

Best Regards

[Kevin Dorrell]

Just to clarify my last comment: the switch is doing IGMP snooping so that it knows which ports are interested in the multicast group and which are not. It prunes the group from all the ports that are not interested in the group. A host on a port expresses its interest in the group by sending an IGMP report, which makes the switch add the port to the forwarding table for the multicast address.

But there is one (or maybe more) switch port that should never be pruned from any multicast group, and that is the port that leads to the multicast router. You can see which port that is by show ip igmp snooping mrouter [vlan n]. By default, the switch detects its path to the multicast router, in your case the 3750, because the router is sending out PIM packets, which the switch is also snooping.

What I am suggesting is that the switch might be losing track of where the multicast router is. If that is tha case, you can fix it by hardcoding the port. That way all the multicasts will be flooded to the router port all the time, and cannot be pruned by the IGMP snooping.

Kevin Dorrell

Luxembourg

[s.yeong]

Hi Kevin,

Excellent! I also suspect there could be something 'dynamic' that may cause the losses as I encountered with ARP aging causing UDP broadcast packet loss until I fixed the ARP table. As not much experience on multicast, really not sure how to go about it for this case.

Thanks for your 'enlightenment'! I'll try out what you suggested and will keep you posted on the result.

Rgds,

SweeEng

[Kevin Dorrell]

Hi,

Did you make any progress on this case? I would be interested to know the outcome.

Thanks in advance.

Kevin Dorrell

Luxembourg

[s.yeong]

Hi Kevin,

After experimenting different setting, this are my finding:

1) IGMP snooping has no impact on the message loss issue.

2) New finding showed lost at router where interface recorded overrun count (overlook the router as initial investigation reveal no error count on related router)

- we use Cisco 3725, intially using only 2 interfaces but recently added more interfaces totaling to 5 active interfaces (1 in, 4 out).

- All 4 output interfaces connected to LAN with high broadcast traffic

- suspect router's hardware limitation has problem receiving surge of traffic from all interfaces

- shutdown 3 output interfaces and observe no more overrun count and no more message loss

- besides upgrade the router to avoid the overrun problem, any idea if we can block unwanted broadcast to the router interface at switch level?

4) CAT2950 switch experiencing more message loss than CAT2900XL under same environment

- any idea if CAT2950 has more protocol level traffic from the siwtch itself by default (besides IGMP snooping)?

3) CAT2950 switch cannot support direct traffic from more than one subnet, where older CAT2900XL having no problem to support.

- due to limited devices and time, very often we connect 2 different subnets on one switch (without VLAN subnetting) in testbed. No problem seen on CAT2900XL but on CAT2950, a lot of random UDP message loss observed.

I'll further experiment on other setting, hopefully to resolve problem on point (2) above. Will keep you posted on new progress.

Wish you and all readers a safe and happy new year!

Cheers,

SweeEng

Singapore

[rkoegel]

Hi !

Referring to your network-design - any chance to work on your problem-switch with 'static' / PERMANENT is the key.. - entries ?

After several problems - even with Cisco 29XX as working as NON-RFC compliant due to Multicast - we decided to use static entries !

Also happy new year !

Regards,

Ralf

[s.yeong]

Hi Ralf,

Sorry for late reply... was moved on to another proj.

FYI, tried on what you suggested but problem still persist with CAT2950 - only in testbed though where there's traffic via TAP (although no problem on 2900XL switch). Since the switch works fine at least in production now, I stopped the investigation on CAT2950.

Kelvin,

FYI, I workaround the message loss issue caused by router's overrun by spreading the port usage to different slot i.e. used only one port per slot ( althought there're 2 ports per slot). This seems solved the problem for now.

Best Regards,

SweeEng