我们注意到一些stream出来的数据包从我们的交换机走出应该没有的端口。
在清除clear mac address-table清除凸轮表后，问题似乎消失了。 我们目前最好的理论是，桌子在某个时刻被淹没，导致转换器展现出这种中心的行为。
有谁知道是否可以通过SNMP监控表的大小，所以我们可以跟踪？
您是否对这个问题有充分的数据包大小和频率的感觉？ 由于CAM和ARP定时器不匹配，一种常见现象是单播洪泛。 如果CAM老化，但对应的ARP表项仍然存在，那么交换机将洪泛这些帧。 我已经看到了这种情况，导致了字面上千兆比特的stream量，显示了它不应该的地方。 在这种情况下，与CEF相关的input项也会丢失 – 这在许多平台上都performance为CPU问题。
至于通过SNMP拉地址计数 – 看看这个网页： http : //www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094a9b.shtml 。 这有点痛苦，但其机制是拉出VLAN列表，然后拉出每个VLAN的CAM表地址列表并相应计数。 从好的一面来看，如果实际上某处出现地址突然增多的话，它会给你一个线索。
你也可以通过ssh或定期的EEM脚本简单地调用“sh mac address-table count”，然后通过电子邮件，系统日志，陷阱等将结果传回。这取决于硬件平台和代码rev但是。
不知道是否可以通过SNMP进行监控，但可以使用以下命令检查大小（当前/最大使用率）： show platform tcam utilization
它应该给你以下输出：
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