Ivan Rostovikov Опубликовано 24 сентября, 2009 Стек из 3750. 3 штуки. c3750-advipservicesk9-mz.122-46.SE Периодически лавинообразно растет загрузка CPU. От 10-15 до 90 и более %% из них до 90 % составляет загрузка от прерываний т.е. трафик. Чем таким можно прогрузить 3750 на 90% и более - не представляю. Проблема исчезает так же нежидано как и появляется. В момент проблемы трафик по всем порта стека - минимальный. Т.к. свич просто неуспевает его пропускать. Как диагностировать непонятно. портов много, пока начинаеш отключать - проблема пропадает. Какие мысли ? Есть у этого свича ограничения на кол-во записей в таблице ARP ? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Alexandr Ovcharenko Опубликовано 24 сентября, 2009 А сколько всего МАС в сети? sh log что-то говорит? Возможен арп-флуд, переполняющий таблицы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Stak Опубликовано 24 сентября, 2009 Ходт такие слухи, что на стеке такое поведение наблюдается, если используется маршрутизация. При этом на свичах не в стеке всё в порядке. Сам не сталкивался правда, так что деталей не скажу... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
alks Опубликовано 24 сентября, 2009 вы ios недавно не меняли? какой сейчас работает? ... у нас была подобная проблема именно со стекированными свичами сменили ios проблема исчезла единственно что номер не помню Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan Rostovikov Опубликовано 24 сентября, 2009 #show platform tcam utilization CAM Utilization for ASIC# 0 Max Used Masks/Values Masks/values Unicast mac addresses: 784/6272 437/3419 IPv4 IGMP groups + multicast routes: 144/1152 7/28 IPv4 unicast directly-connected routes: 784/6272 437/3419 IPv4 unicast indirectly-connected routes: 272/2176 98/726 IPv4 policy based routing aces: 0/0 0/0 IPv4 qos aces: 768/768 260/260 IPv4 security aces: 1024/1024 195/195 Решили !Вот тут была проблема. Свич собирал по RIP маршруты от PPPoE NASов. Как только переваливало за 2K - Начинал работать CPU роутинг. Тут свичу и хана наступала... Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 25 сентября, 2009 Что-то странный набор функций на свитче. И МАСов много и маршрутов. Может, разделить, да и настроить разные sdm template? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Serhio Go Опубликовано 25 сентября, 2009 А что там странного-то? Imho, ничего. Просто routing template нужен. Правда, тогда придется в оба глядеть уже на размер MAC-таблицы. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
sirmax Опубликовано 25 сентября, 2009 UglyAdmin Это хорошо когда есть где взять второй свитч ) а как негде, и не так извернуться можно ) Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
UglyAdmin Опубликовано 25 сентября, 2009 Так ведь стэк. Раcформировать, выделить один из них под L2, выбрать для него sdm template vlan. Остальные - под L3, sdm template routing. :) Но вообще, анонсить по RIP /32 - плохая затея, слишком маршрутов много... Агрерировать надо по BRAS'ам, а /32 - только тем, у кого IP фиксирован (куплен). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...