12-29-2014 07:25 AM - edited 03-07-2019 10:02 PM
Since upgrading to version 6.2(8b) on our core Nexus 7ks I'm seeing the following errors:
2014 Dec 29 08:09:22 DC7K-ADMIN_VDC %L2MCAST-SLOT2-2-L2MCAST_MAC_FULL_LC: Failed to insert entry in MAC table for FE 0 swidx 268 (0x
10c) with err (mac table full). To avoid possible multicast traffic loss, disable OMF. Use the configuration CLI: "no ip igmp snoopi
ng optimise-multicast-flood"
When this is reported to syslog, I have an alert that fires a SecureCRT script to log into the switch that reported the alert and then log to a text file how many MAC addresses it currently "sees". The number of MAC addresses normally sits around 12k, no where near the 16384 limit.
Anyone else seen this message?
module-1# show hardware internal forwarding f2 l2 table utilization instance all
L2 Forwarding Resources
-------------------------
L2 entries: Module inst total used mcast ucast lines lines_full
------------------------------------------------------------------------------
1 0 16384 12368 281 12087 512 4
1 1 16384 8862 1 8861 512 0
1 2 16384 12384 282 12102 512 1
1 3 16384 8857 8 8849 512 0
1 4 16384 8997 9 8988 512 0
1 5 16384 8861 1 8860 512 0
1 6 16384 8847 0 8847 512 0
1 7 16384 558 0 558 512 0
1 8 16384 558 0 558 512 0
1 9 16384 558 0 558 512 0
1 10 16384 558 0 558 512 0
1 11 16384 8849 0 8849 512 0
12-29-2014 05:37 PM
%L2MCAST-SLOT3-2-L2MCAST_MAC_FULL_LC: Failed to insert entry in MAC table for FE 7 swidx 19 (0x13) with err (mac table full). To avoid possible multicast traffic loss, disable OMF. Use the configuration CLI: "no ip igmp snooping optimise-multicast-flood"
Such messages mean that the mac address entry was not installed into the MAC table due to a hash function that is used to optimize the MAC table usage.As a consequence, the multicast traffic will be dropped when IGMP snooping is enabled. If you disable IGMP snopping, the traffic will be flooded.
You can check current resources on the card with this command:
attach module 1
show hardware internal forwarding l2 table utilization instance all
The max L2 entries(MAC address) per ASIC/Instance in the F2 module is 16K, there are totally 12 ASIC/Instance per F2 module (each ASIC controls 4 ports, for example instance 0 controls port 1-4), so theoretically, one F2 module can support up to 16k*12=192k MAC addresses. However each ASIC will synchronize the mac address table per VLAN with other ASICs with the same VLAN. For example if ports 1 and 15 both allow vlan 1000, they will both have the mac address table entries for vlan 1000. Thus, if vlan 1000 has 16K mac address table entries, no more entries will be able to be programmed into those two ASICs. You may be hitting such issues.
Therefore, it is suggested to only allow those required VLANs in the trunk port.
Following is a link for the N7K verified scalability:
12-30-2014 06:53 AM
Thank you for the information, but that's the same information I already provided in my first post. Never do we come close to the 16k MAC limit, we normally hover around 12k.
I have also gone through and limited VLANs were appropriate to limit as much as possible.
02-10-2015 06:07 PM
After opening a TAC case and also escalating the case we've found that the CAM tables fill much quicker than the 16384 limitation on the card. This error message will start displaying around 70 - 80% of the 16384 MAC addresses that the F2 states as a maximum.
Be careful. We thought that since the limitation documented by Cisco was 16384 we would be ok with about 12k clients on these cards, we were very wrong.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide