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...
