IGMP Snooping

stephendrkw · ‎11-25-2015

I have a 6509 switch with "no ip igmp snooping" enabled. I would like to take this command off, the switch is dropping multicast packets periodically (not sure why this command was applied in the past, looks a testing scenario)

When I enable this command "ip igmp snooping", will all the current multicast traffic be disruptive in anyway and for how long -IGMP timers?. Would this this be a short ms or long s disruptive time.

I'm trying to figure out how long this global command would take to start to learn and build its forwarding table of interested multicast listeners on the VLAN who are sending IGMP joins to build the Vlan multicast forwarding table with the specific ports in each Vlan. I have some sensitive multicast traffic where I need to inform application teams of how long multicast packets will be missed for, its a 24x7 operational switch mostly (trading financial). latency sensitive! !

Jean-Francois Dube · ‎11-25-2015

Greetings,

I'm not clear on what your goal is with regards to IGMP snooping.

By default IGMP snooping is enabled globally.

I'll assume you see no ip igmp snooping in the running-config. (Try: show run | i snooping)

If IGMP snooping is disable then enabling it should not cause any outage.

I have not tried this on a 6500 but my reasoning is that the router should do one of two things:

1- After ip igmp snooping is configured the router keeps flooding for up to 60 seconds until it learns of interested listener by usual IGMP query/report mecanism.

2- After ip igmp snooping is configured the router sends a membership query right away to learn of interested listener and starts pruning traffic from other ports.

In both cases, I don't think you'll have an outage or any problems with actual forwarding of multicast traffic.

Do you have access to a lab?

You could connect a host running VLC on a port or use ip igmp join-group on the interface. Then debug ip igmp to see the membership reports from that interface. The default timer for IGMP queries is 60 seconds. Wait for a new 60-second cycle of query followed by report from the interface and then configure "ip igmp snooping" on the lab router. With the debugs still enabled you'll see if the IGMP querier sends another membership query or keeps waiting for the 60-second timer to expire. Also run show ip igmp snooping groups right after configuring snooping to see when the learning occurs

Good luck!

JF

Julio Garcia · ‎11-26-2015

Hi,

just some additional information:

1. If you are routing multicast, meaning that you have PIM enabled in your vlan interface, that interface would act as the IGMP querier, and everything should be fine. IGMP snooping will see the answers from queries sent by the vlan interface and act accordingly. You can always check if there is an active querier after enabling snooping with the command:

show ip igmp interface vlan XXX | include querying (in 12.2SX)

or

show ip igmp snooping querier vlan XXX (in 12.2SY and above)

2. If you are not routing multicast and you only run multicast in that specific vlan, enabling IGMP snooping without the querier enabled could lead to the multicast not being sent to some ports. The receivers may only sent a membership report/IGMP Join when they originally want to subscribe to the group, but not again, so in this case IGMP snooping will stop forwarding the multicast traffic towards that port after the query timeout. To avoid this, you must enable the IGMP querier in your vlan. Depending on the version you are running it must be enabled in the vlan interface or in the vlan configuration.

For 12.2SX : http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/snooigmp.html#wp1122174

For 12.2SY and 15.1SY : http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/15-1SY/config_guide/sup720/15_1_sy_swcg_720/ipv4_igmp_snooping.html#wp1123116

3. The command "ip igmp join-group" forces the switch/router to act as a member of the specified multicast group, and the packets will be sent to the CPU to be processed. The command "ip igmp static-group" will just force the traffic to be fast-switched towards the interface. Generally speaking the latter is preferred in terms of CPU usage (please refer to https://supportforums.cisco.com/discussion/10359081/igmp-join-group-vs-static-group)

Regards,

Julio

stephendrkw · ‎12-21-2015

I enabled "igmp snooping" on our 6509 expecting possible lost multicast packets with IGMP timers (from anything 1-60 seconds) and also the delays in sending the IGMP messages to the interested ports. In the end, we had no falllout from from our trading application teams which I must say is remarkable. They scream when any multicast is lost!!!! I was thinking of running debug ip igmp during the change but decided it the last moment not to, with the sensitivity in these productions switches the risk was too high.