Logs are useful all the time and give us the first clue in troubleshooting. Some of them are encountered frequently but others appear just in certain conditions .
Not long time ago one of our customers discovered the log bellow and here is what it turned to be :
Sep 29 2014 08:11:21+02:00 DST core %%01MCAST/3/ENTRY(l):Slot=1/1;Failed to set forwarding table(group ip=188.8.131.52, group mac=, source ip=10.0.100.100, in-VlanID=200) in switch board(SlotID=1). The operation is ADD and the result is 21.
If we check the product documentation we can see that the MCAST ENTRY alarm refers to add/delete chip entry failure, so the next thing to do is to see what were the conditions that favored it.
After a thorough examination of the diagnostic and the logs, we found out that the alarms were generated because a hash conflict occured. Multicast, arp and ipv6 neighbors tables cost the same resource of the chip’s hash bucket.
One ARP entry and one multicast occupies one entry while the ipv6 neighbor occupies two entries in the hash table which means the table is easier reach its limit when we have a big number of IPv6 clients
The board in question supported 8 K ARP entries and after checking the arp and neighbor tables we discovered that at the moment of the problem this limit was reached causing the new multicast entry to not be learnt .
Suggested solutions in this specific case:
1. Since the multicast entry for which the alarm was generated :184.108.40.206 it’s a SSDP packet（Simple Service Discovery Protocol）which is used by the computer for advertisement and discovery of network services and presence information，we could consider to deny these packets on the device or disable the service on the PC.
2. The second suggestion was the obvious one, to replace the board with an enhanced one which has a bigger arp table .