[c-nsp] 6500 IGMP snooping database now bound to MAC address and not switchport?

[Sam Stickland]

Hi Ben,

We aren't using port-channels towards the servers. However, I've just seen another issue on a 3560 where IGMP joins/reports aren't replicated to the SPAN session. This has got me wondering if the server was reissuing the join all along but I simply failed to capture it.

Sam

On 9 Feb 2011, at 18:34, Benjamin Lovell <belovell at cisco.com> wrote:

> Just taking a shot here but I don't think it's quite that if you have port-channel configured on the switch side for the server link because the hardware programing is not based on the receiver MAC it's based on the mcast MAC. The MAC table will program a snooping entry for the mcast MAC to replicate out that interface. What could have changed is the on the switch side if you have a port channel configured then the mcast MAC entry is getting moved over to the other link w/o a new IGMP membership report coming in, which we really should have been doing all along. 
> 
> -Ben
> 
> 
> On Feb 9, 2011, at 11:57 AM, Sam Stickland wrote:
> 
>> All,
>> 
>> I encountered some strange, but beneficial, behaviour in the lab. We connected a server with teamed NICs to two 6500s running SXH2a. The NIC teaming is active/standby using only a single MAC and IP address. The server joins a multicast group and starts receiving traffic. We found that if we pull the primary NIC everything, including the multicast traffic, fails over to the standby NIC, losing a couple of packets at most.
>> 
>> The strange thing is that packet captures don't show the server re-issuing the IGMP join or sending any membership reports on the standby NIC. In the past this would had resulted in a loss of multicast traffic until the IGMP state is rebuilt on the new switch port. But no longer.
>> 
>> My guess is that the IGMP snooping mechanism is now recording the MAC address of the reporter and updating the snooping tables when the MAC address moves.
>> 
>> But I can't find this documented anywhere, so I'd hate to rely on this behaviour.
>> 
>> Has anyone else heard of this?
>> 
>> Regards,
>> 
>> Sam
>> _______________________________________________
>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>