Unable to Add IPmc sender : Entry exists

  • 0
  • 1
  • Problem
  • Updated 3 years ago
  • Solved
  • (Edited)
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://gtacknowledge.extremenetworks.com/articles/Solution/Cache-entries-for-local-multicast-group-...

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.
Photo of Fauriant Tristan

Fauriant Tristan

  • 384 Points 250 badge 2x thumb

Posted 3 years ago

  • 0
  • 1
Photo of Paul Russo

Paul Russo, Alum

  • 9,694 Points 5k badge 2x thumb
Hello Tristan

Not necessarily.  Even though the build of code is newer than 15.5.2 the fix may not be in there.  It all depends on if the fix was able to make it into that build of code.

Some things to check 1) the release notes of the build of code.  look for the CR xos0057375 issues as being resolved, 2) load one of the versions of code that is listed in the knowledge base article or 3) call GTAC and verify.

Hope that helps
P
Photo of EtherMan

EtherMan

  • 426 Points 250 badge 2x thumb
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...   
Photo of OscarK

OscarK, ESE

  • 7,702 Points 5k badge 2x thumb
I think this article might be applicable.
https://gtacknowledge.extremenetworks.com/articles/Solution/Unable-to-Add-L2

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

Fauriant Tristan

  • 384 Points 250 badge 2x thumb
Thanks all for your responses, I will test the configuration of ipmc lookup key to group/vlan and I'll send you a feedback.
Photo of Fauriant Tristan

Fauriant Tristan

  • 384 Points 250 badge 2x thumb
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.
(Edited)