Мы заметили, что некоторые паразитные пакеты от нашего коммутатора выходят из портов, которых у них быть не должно.
После очистки кулачкового стола с помощью clear mac address-table проблема вроде исчезла. Наша лучшая теория на данный момент заключается в том, что в какой-то момент таблица была затоплена, что привело к тому, что коммутатор проявил поведение, подобное концентратору.
Кто-нибудь знает, можно ли контролировать размер таблицы через SNMP, чтобы мы могли это отслеживать?
Есть ли у вас представление о размере и частоте лавинных пакетов - или о конкретной VLAN, если на то пошло? Распространенным явлением является одноадресная лавинная рассылка из-за несовпадения таймеров CAM и ARP. Если CAM устаревает, но соответствующая запись ARP все еще существует, коммутатор будет лавинно рассылать эти кадры. Я видел обстоятельства, когда это приводило к появлению буквально гигабитных объемов трафика там, где этого не должно было быть. Также были обстоятельства, когда это коррелировало с потерей записей CEF, что затем проявлялось как проблемы с процессором на многих платформах.
Что касается подсчета адресов через SNMP - посмотрите эту страницу: http://www.cisco.com/en/US/tech/tk648/tk362/technologies_tech_note09186a0080094a9b.shtml . Это немного болезненно, но механизм состоит в том, чтобы вытащить список VLAN, а затем вытащить список адресов таблицы CAM для каждой VLAN и соответственно подсчитать. С другой стороны, это подскажет, где искать, если где-то действительно произошло внезапное увеличение количества адресов.
Вы также можете просто вызвать «sh mac address-table count» либо через ssh, либо через периодический EEM-скрипт, который затем будет передавать результат обратно по электронной почте, системному журналу, ловушке и т. Д. Это зависит от аппаратной платформы и версии кода. , хотя.
Понятия не имею, можно ли отслеживать через 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