We noticed some stray packets from our switch going out ports they should not have.

After clearing the cam table with clear mac address-table the problem seems to have gone away. Our best theory at the moment is that the table got flooded at some point causing the switch to exhibit this hub like behavior.

Does anyone know if the size of the table can be monitored via SNMP so we can track this?

  • What switch model and IOS version? – Wesley May 23 '12 at 3:36

Do you have a sense of the size and frequency of the flooded packets - or a particular VLAN, for that matter? One common phenomenon is unicast flooding due to the mismatch of CAM and ARP timers. If CAM ages out but the corresponding ARP entry is still there then the switch will flood these frames. I've seen circumstances where this has resulted in literally gigabits of traffic showing up places it wasn't supposed to. There have also been circumstances where this correlated with CEF also losing entries - which then manifests as CPU issues on many platforms.

As far as pulling the address count via SNMP - check out this page: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094a9b.shtml . It's slightly painful, but the mechanism is to pull the list of VLAN's and then to pull a list of CAM table addresses per VLAN and count accordingly. On the plus side it will give you a clue about where to look if there is actually a sudden proliferation of addresses somewhere.

You could also simply call "sh mac address-table count" either via ssh or a periodic EEM script that would then transmit the result back via e-mail, syslog, trap, etc.. This is dependent on the hardware platform and code rev, though.


No idea if you can monitor via SNMP, but you can check the size (current/max usage) with this command: show platform tcam utilization

It should give you the following output:

CAM Utilization for ASIC# 0                      Max            Used
                                            Masks/Values    Masks/values
Unicast mac addresses:                       3292/3292        702/702
IPv4 IGMP groups + multicast routes:         1120/1120          1/1
IPv4 unicast directly-connected routes:      3072/3072        305/305
IPv4 unicast indirectly-connected routes:    8144/8144       6839/6839
IPv4 policy based routing aces:               498/498          13/13
IPv4 qos aces:                                474/474          21/21
IPv4 security aces:                           972/972          33/33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.