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

[Benjamin Lovell]

mcast packets are kinda tricky when it comes to SPAN and there are various platform caveats. If I remember right some 3K series just wont show them as they are punted to CPU before SPAN happens. 6500 can't get mcast on TX SPAN when doing egress replication, etc. If you don't use port channel towards the server then I can't see how it forwards down the new link w/o a new join as knowledge of the receiver unicast MAC doesn't come into play when forwarding mcast at L2. It's all based on IGMP snooping programing the mcast DMAC to a logical or physical port.

Phil's suggestion to do a "debug ip igmp <group>" seems best to get more info. 

-Ben

On Feb 9, 2011, at 2:05 PM, Sam Stickland wrote:

> 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/
>>