Периодическая загрузка процессора на Cisco 2960?

Question

[Dmitry]

Добрый день,
столкнулся со следующей проблемой:
несколько коммутаторов (стеки) Cisco Catalyst 2960 (WS-C2960X-48FPS-L) стали периодически в течение дня показывать высокий уровень загрузки CPU.
На данный момент замечена проблема на 5 свичах.
Примеры высоких значений, замеченных в реальном времени с двух стеков:

switchname1#show processes cpu sorted | exclude 0.00%
CPU utilization for five seconds: 82%/20%; one minute: 74%; five minutes: 66%

swithcname2#show processes cpu sorted
CPU utilization for five seconds: 82%/19%; one minute: 89%; five minutes: 78%

Как видно, и там и там высокий уровень itterupt-загрузки, т.е. возможно TCAM не справляется и пакеты обрабатываются на CPU.
Но, во-первых в логах (debbuging level) нет никаких записей, связанных с TCAM, во-вторых, если смотреть TCAM utilization, в момент высокой загрузки, вижу следующее:

switchname1#show platform tcam utilization asic all

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values    Masks/values

 Unicast mac addresses:                      16604/16604      3217/3217
 IPv4 IGMP groups + multicast routes:         1072/1072          1/1
 IPv4 unicast directly-connected routes:      2048/2048          0/0
 IPv4 unicast indirectly-connected routes:    1024/1024         34/34
 IPv6 Multicast groups:                       1072/1072         11/11
 IPv6 unicast directly-connected routes:      2048/2048          0/0
 IPv6 unicast indirectly-connected routes:    1024/1024          3/3
 IPv4 policy based routing aces:               504/504          13/13
 IPv4 qos aces:                                504/504          51/51
 IPv4 security aces:                           600/600         581/581
 IPv6 policy based routing aces:                20/20            8/8
 IPv6 qos aces:                                500/500          44/44
 IPv6 security aces:                           600/600          17/17

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization


CAM Utilization for ASIC# 1                      Max            Used
                                             Masks/Values    Masks/values

 Unicast mac addresses:                      16604/16604      3217/3217
 IPv4 IGMP groups + multicast routes:         1072/1072          1/1
 IPv4 unicast directly-connected routes:      2048/2048          0/0
 IPv4 unicast indirectly-connected routes:    1024/1024         34/34
 IPv6 Multicast groups:                       1072/1072         11/11
 IPv6 unicast directly-connected routes:      2048/2048          0/0
 IPv6 unicast indirectly-connected routes:    1024/1024          3/3
 IPv4 policy based routing aces:               504/504           0/0
 IPv4 qos aces:                                504/504          51/51
 IPv4 security aces:                           600/600         491/491
 IPv6 policy based routing aces:                20/20            0/0
 IPv6 qos aces:                                500/500          44/44
 IPv6 security aces:                           600/600          17/17

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization

	
swithcname2#show platform tcam utilization asic all

CAM Utilization for ASIC# 0                      Max            Used
                                             Masks/Values    Masks/values

 Unicast mac addresses:                      16604/16604      1219/1219
 IPv4 IGMP groups + multicast routes:         1072/1072          1/1
 IPv4 unicast directly-connected routes:      2048/2048          0/0
 IPv4 unicast indirectly-connected routes:    1024/1024         34/34
 IPv6 Multicast groups:                       1072/1072         11/11
 IPv6 unicast directly-connected routes:      2048/2048          0/0
 IPv6 unicast indirectly-connected routes:    1024/1024          3/3
 IPv4 policy based routing aces:               504/504          13/13
 IPv4 qos aces:                                504/504          51/51
 IPv4 security aces:                           600/600         568/568
 IPv6 policy based routing aces:                20/20            8/8
 IPv6 qos aces:                                500/500          44/44
 IPv6 security aces:                           600/600          17/17

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization


CAM Utilization for ASIC# 1                      Max            Used
                                             Masks/Values    Masks/values

 Unicast mac addresses:                      16604/16604      1219/1219
 IPv4 IGMP groups + multicast routes:         1072/1072          1/1
 IPv4 unicast directly-connected routes:      2048/2048          0/0
 IPv4 unicast indirectly-connected routes:    1024/1024         34/34
 IPv6 Multicast groups:                       1072/1072         11/11
 IPv6 unicast directly-connected routes:      2048/2048          0/0
 IPv6 unicast indirectly-connected routes:    1024/1024          3/3
 IPv4 policy based routing aces:               504/504           0/0
 IPv4 qos aces:                                504/504          51/51
 IPv4 security aces:                           600/600         583/583
 IPv6 policy based routing aces:                20/20            0/0
 IPv6 qos aces:                                500/500          44/44
 IPv6 security aces:                           600/600          17/17

Note: Allocation of TCAM entries per feature uses
a complex algorithm. The above information is meant
to provide an abstract view of the current TCAM utilization

На что я думаю: на этих свичах используются per-user DACL, которые грузятся с ISE. На таких же абсолютно стеках, но где используются VACL, цп не грузится так, и прерываний на них 0-4% в среднем.
Могут ли dacl так забивать TCAM, что обработка трафика идет на процессор?
Или копать в другом направлении?
UPD. в маршрутизации эти коммутаторы не учавствуют, дебаг, который может грузить цпу не запущен.

Comments

[Владимир Дубровин]

Не могу сказать про конкретную модель, но чаще всего, высокая загрузка в течении длительного времени говорит о проблеме с хэш-таблицами, обычно это либо переполнение хэш-таблицы либо коллизия в таблице. К проблемам может приводить:
1. Слишком большое количество MAC-адресов. Либо просто много клиентов, либо какой-то из клиентов флудит случайными мак-адресами, либо делает спуфинг либо replay трафика.
2. Одинаковый MAC приходит с разных портов. Может быть следствием петли, клонирования MAC-адреса (в т.ч. непреднамеренного, в некоторых девайсах MAC слетает при перепрошивке), опять же спуфинг/реплей или на некоторых моделях коллизия может возникать случайно.
Часто источник проблемы можно найти посмотрев статистику по портам.

Answer 1

[DDwrt100]

1) Да Dacl могут положить железку. Встречал ситуациии когда 6500К вис, из-за использования DACL.
2) Посмотрите в момент нагрузки какой процесс отъедает больше всего ресурсов show proc cpu если правильно помню команду.

Comments

[Dmitry]

Спасибо за ответ. Я смотрел в момент высокой загруженности процессора процессы командой show processes cpu sorted и самый "жручий" был и остается "Hulc LED Process".

[DDwrt100]

Dmitry,
Самое просто поппробуйте отключить DACL если возможно и посмотреть будут ли проблемы.
Если есть подписка можете обратиться в TAC.

[Maxim Iontzev]

Насколько помню, на свичах только vlan acl обрабатываются аппаратно. Все остальные грузят процессор. Попробуйте уменьшить или оптимизировать свои списки доступа