web-dev-qa-db-ja.com

CiscoスイッチのCAMテーブルのサイズを監視する

スイッチからの漂遊パケットが、あるべきではないポートから出ていることに気づきました。

clear mac address-tableでカムテーブルをクリアした後、問題は解決したようです。現時点での最善の理論は、ある時点でテーブルがフラッディングし、スイッチがこのハブのような動作を示すようになるというものです。

テーブルのサイズをSNMP経由で監視できるかどうかを誰かが知っているので、これを追跡できますか？

networkingciscomonitoringsnmp
5
Kyle Brandt

フラッディングされたパケットのサイズと頻度、または特定のVLANについて理解していますか？一般的な現象の1つは、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スクリプトを介して「shmacaddress-table count」を呼び出すこともできます。このスクリプトは、結果を電子メール、syslog、トラップなどで送り返します。これは、ハードウェアプラットフォームとコードリビジョンによって異なります。 、しかし。

2
rnxrx

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
0
pauska