Периодическая загрузка процессора на Cisco 2960? Добрый день,
столкнулся со следующей проблемой:
несколько коммутаторов (стеки) 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. в маршрутизации эти коммутаторы не учавствуют, дебаг, который может грузить цпу не запущен.
Периодическая загрузка процессора на Cisco 2960? Добрый день,
столкнулся со следующей проблемой:
несколько коммутаторов (стеки) 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. в маршрутизации эти коммутаторы не учавствуют, дебаг, который может грузить цпу не запущен.
столкнулся со следующей проблемой:
несколько коммутаторов (стеки) 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. в маршрутизации эти коммутаторы не учавствуют, дебаг, который может грузить цпу не запущен.
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Вы правильно заметили, что использование per-user DACL может привести к загрузке TCAM и, как следствие, к перенаправлению обработки трафика на процессор. Если TCAM полностью загружен, коммутатор не сможет обрабатывать новые записи и будет перенаправлять трафик на CPU для принятия решений о пересылке данных.
Для решения проблемы вы можете попробовать оптимизировать вашу конфигурацию DACL, уменьшить количество записей или использовать более эффективные ACL. Также, вы можете попробовать использовать VACL вместо per-user DACL, если это возможно в вашей среде.
Кроме того, вы можете проверить другие потенциальные причины высокой загрузки процессора, такие как широковещательный трафик, наводки, атаки на сеть и т. д. Обратитесь к логам коммутатора и проведите более подробное исследование, чтобы выяснить причину проблемы.