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

[Benjamin Lovell]

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/