☰

监视 Cisco 交换机上的 CAM 表的大小

tag-icon • tag-icon networking cisco monitoring snmp
监视 Cisco 交换机上的 CAM 表的大小

我们注意到我们的交换机中有一些散落的数据包从不应该发出的端口发出。

清除凸轮表后，clear mac address-table问题似乎消失了。目前我们最好的理论是，凸轮表在某个时刻被淹没，导致交换机表现出类似集线器的行为。

是否有人知道是否可以通过 SNMP 监控表的大小，以便我们可以跟踪它？

答案1

您是否了解泛洪数据包（或特定 VLAN）的大小和频率？一种常见现象是由于 CAM 和 ARP 计时器不匹配而导致的单播泛洪。如果 CAM 过期但相应的 ARP 条目仍然存在，则交换机将泛洪这些帧。我见过这种情况，这种情况导致千兆位流量出现在不该出现的地方。也有一些情况与 CEF 也丢失条目有关 - 然后在许多平台上表现为 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”，然后通过电子邮件、系统日志、陷阱等方式将结果传回。但这取决于硬件平台和代码版本。

答案2

不知道您是否可以通过 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

相关内容