Unable to Add IPmc sender : Entry exists

[Fauriant_Trista]

Hello all!

I've some trouble on a x460 compound stack (L2 only, 2 * x460 -24p with XGM3-2SF and SummitStack necessarily), since a while this error appears in the log:

07/27/2015 06:26:58.95 Slot-1: Unable to Add IPmc sender entry s,G,v=10.92.XX.X2,224.0.0.18,2259 IPMC 1 flags 4 unit 0, Entry exists
07/27/2015 06:25:32.94 Slot-1: Unable to Add IPmc sender entry s,G,v=10.92.XX.X2,224.0.0.18,2259 IPMC 1 flags 4 unit 0, Entry exists
07/27/2015 06:24:05.92 Slot-1: Unable to Add IPmc sender entry s,G,v=10.92.XX.X2,224.0.0.18,2259 IPMC 2 flags 4 unit 0, Entry exists

This stack is linked to two x670 in MLAG mode, the two x670 are sharing the 10.92.XX.X1 LAN for VRRP nexthop, their respective addresses are 10.92.XX.X2 et 10.92.XX.X3. The stack is not involved in the VRRP exchange.

I searched in the GTAC knowledge base and I found the following issue : https://extremeportal.force.com/ExtrArticleDetail?an=000075055

A reboot can solve the problem, for a while...

My stack is in 15.5.3.4 p1-2 version (as my x670) and it seems that the correction has been placed in the 15.5.2 so i supposed that 15.5.3.4 p1-2 inherited of this correction, right ?

Somebody has encountered the same issue or solved this ?

Thanks in advance,
Tristan.

[Fauriant_Trista]

A reload has been made of the stack and all seems ok now (without making modification of the ipmc lookup-key)

I'll check this problem during the next weeks and give you a status.

Thanks for your support.

[Fauriant_Trista]

Thanks all for your responses, I will test the configuration of ipmc lookup key to group/vlan and I'll send you a feedback.

[OscarK]

I think this article might be applicable.
https://extremeportal.force.com/ExtrArticleDetail?an=000077156

Most times changing the ipmc lookup key to group/vlan does create a lot more room for storing multicast entries.

[EtherMan-Dupe]

Tristan trick here from our experience is this a real problem or maybe software not keeping up with entries in tables. Mcast groups tables are small for today's networks in my opinion where you have many more things other than routers chirping and using mcast. We see this all the time in our core where we have a few hundred vlans on common switches ..... Pretty much all product lines 8900 with MSM128 and all XL blades .. summit 460, 480, 670 as they all have very similar mcast support and tables. We as a rule keep igmp snooping disabled in those switches with the exception of our IPTV delivery vlans. We do not seem to have problems with services passing through these switches even though the warnings continue to show up in logs.... If you are seeing or suspect you are dropping any
mcast services through this stack then reach out to TAC ... They can do a debug session with you to look at actual tables to make sure mcast resources are not filling up and this can be safely ignored...